Чем опытнее разработчик, тем меньше соблюдается принцип KISS?

Есть Keep It Stupid Simple принцип.

Но просматривая некоторые Laravel проекты на гитхабе от опытных разработчиков, есть ощущение что на этот принцип все положили.
Куча каких-то папок внутри app, сервис лееры, провайдеры, repository, полным полно каких-то трейтов. Под каждый чих свой класс. Всё друг на друге завязано.
Кто-то пытается сделать Symfony из Laravel.
Я понимаю, что сеньоры это умеют, знают много паттернов, но зачем всё усложнять?
Особенно когда в репозитории есть ссылка на сайт, а там... простой сайт с документацией какой-то библиотеки.

То есть создатели Laravel понаписали кучу всяких абстракций и магии, чтобы упростить задачу разработчикам, но тут еще и разработчики понаписали своего, по моему только лишь потому, что они это умеют.
Джуниор в таком проекте вряд ли сможет что-то дописать, а другой сеньор придет и перепишет все под себя потому, что он посчитает, что здесь нужно не этот паттерн, а вместо него еще 3-4 других, для "удобства".
Конкретных примеров приводить не буду, чтобы не кидать камень в огород какого-то конкретного разработчика. Но в целом тенденция такая.

Приведите пожалуйста пример правильно (соблюдая best practices) написанного проекта на Laravel, в котором нет ничего лишнего, если вы знаете такой.
  • Вопрос задан
  • 4406 просмотров
Решения вопроса 2
@FanatPHP
Принцип KISS не означает что надо использовать самые примитивные инструменты.
Он означает, что не надо переусложнять систему без нужды.
Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

Для того, чтобы упростить управление системой, её надо усложнить.
Этот принцип относится к любой области человеческой деятельности, от постройки ракет до управления государствами.
Чем сложнее система, тем больше накладные расходы на ее управление. Хоумпейдж с котиками можно и нужно делать примитивными средствами. В большом проекте надо сразу закладываться на будущую расширяемость. То есть, заранее делить ответственность между "леерами".

И кстати. Код, в котором "всё друг на друге завязано" - это очень плохой код. Собственно, предназначение всех этих "лееров, провайдеров и репозиториев" как раз в том, чтобы компоненты были как можно более независимы друг от друга.
Ответ написан
Adamos
@Adamos
Чем опытнее разработчик, тем чаще, выполняя конкретную задачу, он понимает, что примерно такую уже решал. Поэтому опытный разработчик видит уровни абстракции, общие для многих решений. И описывает их так, чтобы потом, при решении очередной конкретной задачи, использовать написанное ранее с минимумом дополнительных усилий.
Вы, не имея такого опыта, просто не понимаете, что все эти лееры, провайдеры и трейты - прекрасная возможность написать две строчки и быть уверенным в их работе там, где вы угробите два дня на написание "простого" решения, а потом еще неделю будете отлавливать его глюки.
Ответ написан
Пригласить эксперта
Ответы на вопрос 9
Arris
@Arris
Сапиенсы учатся, играя.
Самая частая причина - "бикоз ай кэн".

Разбирался как-то с одной библиотекой аутентификации на базе ларавель (не сентинель, там отдельный ужас). Господи, автор навернул 6 слоёв абстракции ради одной операции `login()`. ШЕСТЬ, я не шучу. Я мозг сломал, пытаясь это понять.

Написал автору, да. В ответ получил "Там все просто, чего тебе непонятно? (далее были контрпродуктивные оскорбления)"
Ответ написан
@stratosmi
Тем опытнее разработчик тем он лучше понимает когда и что нужно использовать.
Паттерны, принципы и т.п. - это для начинающих важно. Потом ты уже сам понимать начинаешь.
Ответ написан
Они все правильно делают. Невозможно "просто" сделать сложный проект, который будет расширяем и гибок. KISS, как правило, используется на этапе первоначальной разработки, когда нужно просто сделать - вот тогда да, он незаменим. Сроки жмут, а ты рюшечки пилишь, нет, нужно просто наговнокодить, клиент улыбнется, а там, глядишь, и на рефакторинг время даст.

Ну и Laravel круче Симфони, хоть и несколько медленнее.
Ответ написан
sim3x
@sim3x
0. Тайтлы существуют не для определения качества кодера, а для того чтоб не платить больше зп

