Большая часть алгоритмов уже так или иначе реализована из коробки в яве, вам просто нужно понимать как они работают, в этом плане си будет неплох, а студенты не будут пытаться скопипастить собственные реализации алгоритмов в своих проектах, используя вместо них встроенные. И не будет вопросов типа, есть же функция x которую я могу использовать, зачем мне писать свою функцию y в 20 строк кода
Пример, так себе, это можно сделать и в вашем случае, и никто не говорил что так делается в моем случае, вы все равно не сможете сделать бизнес логику на 100% прозрачной, а время на это потратите неимоверное.
В одном из проектов, у нас куда больше 200 таблиц, более того, он работает с 7 разными базами данных и имеются связи как меж. таблицами одной базы так и меж таблицами разных баз данных. Тем не менее, у меня нет сложных запросов, а приложение работает быстро. Так же оно работает с разнообразными хранилищами типа s3, ftp, sftp и яндекс.диска. Так же есть очереди задач, Task Scheduling, прикручный elasticsearch, websocket сервер для real-time взаимодействий(на node.js общается с сайтом через бродкасты). Интеграциями с разными рекламными API для сборов статистики и управления рекламой, дашборд с аналитической информацией и многое другое, кол-во контроллеров не считал.
Что значит попдают? Передаю ли я их туда? Да, передаю, но никакой логики там, нет, просто вывод. На самом деле, я конечно, могу форматировать вывод или приобразовывать это все в массив, но толку с этого мало.
Да использую связанные отношения, и не вижу в этом ничего плохого, за 4 года работы проекта, пока не возникало глобальных проблем ни с обновлениями, ни с рефакторингом.
Есть такие.
Да, например в сущности новость, перед сохранением генерируется slug если название было изменено.
ЗЫ: На самом деле, вы можете написать хоть 10 слоев абстракций для общение с фреймворком, вы можете сказать что это дает вам неимоверный профит и возможность в любой момент сменить фреймворк, но вам все равно придется менять часть кода. Я же использую другой подход, мой код интегрируется с фреймворком, у меня нет никаких слоев меж ним и бизнес логикой, это безусловно имеет один минус — обновления проходят не так гладко, как в вашем случае, хотя, у вас проблем возникнут тоже. В моем случае используются практически все возможности фреймворка, когда мне их не хватает, что то даже модифицируется, в этом кстати Laravel преуспел как никто другой, а вы пытаеться от них отказаться в силу того, что в дальнейшем можете сменить фреймворк на другой.
Мне довелось поработать к на стартапах, так и в ентерпрайзе, на стартапе ваш способ так себе, потому что требует некотрых временных затрат на архитектуру, а в ентерпрайзе вам врятли кто то позволит через 4 года успешной работы на фреймворке Х перейти на фреймворк Y без крайне везких причин.
1. Как правило, достаточно сервиса, на самом деле любой лишний слой, добавляет сложность, а управление сложностью, очень важно для большого проекта.
2. При чем тут разница меж ними? Вы используете Laravel? Пользуйтесь предложенным подходом, он работает. Не нужно к метле педали прикручивать.
3. Если вы стремитесь в одном проекте совместить все паттерны сразу, то я вас тоже, огорчу, это так не работает.
Суть моего сообщение в том, что, не стоит недооценивать технологии не попробовав ее сполна, а потом говорить что я использовал паттерн1, паттерн2 и паттерн3 как на всех своих старых проектах в новом проекте на Laravel и он мне не понравился :) Это называется: «в чужой монастырь со своим уставом»
Ну куда, зачем Laravel не для этого придумали. На самом деле, я сталкиваюсь с разработчиками (такие есть и в комментариях) которые я пару раз правил код в Laravel и он вообще имеет не правильную архитектуру и вообще давайте не юзать Eloqent, навернем три слоя абрстракции сверху и будем радоваться жизни.
На самом же деле для небольших проектов достаточно ничего не мудрить, а просто писать код как вам предложили (даже если вы супер мего крутой Senior Software Engineer) и побольшей части для сайта заказа пиццы никакие Сервисы даже не нужны.
Все эти современные стандарты и крутые абривиатуры, на самом деле всех бесит что Laravel ломает их, к примеру:
И что же, он найдет пиццу, а если не найдет у юзера высвититься красивая 404 ошибка (из коробки, Карл, просто установил laravel написал 10 строк кода и оно работает!)
А нам предлагают, делать так:
class PizzaRepository {
// какие то 100 строк кода
}
class PizzaService {
// какие то 100 строк кода
}
someControllerMethod(PizzaService $pizzaService) {
$pizza = $pizzaService->find($pizza);
if (!$pizza) {
throw new SomeHttpException('Pizza not found...');
}
return view('pizza.show', ['pizza' => $pizza])
}
На самом деле, в Laravel модель выполняет множество функций, что позволяет избавить от написание лишних 300 строк кода, это есть фишка это фреймворка, он сделан в первую очередь для того, что бы вы как программист занимались бизнес-логикой, а не тратили время на изучение очередного модного архитектурного паттерна и пытались придумать свой велосипед.
У меня довольно много проектов на Laravel, есть и одиночные, есть и с небольшими командами 3-6 человек, и пока мы не сталкивались с тем что у нас что то пошло не туда, с самого начала пути (есть проекты долгожители, которые живут с 3 версии Laravel, сейчас он уже на версии 5.5) мы стараемся просто использовать ту парадигму которую предлагает Laravel.
И все это время читаю на разных форумах об архитектуре Laravel что Eloqent слабоват и не позваляет писать сложные запросы, красиво. На самом деле, решение простое, не писать сложные запросы, использовать простые связи, избегать вложенности и писать код с удовольствием. У вас много сложных запросов? Вы где то свернули не туда. Уже прошли те времена, когда считалось крутым одним запросом вытащить пол базы данных.
Мне, вот, тоже аукнулось, ну что сказать, пошел на заочку… В основном это бюрократия, как правило чтобы куда то перебраться (туда где потеплее) нужен хотя-бы баколавр.
Хотя после 7 лет простой разработки, захотелось чего то большего и тут прилетела по голове высшая математика и физика, коих иногда не хватает, да и вдруг стали интересны совсем странные темы.
Прочел обе статьи, полностью солидарен с автором(ми) обоих статей, как обычно все решают деньги.
Практики наказаний 0, что бы быть отчисленным из ВУЗа, нужно так не хило постараться (из своего личного опыта, и из опыта знакомых ребят), более того так же дела обстоят и со школами, как и собственно с колледжами.
Если в группе мало обучающихся это минус для вуза и преподавателей, отсюда никто не хочет исключать даже явных так бездарей (и речь даже не о тех кому просто не дано, а о тех кто просто пришел чтобы отоспаться на паре, к примеру), а вот нормальных ребят это просто вымораживает, о чем ниже:
После общения с одним из профессоров ВУЗа, вылезает такая статистика что ребята, которые хотя-бы что то могу и знают (речь про IT) просто сваливают с 3 курса и идут работать (об этом ниже), ну оно и понятно, как сказано где то в комментах, остальная часть просто сидит и ждет чего то с неба.
Касательно работы же в IT, на данный момент довелось проводить собеседования в одной из московских компаний(несколько лет назад) и сейчас, в СПб:
Выходцы из вузов, обычно приходят с требованиями зарплаты, что позавидуешь, но в итоге оказывается что человек отсидел 5 курсов в модном вузе и вот, на деле ничего не стоит, а самое забавное что идти в джуны или стажоры ребята просто не хотят.
Незаконченное высшее / заочка / самоучки — подают куда большие надежды, готовы показать свои проекты (с самоучками веселее, находятся индивиды которые кидаю вызов, мол берите меня на самую низкую ставку и я вам докажу(такие редкость, но своего добиваются))
Притом «название» ВУЗа особой роли не играет, в СПб много легендарных выходцев из ИТМО, на деле точно такой же разброс есть те кто старается и есть те кто просто сидит. (у нас есть один забавный пример, человек учившийся на «преподавателя» в ИТМО сейчас работает успешно программистом)
По существу своему как я писал вышел перенос редко занимает большое кол-во времени, а если брать в учет что есть подробное описание того как это сделать, проблем возникать не должно.
По факту изменений структуры в минорных версиях, нигде не видел чтобы кто-то регламентировал это, более того мы можем тогда ругать разработчиков PHP за то, что эти гады добавляют и изменяют функциональность в минорных версиях(если смотреть на это взглядом сверху) :) в общем-то подобный подход и дает свежачек этому фреймворку
Laravel поддерживает php7 и 5.6, все что ниже уже давно «протухло», не выпускаются даже фиксы по безопасности: http://php.net/supported-versions.php
Я думаю если на проект вброшено аж 5ppl команда, то она следит за безопасностью продукта и уже давно должна была напинать под зад сисадмину для перехода на новую версию.
Хотя это уже все придирки, да и в общем то… я сейчас на должности Java программиста, так что мне грех Php обсуждать :)
Переходил с 4.2 -> 5.0, с 5.0 -> 5.1, с 5.0 -> 5.2 в принципе если внимательно это делать, то даже на объемный проект уходит не так много времени.
По моему личному мнению, дело не в зрелости, нет смысла погружать себя в рамки обратной совместимости, все шагают вперед, я привык все держать на последних версиях, если не забивать на маленькие апдейты, то поддержка не станет апокалипсисом. А учитывая насколько большую аудиторию имеет данный фреймворк, собственно как и комьюнити то проблем с подобными выворотами у них не возникает, а мы имеем свежачек.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Большая часть алгоритмов уже так или иначе реализована из коробки в яве, вам просто нужно понимать как они работают, в этом плане си будет неплох, а студенты не будут пытаться скопипастить собственные реализации алгоритмов в своих проектах, используя вместо них встроенные. И не будет вопросов типа, есть же функция x которую я могу использовать, зачем мне писать свою функцию y в 20 строк кода
Что значит попдают? Передаю ли я их туда? Да, передаю, но никакой логики там, нет, просто вывод. На самом деле, я конечно, могу форматировать вывод или приобразовывать это все в массив, но толку с этого мало.
Да использую связанные отношения, и не вижу в этом ничего плохого, за 4 года работы проекта, пока не возникало глобальных проблем ни с обновлениями, ни с рефакторингом.
Есть такие.
Да, например в сущности новость, перед сохранением генерируется slug если название было изменено.
ЗЫ: На самом деле, вы можете написать хоть 10 слоев абстракций для общение с фреймворком, вы можете сказать что это дает вам неимоверный профит и возможность в любой момент сменить фреймворк, но вам все равно придется менять часть кода. Я же использую другой подход, мой код интегрируется с фреймворком, у меня нет никаких слоев меж ним и бизнес логикой, это безусловно имеет один минус — обновления проходят не так гладко, как в вашем случае, хотя, у вас проблем возникнут тоже. В моем случае используются практически все возможности фреймворка, когда мне их не хватает, что то даже модифицируется, в этом кстати Laravel преуспел как никто другой, а вы пытаеться от них отказаться в силу того, что в дальнейшем можете сменить фреймворк на другой.
Мне довелось поработать к на стартапах, так и в ентерпрайзе, на стартапе ваш способ так себе, потому что требует некотрых временных затрат на архитектуру, а в ентерпрайзе вам врятли кто то позволит через 4 года успешной работы на фреймворке Х перейти на фреймворк Y без крайне везких причин.
2. При чем тут разница меж ними? Вы используете Laravel? Пользуйтесь предложенным подходом, он работает. Не нужно к метле педали прикручивать.
3. Если вы стремитесь в одном проекте совместить все паттерны сразу, то я вас тоже, огорчу, это так не работает.
Суть моего сообщение в том, что, не стоит недооценивать технологии не попробовав ее сполна, а потом говорить что я использовал паттерн1, паттерн2 и паттерн3 как на всех своих старых проектах в новом проекте на Laravel и он мне не понравился :) Это называется: «в чужой монастырь со своим уставом»
На самом же деле для небольших проектов достаточно ничего не мудрить, а просто писать код как вам предложили (даже если вы супер мего крутой Senior Software Engineer) и побольшей части для сайта заказа пиццы никакие Сервисы даже не нужны.
Все эти современные стандарты и крутые абривиатуры, на самом деле всех бесит что Laravel ломает их, к примеру:
Или, о боги, даже так:
И что же, он найдет пиццу, а если не найдет у юзера высвититься красивая 404 ошибка (из коробки, Карл, просто установил laravel написал 10 строк кода и оно работает!)
А нам предлагают, делать так:
На самом деле, в Laravel модель выполняет множество функций, что позволяет избавить от написание лишних 300 строк кода, это есть фишка это фреймворка, он сделан в первую очередь для того, что бы вы как программист занимались бизнес-логикой, а не тратили время на изучение очередного модного архитектурного паттерна и пытались придумать свой велосипед.
У меня довольно много проектов на Laravel, есть и одиночные, есть и с небольшими командами 3-6 человек, и пока мы не сталкивались с тем что у нас что то пошло не туда, с самого начала пути (есть проекты долгожители, которые живут с 3 версии Laravel, сейчас он уже на версии 5.5) мы стараемся просто использовать ту парадигму которую предлагает Laravel.
И все это время читаю на разных форумах об архитектуре Laravel что Eloqent слабоват и не позваляет писать сложные запросы, красиво. На самом деле, решение простое, не писать сложные запросы, использовать простые связи, избегать вложенности и писать код с удовольствием. У вас много сложных запросов? Вы где то свернули не туда. Уже прошли те времена, когда считалось крутым одним запросом вытащить пол базы данных.
Хотя после 7 лет простой разработки, захотелось чего то большего и тут прилетела по голове высшая математика и физика, коих иногда не хватает, да и вдруг стали интересны совсем странные темы.
Практики наказаний 0, что бы быть отчисленным из ВУЗа, нужно так не хило постараться (из своего личного опыта, и из опыта знакомых ребят), более того так же дела обстоят и со школами, как и собственно с колледжами.
Если в группе мало обучающихся это минус для вуза и преподавателей, отсюда никто не хочет исключать даже явных так бездарей (и речь даже не о тех кому просто не дано, а о тех кто просто пришел чтобы отоспаться на паре, к примеру), а вот нормальных ребят это просто вымораживает, о чем ниже:
После общения с одним из профессоров ВУЗа, вылезает такая статистика что ребята, которые хотя-бы что то могу и знают (речь про IT) просто сваливают с 3 курса и идут работать (об этом ниже), ну оно и понятно, как сказано где то в комментах, остальная часть просто сидит и ждет чего то с неба.
Касательно работы же в IT, на данный момент довелось проводить собеседования в одной из московских компаний(несколько лет назад) и сейчас, в СПб:
Выходцы из вузов, обычно приходят с требованиями зарплаты, что позавидуешь, но в итоге оказывается что человек отсидел 5 курсов в модном вузе и вот, на деле ничего не стоит, а самое забавное что идти в джуны или стажоры ребята просто не хотят.
Незаконченное высшее / заочка / самоучки — подают куда большие надежды, готовы показать свои проекты (с самоучками веселее, находятся индивиды которые кидаю вызов, мол берите меня на самую низкую ставку и я вам докажу(такие редкость, но своего добиваются))
Притом «название» ВУЗа особой роли не играет, в СПб много легендарных выходцев из ИТМО, на деле точно такой же разброс есть те кто старается и есть те кто просто сидит. (у нас есть один забавный пример, человек учившийся на «преподавателя» в ИТМО сейчас работает успешно программистом)
По факту изменений структуры в минорных версиях, нигде не видел чтобы кто-то регламентировал это, более того мы можем тогда ругать разработчиков PHP за то, что эти гады добавляют и изменяют функциональность в минорных версиях(если смотреть на это взглядом сверху) :) в общем-то подобный подход и дает свежачек этому фреймворку
Laravel поддерживает php7 и 5.6, все что ниже уже давно «протухло», не выпускаются даже фиксы по безопасности: http://php.net/supported-versions.php
Я думаю если на проект вброшено аж 5ppl команда, то она следит за безопасностью продукта и уже давно должна была напинать под зад сисадмину для перехода на новую версию.
Хотя это уже все придирки, да и в общем то… я сейчас на должности Java программиста, так что мне грех Php обсуждать :)
По моему личному мнению, дело не в зрелости, нет смысла погружать себя в рамки обратной совместимости, все шагают вперед, я привык все держать на последних версиях, если не забивать на маленькие апдейты, то поддержка не станет апокалипсисом. А учитывая насколько большую аудиторию имеет данный фреймворк, собственно как и комьюнити то проблем с подобными выворотами у них не возникает, а мы имеем свежачек.