Я давно занимаюсь разработкой ПО, и с кем бы я ни работал, от начинающих разработчиков и до архитекторов (не Вася-архитектор, а из крупной компании), все работают по принципу прибить гвоздями, а потом когда нужен будет развивать систему, что-нибудь придумаем.
Мне этот подход очень не нравится, и я вижу в паттернах решение задач, и что самое главное, они позволяют отложить решение задачи на самый конец, т.е. можно создать систему, а потом в неё интегрировать нужное решение.
На деле немного другое получается. Если стараться проектировать систему на уровне паттернов, получается хорошее решение (т.е. можно безболезненно изменять систему, развивать, поддерживать, и так далее), но на выходе получается решение, которое далеко от принципа KISS, т.е. вместо простого решения получается гибкий монстр, который говорит тебе "я гибкий, я хороший", но от количества сущностей система становится сложной и запутанной.
Я почитал что пишут люди, но мнения разные, от "не используйте паттерны, будет хуже" до "используйте их всегда", и есть кто посередине, "пишите сначала без паттернов, а потом упрощайте систему их внедрением".
Поэтому, какие ваши рецепты по использованию паттернов, когда вы их используете и почему?
Такой рецепт: используйте паттерны, когда вам кажется, что вы можете их использовать, и не бойтесь выкинуть неудачный код только потому, что там красиво использованы паттерны.
Постепенно придете к пониманию, когда их нужно применять и как.
Просто по книжкам этого понимания не получишь.
Я тоже так думаю. Похоже, что нужно их в голове и при их помощи проектировать решение, но не натягивать сову на глобус. Т.е. пишем код, решаем наши задачи, но когда видим явную необходимость внедрить некоторое решение уже решенное паттерном, его можно применить.
нет. Вы еще не переболели болезнью джуна, прочитавщего книгу с паттернами
Правильный подход
все работают по принципу прибить гвоздями, а потом когда нужен будет развивать систему, что-нибудь придумаем.
Если стараться проектировать систему на уровне паттернов, получается хорошее решение
нет. Получается решение собранное из паттернов, а не решение задачи
мнения разные, от "не используйте паттерны, будет хуже" до "используйте их всегда", и есть кто посередине, "пишите сначала без паттернов, а потом упрощайте систему их внедрением".
Все три некорректны
Пишите код, который решает задачи. По возможности, масштабиремый, слабосвязный и тп.
Главная забота - решение поставленной задачи
Вы попали в точку, это мой пробел, который я стараюсь заполнить, но пока выходит что от него толку крайне мало.
Но вы не написали аргументов, совсем. Весь код решает задачи, по-разному. Паттерны призваны решить проблемы масштабируемости, зависимостей, и прочие проблемы. Поэтому вы говорите что про них нужно говорить только на конференциях (т.е. использовать их, видимо, вы не хотите), и сами указываете на проблемы, которые ими решаются.
Похоже, что вы сами запутались, поэтому, какие ваши рецепты и почему?
В этом и вопрос.
К слову, написать код решающий задачу, это далеко не правильное решение задачи. Работающее решение и хорошее решение, это не всегда одно и то же. Если вы давно в разработке ПО, вы должны это знать.
Можно сделать рабочее решение, и при необходимости его развить, внедрить новые функции, придется пилить его на части и вклинивать решение, потому что текущая архитектура не позволяет этого сделать.
RomanYakimchuk, Так называемая "академическая разработка", очень сильно отличается от реалий. Когда бизнес говорит "Нужна вот такая фича! Причём она нужна даже не вчера, а на прошлой неделе!", никто вам не даст времени на рисование диаграммы классов. Согласен с sim3x чуть более чем полностью - про паттерны можно поговорить на конференциях или в пет-проектах.
Паттерны призваны решить проблемы масштабируемости, зависимостей, и прочие проблемы.
нет. Паттерны - решают "проблему" стандартизации кода и именования блоков кода
Они не решают задачи масштабирования и тд
Поэтому вы говорите что их использовать не нужно, и сами указываете на проблемы, которые ими решаются.
Вы не можете с помощью синглтона ничего решить. Вы решаете задачи с помощью кода. А то что код похож на паттерн синглон - совпадение
Паттерны не должны становиться самоцелью вашего кода
Вы не должны проектировать в паттернах, потому как вы будете притягивать за уши задачу на паттерн.
И в итоге, код превратиться в трешовый набор паттернов, слабо решающий задачу
Мы разработчики, мы не менеджеры. Если мы будем идти на встречу управлению, мы в итоге превратим проект в монолитного монстра и он будет невероятно неподвижным. Проходил это не один раз, поэтому наша задача работать максимально качественно, и драться за качество насмерть.
Понимаю о чем вы, мы все постоянно в этом живем, это реальность, и так почти везде. Правда, есть проекты где можно выбить большой бюджет, и если можно сделать хорошо, почему нет?
К слову, написать код решающий задачу, это далеко не правильное решение задачи
Для мидл+ утверждение не верно
Работающее решение и хорошее решение, это не всегда одно и то же
Оценки "хорошести" решения займут больше чем написание Линукса
Можно сделать рабочее решение, и при необходимости его развить, внедрить новые функции, придется пилить его на части и вклинивать решение, потому что текущая архитектура не позволяет этого сделать.
если текущая "архитектура" чего-то не позволяет ее можно переписать.
Не стоит бояться выкидывать код
RomanYakimchuk,
Я нигде не писал, что вы обязаны писать плохой код
Я также дополнительно укажу, что преждевременная оптимизация и попытки сделать "архитектуру" на временном проекте, также отвратительны как и монолит
>Для мидл+ утверждение не верно
Тогда пишите всё ваше приложение в одном классе, и посмотрим какое хорошее у вас получится приложение, товарищ знаток J
Задача это не только бизнес, это еще и техника. Не подумав о технической стороне вы обрекаете приложение на тотальный рефакторинг по требованию новых фич. Т.е. вы изначально пишете потенциально легаси систему.
Это называется перерасход трудозатрат в N-раз, и потенциально убийство проекта.
Если я вас не так понял, объяснитесь, пожалуйста?
Мы в интеллигентном обществе, здесь положено аргументировать свои мысли, а не просто разбрасываться утверждениями и громкими словами.
Roman, Спасибо, не знал про него. Насколько я понимаю, это про использование одного решения под всё, и про неверное использование инструментов, т.е. это к паттернам напрямую не относится.
Паттерны не должны становиться самоцелью вашего кода
Вы не должны проектировать в паттернах, потому как вы будете притягивать за уши задачу на паттерн.
И в итоге, код превратиться в трешовый набор паттернов, слабо решающий задачу
Так а что делать, как вы считаете?
Если так не делать, получится относительно жесткое довольно простое решение.
Если делать, получится сова на глобусе.
Вы сами пришли к вопросу, который я изначально задал.
Что вы думаете то, в результате?
RomanYakimchuk, в некоторых учебниках по проектированию ПО можно встретить утверждения, что паттерны в коде должны появляться естественных образом - в процессе рефакторинга рабочего кода. Попытки использовать их со старта подобны преждевременной оптимизации.
Единственный способ не использовать паттерны, это не писать код. Паттерн это общие механизмы решения задач, встречающихся в программировании, без привязки к синтаксису языка. Если кто-то работает со сложными проектами и при этом говорит что он не использует паттерны - это значит лишь, что он не понимает что такое паттерн или просто не знает названия паттернов, которые он использует. Изучать их я бы рекомендовал в несколько подходов - сначала просто почитать что-то популярное для общего развития, надеясь, что нечто отложится в подсознании. Второй шаг стоит сделать после пары лет работы со сложными проектами и\или фреймворками - читаете, пытаясь понять какие паттерны вы используете сами, какие паттерны используются в вашем любимом фреймворке и т.п., изучаете все их нюансы и разновидности, приучаете себя \ свою команду использовать названия паттернов, вместо пространных описаний где это возможно. Только после познания дзена в первых двух шагах стоит переходить к третьему - изучение незнакомых, непонятных паттернов, при этом вы пытаетесь понять в каком из прошлых проектов этот паттерн мог бы быть применен и какие преимущества он дает по сравнению с решением которое было там. Знание и понимание паттернов позволяет сделать систему настолько простой насколько это возможно, если у вас попытка применения паттернов приводит к появлению лишних сущностей - скорее всего вы просто поторопились с шагом 3.