1.
Куча каких-то папок внутри app, сервис лееры, провайдеры, repository, полным полно каких-то трейтов. Под каждый чих свой класс. Всё друг на друге завязано.
если в коде или рядом нет документации и тестов - считайте что ето говнокод

2.
Но просматривая некоторые Laravel проекты на гитхабе от опытных разработчиков, есть ощущение что на этот принцип все положили.
с другой стороны, есть проекты на которых хочется попробовать что-то новое, что конечно там не стоило использовать

3. Каждый такой проект стоит рассматривать отдельно и стоить теори по поводу
Чем опытнее разработчик, тем меньше соблюдается принцип KISS?
не стоит
Ответ написан
@asd111
То что ты назвал - repository, service layer, provider это не так сложно как кажется.

Repository - это прослойка над моделью, обычно один класс для каждой модели в котором собраны все функции для работы с моделью, т.е. все нужные запросы к БД через модель, чтобы не писать их в самой модели.

Service layer - прослойка между контроллером и репозиторием, обычно один класс для каждой модели(репозитория). Здесь обычно пишут обработку данных полученных из репозитория чтобы потом можно было сразу вставить во view. Как правило в service layer есть методы create read update delete - как в контроллере и в них пишут ту логику, которую обычно писали в контроллере только без привязки ко view.

Sevice Provider - некий код который кочует из проекта в проект и делает например авторизацию пользователя или кеширование. В Laravel есть свой механизм service provider.

Как правило service layer и repository добавляют чтобы всю логику класть туда и сохранить модели и контроллеры очень простыми. Например в методах контроллера может быть банальный вызов методов service layer с привязкой ко view и больше никакой логики.

Посмотри вот этот пример https://blog.eduonix.com/web-programming-tutorials... и сразу станет понятно.
В этом подходе нет ничего сложного иначе никто бы не пользовался.
Можешь сам попробовать написать тот же блог но только с service layer и repository - это проще чем кажется.
Ответ написан
@fpinger
Как раз молодые разработчики усложняют (они чаще плодят сущности, подражая, а не думая).
А вот специалисты с опытом упрощают. У упрощения два основных подхода:
1. Не делать того, что не требуется.
2. Разделять и властвовать над тем, что требуется. Правильно разделяя - мы упрощаем.

Что касается репозиториев. Объекты бизнес логики не должны знать где и как они хранятся, как извлекаются и сохраняются. Тогда бизнес логику легко написать и протестировать. Так же легко мы можем протестировать отдельно извлечение или сохранение объектов. Что ведёт к лёгкой смене хранилища. И при этом нет стандарта на репозитории и их интерфейс. Он может быть минимальным и добавляться на основе востребованности. Не нужно сразу писать интерфейс на все случаи жизни.

Порой случается, что бизнес логика простая. Взять объект из одного места и положить слегка изменив в другое. Вся сложность будет не в бизнес логике, а вокруг неё. С репозиториями. Один репозиторий реализует только извлечение в общий вид объекта, а второй только размещение в хранилище. И мы знаем, что если изменится API для какого-то из хранилищ, то изменения придётся вносить только для него. Мы разбили и скорее написали больше кода, но зная, что один API сырой или быстро изменяется, мы защитили себя от сложности внесения изменений.
Ответ написан
miraage
@miraage
Lead Software Engineer
Я понимаю, что сеньоры это умеют, знают много паттернов, но зачем всё усложнять?

Самая нелепая отмазка, чтобы не учить паттерны :)
Ответ написан
marperia
@marperia
Дизайнер, программист, писатель
Боюсь нарваться на butthurt, но и молчать уже не могу.
Умение строить архитектуру не зависит от опытности разработчика (увы и ах). Но, в то же время, кол-во фич, техник, паттернов и абстракций от опытности разработчика зависит напрямую.
Отсюда следует неутешительный факт: тупой (читай: не умеющий строить архитектуру) разработчик с возрастом начинает писать всё более и более навороченный говнокод.
У меня всё.
Ответ написан
customtema
@customtema
Кастомный софт и бизнес-аналитика
Ответ - в вопросе.

Значит не опытный.

Сколько знаю действительно опытных разработчиков, а знаю таких немало - у них "под капотом" всегда все экстремально просто.

Другой вопрос, что разработчики со стажем менее 10 лет себя к опытным относят... Ну, пускай относят. Через несколько лет будут думать иначе. "Эх, вот я дурак-то был..."

Можете заключать с ними пари.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы