Шаблоны дизайна не одобряются?

У меня была беседа с одним из наших старших разработчиков, который работает в этом бизнесе уже 20 лет. Он очень хорошо известен в Онтарио по блогам, которые он пишет.

Странная вещь состоит в том, что он сказал мне: он сказал, что есть кусок кода, с которым кошмарно работать, потому что он написан из учебника и не учитывает реальный мир. Добавление нового поля в слой UI / database / Data занимает 2-3 часа, тогда как в его коде это занимает 30 минут.

Другое дело, что он избегает шаблонов проектирования, потому что большинство программистов их не понимают, и они не очень хороши с точки зрения обслуживания.

Также существует идея, что большинство веб-разработчиков в Канаде предпочитают наследовать свою модель данных от классов Data Layer, а не держать ее изолированной. Я спросил его: «Разве не является отраслевым стандартом отделение модели от слоя данных?» Он иногда говорил, но большинство людей здесь предпочитают не делать этого, потому что это слишком много работы.

Похоже, его аргументация в пользу того, что он не кодирует с использованием передового опыта, заключается в том, что это кошмар обслуживания, мало кто из наших сотрудников понимает это (кроме меня), и с ним трудно работать, если вам нужно выдвинуть новые функции или поля в течение нескольких дней ». время.

Странно слышать подобное мнение, учитывая, что переполнение стека в основном побуждает людей следовать отраслевым стандартам. Является ли проблемой то, что мы постоянно вынуждены создавать новые поля и функции в течение нескольких дней, что невозможно вывести твердый шаблон, который достаточно гибок? Кажется, в этом суть того, что я понимаю из этого.

Что вы делаете из этих заявлений?

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

Шаблоны проектирования и лучшие практики - это не одно и то же. Некоторые люди думают, что они есть, и сводят людей, которые знают, что они делают, чокнутые. Даже если они не знают правильного имени для того, что они делают.

Шаблоны дизайна существовали до того, как у них были имена. Мы дали им имена, чтобы было легче говорить о них. Шаблон с именем не делает его хорошим. Это делает это узнаваемой вещью.

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

Многие шаблоны проектирования, которые вы и ваш друг описывает, на самом деле являются просто обходными путями для недостатков в языках программирования . Используйте более выразительный язык программирования, и большая часть этих шаблонов проектирования исчезает.

Поскольку для удовлетворения многих возможных сценариев использования требуются хорошие шаблоны проектирования, они, как правило, чрезмерно спроектированы. Чрезмерно спроектированный код имеет свою цену: вы должны прочитать его, понять, что он делает, и понять, как он работает в контексте всей системы программного обеспечения. Следовательно, как и в случае любой другой методики разработки программного обеспечения, вы должны сравнить методику с затратами на ее использование и решить, превышают ли выгоды затраты.

При прочих равных условиях лучше всегда меньше кода. Я прошел через многоуровневую архитектуру, где буквально приходилось делать от трех до шести прыжков через несколько проектов, чтобы найти любой интересный код, то есть код, который на самом деле выполняет нечто иное, чем добавление накладных расходов.

Предполагается, что хорошо известные программные шаблоны дают вам общий словарный запас, с помощью которого вы можете передавать стратегии проектирования. К сожалению, многие разработчики программного обеспечения недостаточно хорошо понимают словарь шаблонов программного обеспечения, чтобы правильно применять его в своих задачах программирования. Неопытные разработчики видят в этих шаблонах компетенцию экспертов; они хотят, чтобы их считали экспертами, и поэтому они пытаются изучить и применить шаблоны слишком рано, прежде чем они будут готовы. Вместо этого они должны сначала сосредоточиться на изучении основ программирования, а затем попытаться решить проблему, которую каждый шаблон решает самостоятельно. Если они это сделают, они будут в гораздо лучшем положении, чтобы правильно понимать и применять шаблоны.

Stackoverflow.SE и Programmers.SE в основном побуждают людей следовать передовым методам, таким как SOLID, а не отраслевым стандартам . И верьте этому или нет, де - факто отраслевым стандартом часто является «большой шар из грязи» архитектуры - серьезно.

Но, чтобы ответить на ваш вопрос напрямую: проблема с шаблонами проектирования аналогична проблеме с наследованием - многие посредственные разработчики злоупотребляют ими, что создает определенный риск создания чрезмерно сложного, сложного в обслуживании кода. Но ответ на это, безусловно, состоит в том, чтобы не избегать и не запрещать использование шаблонов проектирования (или наследования) полностью, ответ заключается в том, чтобы научиться использовать эти инструменты в ситуациях, когда они имеют смысл, и только там. И это полностью независимо от работы "гибкой" или нет.

1. Шаблоны дизайна - это просто имена, используемые для передачи идей. Я часто обнаруживал, что занимаюсь тем, что позже обнаружил имя. Таким образом, не существует «схемы проектирования», в отличие от «схемы проектирования».

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

3. Любая лучшая практика и рекомендации могут быть проигнорированы, если есть достаточно веская причина. Основательные причины включают время разработки и ожидания от приложения. Например, я знаю, что жестко кодировать значения (глупый пример) плохо, но для подтверждения концепции преимущества могут перевесить затраты (в данном случае это в основном время разработки). Однако, если такое решение принято, оно может иметь неприятные последствия, и в какой-то момент может потребоваться рефакторинг.

Чтобы добавить еще одну метафору в суп, шаблонами проектирования являются Clippy - помощник Microsoft Office. «Похоже, вы делаете то же самое с целой кучей вещей. Могу я помочь вам с этим, предложив вам Iterator или Visitor?»

Хорошая запись этих шаблонов покажет, когда полезно сделать что-то так же, как это делалось много раз раньше, какие ошибки вы совершите в первый раз, и какие были найдены общие способы избежать этих ошибок. , Итак, вы читаете шаблон проектирования (или просматриваете его по памяти), а затем вы приступаете к своей работе. То, что вы не можете сделать, это получить только с помощью Clippy и мастеров.

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

Конечно, кто-то также может избежать паттерна, основанного на YAGNI, а затем понять, что он ему нужен, и попытаться найти нормальное решение. Это обычно (но не всегда) хуже, чем реализация требования с самого начала, и поэтому даже в гибкой разработке разочаровывает, когда полностью предсказуемые требования не обнаруживаются на ранней стадии. Я не мог быть единственным программистом на C ++, который был сильно удивлен тем, что Java изначально отвергала универсальные контейнеры как ненужно сложные, а затем снова включила их.

Поэтому почти наверняка было бы ошибкой избегать написания Итератора в принципе, потому что вы предпочитаете избегать шаблонов проектирования.

Добавление нового поля в слой UI / database / Data занимает 2-3 часа, а в его коде - 30 минут.

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

Поэтому он признал, что любой шаблон, который требует от вас прикосновения к множеству различных точек в коде, чтобы добавить поле, является плохим шаблоном для работы, «облегчать добавление полей», и он не использовал эти шаблоны. Многоуровневые архитектуры действительно могут пострадать в этом отношении, и неправильно использовать шаблоны проектирования, не осознавая их недостатков.

В отличие от этого, сколько времени нужно, чтобы написать новый пользовательский интерфейс в своем дизайне, и сколько времени это занимает в многоуровневой архитектуре? Если бы проект требовал от него постоянно создавать и развертывать новые пользовательские интерфейсы поверх фиксированной модели данных, вместо того, чтобы постоянно добавлять поля, мы надеемся, что он разработал бы это вместо этого. Или так же. Но, несмотря на все свои преимущества, говорить «мы делаем гибкие», к сожалению, не означает, что вам никогда не придется делать еще один компромисс!

Выбор из меню шаблонов дизайна, безусловно, может помешать вам думать о самых важных проблемах. Но распознавание того, когда вы пишете «Посетитель», и документирование или присвоение ему названия «Посетитель», чтобы помочь читателям быстро получить его, ничего не мешает. Писать «это посетитель» вместо правильного документирования - ужасная ошибка по той причине, которую дает ваш старший разработчик - программисты этого не поймут. Даже программистам, которые знают, что такое посетитель, нужно больше информации, чем просто «это посетитель».

Ваш коллега, кажется, страдает от синдрома NIH («Не изобретено здесь»).

Вполне вероятно, что его код облегчает добавление новых полей: я также гораздо быстрее обновляю свой собственный код, чем код, написанный другими парнями. Но эта кратковременная скорость ничего не говорит о возможности сопровождения и переносимости кода. Я дам ему преимущество сомнения: существующий код действительно может быть плохо структурирован, если он плохо следовал учебнику или придерживался хорошего рецепта в неправильном контексте.

Избегать шаблонов дизайна действительно удивительно. За последние 30 лет программирования и управления кодировщиками шаблоны проектирования помогли выразить словами то, что было сделано инстинктивно, что помогло быстрее понять цель, преимущества, неудобства, риск, возможности и связанные с ними шаблоны. Шаблоны проектирования оказались реальными ускорителями для освоения сложности!

• Возможно, ваш коллега действительно намного умнее, чем большинство из нас, и он может позволить себе переизобретать шаблоны без заметного снижения производительности?

• Аргументы, что «программисты не понимают шаблоны проектирования» звучат как «Я не могу объяснить, что я делаю». Или «Я не хочу спорить о своем собственном дизайне». Я действительно думаю, что шаблонизация может использовать общее понимание и позволить менее старшим коллегам делиться ценными мнениями. Но, возможно, ваш старший коллега хочет избежать этого.

Многоуровневые подходы доказали превосходство над другими архитектурами в большинстве корпоративных приложений. Ведущие пакеты мирового класса построены вокруг этой идеи и на порядок превосходят кустарные архитектуры. Мартин Фаулер представляет этот подход в своей превосходной книге «Шаблоны архитектуры предприятия». Ой! Извините еще раз: речь идет о проверенных моделях; нет шансов с точки зрения NIH вашего коллеги ;-)

Многие люди упускают из виду, что дизайн программного обеспечения является контекстным. Он существует для достижения бизнес-целей, и для разных целей могут потребоваться разные подходы. Иными словами, нет лучшего дизайна, хотя лучший дизайн всегда есть.

Шаблоны проектирования - это стандартные решения стандартных проблем. Однако, если у вас нет проблемы, ее решение - пустая трата усилий.

Ключевое различие между водопадом и гибкой разработкой программного обеспечения заключается в том, когда принимаются дизайнерские решения. В водопаде мы собираем все требования, определяем, какие шаблоны проектирования нам нужны, и только потом начинаем кодировать. В гибкой архитектуре мы следуем принципу YAGNI, чтобы откладывать проектные решения до последнего ответственного момента, когда мы знаем о выборе столько, сколько возможно.

То есть в водопаде шаблоны проектирования, как правило, применяются, если их потребность предвидится , в гибкой, когда они действительно необходимы . Как следствие, гибкие проекты имеют тенденцию применять шаблоны проектирования реже, поскольку не все ожидаемые потребности актуальны.

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

В этом смысле, если вы действительно не привержены написанию 100% -ого одноразового кода, где никакие концепции или реализации не могут быть использованы от одного варианта использования к другому, вы почти наверняка используете по крайней мере некоторые шаблоны проектирования. Они могут не иметь ярких, распространенных имен, таких как «Репозиторий» или «Единица работы» или даже «MVC», но это не делает их «не шаблоном дизайна».

Мне обычно нравится думать об этом, скажем, о «навигации» с использованием GPS. Изучая «лучшие практики» и «шаблоны проектирования» - вы учитесь выбирать маршрут GPS-навигации. Но когда вы знаете район, вы часто узнаете, что езда по боковой дороге приведет вас к проблемным зонам, поможет вам быстрее и / или лучше. Это примерно то же самое, когда дело доходит до этих вещей - опыт позволяет вам разобраться в вашем наборе инструментов и использовать короткие пути.

Изучение шаблонов проектирования и изучение «лучших практик» означает, что вы получите представление об основополагающей идее, чтобы вы могли выбирать в данной ситуации. Поскольку реальные жизненные ситуации часто являются более сложными по сравнению с теоретическими ситуациями - у вас часто будут ограничения и проблемы, которых нет в учебниках. Клиенты / клиенты хотят, чтобы их продукт был быстрым и обычно дешевым; Вам нужно работать с устаревшим кодом; Вам необходимо взаимодействовать со сторонними инструментами, которые вполне могут быть черными ящиками и неэффективными; и все виды вещей. Ваша ситуация специфична - лучшие практики и шаблоны носят более общий характер.

Одна из основных причин того, что многие люди на таких сайтах, как SE, будут давать вам ответы «наилучшей практики» и «шаблона проектирования», заключается в том, что они отвечают общими и абстрактными решениями и, таким образом, помогают обеспечить общий язык для решения определенного типа. проблемы. И чтобы ты научился.

Таким образом, в средах Agile разработки шаблоны не допускаются; однако разработка редко бывает достаточно общей и абстрактной, чтобы идеально соответствовать шаблону, и (опытный) разработчик это знает.

Добавление нового поля в слой UI / database / Data занимает 2-3 часа, а в его коде - 30 минут.

Если вы хотите «оптимизировать» дизайн, вам нужно сказать, что вы пытаетесь оптимизировать.

Например, гоночный велосипед - это оптимизированное транспортное средство ... и Боинг 747 - это также оптимизированное транспортное средство ... но они оптимизированы для различных требований.

Например, идея шаблона «MVC» оптимизируется для таких вещей, как:

• Различные виды одной и той же модели (вид не зависит от модели)
• Каждый слой может быть разработан отдельно (например, разными командами) и протестирован отдельно (модульные тесты) перед интеграцией
• и т.п.

Принимая во внимание, что его код может быть оптимизирован для чего-то другого, например:

• Минимальные строки кода
• Легко для одного человека вносить изменения, которые влияют на все слои (не имея действительно отличных слоев вообще)
• и т.п.

Описания шаблонов начинаются с описания проблемы, которую шаблон должен решить. Если он думает, что это «лучшая практика» - не использовать конкретный шаблон, то (если предположить, что это не глупый шаблон, предположим, что этот шаблон иногда полезен), я полагаю, что у него нет / не возникает специфическая проблема, которую утверждает этот шаблон чтобы решить, и / или у него есть другая (большая или более срочная, конкурирующая) проблема, которую он вместо этого пытается оптимизировать.

Шаблоны проектирования - это инструменты. Как и у инструментов, есть два способа их использования: правильный и неправильный. Например, если я дам вам отвертку и гвоздь и попрошу соединить два куска дерева вместе, вы должны попросить у меня молоток. Молотки используются для гвоздей, а отвертки - для шурупов.

Слишком часто шаблон дизайна объявляется как Единый Истинный Путь, который часто верен только тогда, когда возникают определенные проблемы. Младшие разработчики часто похожи на детей, когда они находят что-то новое для игры; они хотят применить этот шаблон дизайна ко всему . И в этом нет ничего плохого, поскольку они в конечном итоге узнают, что шаблон A относится к проблеме B, а шаблон C относится к проблеме D. Точно так же, как вы не используете отвертку для забивания гвоздей, вы не используете конкретный шаблон только потому, что он существует; Вы используете шаблон, потому что это лучший (известный) инструмент для работы.

Обратная сторона шаблонов - это анти-шаблоны. Вещи, которые снова и снова оказываются плохими, обычно с точки зрения времени выполнения или памяти. Однако и шаблоны, и анти-шаблоны не приносят пользы разработчику, который не понимает, почему они существуют. Разработчикам нравится думать, что они делают что-то новое и изобретательное, но в большинстве случаев это не так. Скорее всего, об этом думали раньше. Люди до них создали шаблоны из-за опыта.

Конечно, начинающие разработчики часто, кажется, придумывают новые способы делать старые вещи, и иногда эти способы лучше. Однако, слишком часто это заканчивается случаем эффекта Даннинг-Крюгера; разработчик знает достаточно, чтобы сделать функциональную программу, но не понимает их собственных ограничений. Единственный способ преодолеть это, кажется, через опыт, как положительный, так и отрицательный. Они игнорируют шаблоны, потому что считают себя лучшими, но не знают, что на самом деле 10 000 разработчиков уже использовали конкретный дизайн, а затем отказались от него, потому что он действительно был плохим.

Agile поддерживает «быстрое выполнение задач» в отношении быстрой адаптации к меняющимся потребностям клиентов. Это не одобряет шаблоны проектирования и не презирает их. Если шаблон является самым быстрым и надежным методом, разработчик должен его использовать. Если конкретный шаблон будет стоить больше времени, чем просто «сделать это», то использование чего-то, что не является шаблоном, вполне возможно (при условии, конечно, что производительность не сильно снижается и т. Д.). Если ни одна из известных схем не может быть найдена, разработка собственной схемы предпочтительнее, чем сообщение клиенту «нет». Клиенты, особенно платящие, обычно правы.

Любой, кто утверждает, что шаблоны - это путь, или утверждает, что шаблоны - это проклятие существования, ошибается. Шаблоны - это инструменты, предназначенные для применения в конкретных ситуациях и имеющие различную степень успеха в зависимости от обстоятельств. Это Истина, которая не зависит от того, выбрали вы MVC или нет, используете ли вы объекты передачи данных, или нет, и т. Д. Что важно, так это реализация кода в достаточно короткие сроки, который достаточно хорошо работает для пользователей, и достаточно свободен от логических ошибок.

Обычно шаблоны допускают согласованную форму дизайна и работают лучше, чем игнорирование всех шаблонов в пользу написания 100% оригинальных идей, но вы не можете избежать всех шаблонов. Например, если y = x + 5, вы действительно собираетесь написать y = x + (5 * 3 + 15/3) / 4, просто чтобы избежать шаблона записи x + 5? Нет, ты не Вы собираетесь написать y = x + 5 и перейти к следующей проблеме.

Люди используют шаблоны каждый день, и это нормально . Больше всего важно иметь код, который логически функционален, редко дает сбой и удобен для пользователя. Ничто другое не имеет значения больше, чем это.

Вы не можете «избегать шаблонов проектирования», за исключением того, что я полагаю, избегая одинакового проектирования любых двух частей вашей системы (что я не рекомендую, и сомневаюсь, что ваш старший разработчик делает это). Вероятно, он имеет в виду «избегать слепого использования дизайна только потому, что он придерживается шаблона дизайна». Размышление о том, что вы делаете, определенно является «лучшей практикой», и один университет должен существовать, чтобы преподавать; к сожалению, этого не происходит.

Шаблоны проектирования не противоречат гибким методам. Что противоположно гибким практикам, так это использование шаблонов проектирования ради использования шаблонов проектирования, распространенная практика среди молодых выпускников и студентов для размышлений в духе «как мы собираемся решить эту проблему с использованием заводского шаблона».

Agile означает, что вы выбираете лучший инструмент для работы, а НЕ пытаетесь настроить работу под инструмент, который вы выбрали.
И это то, к чему сводятся ВСЕ практики разработки здравого смысла (хотя часто вам, конечно, приходится идти на компромиссы, потому что выбор инструментов, из которых вы можете выбирать, обычно ограничен корпоративными стандартами, лицензионными ограничениями (такими как GPL и иногда другие инструменты с открытым исходным кодом, часто не могут быть использованы, особенно при создании программного обеспечения для перепродажи), и тому подобное.

Ваш коллега / друг, вероятно, возражал против вашего кода не потому, что он использует шаблоны проектирования как таковые, а потому, что это искусственная конструкция, предназначенная для демонстрации использования определенного шаблона, когда другой дизайн был бы лучше (хотя часто субъективным, я (и многие со мной, без сомнения), видели множество примеров, когда принудительное использование определенного шаблона проектирования приводило к уродливому, сложному в обслуживании и крайне неэффективному коду).