Я только что прочитал ссылку на статью, которую вы опубликовали, и должен сказать, что Фаулер сделал несколько очень хороших замечаний и много чего сказал, я выступал за нашу команду в течение многих лет.
ИМО, если вы делаете какой-то приличный дизайн, вы не должны попадать в то, что считается тупиковой ситуацией. Я всегда рассматривал программное обеспечение как составную часть строительных блоков . Я все еще верю в какой-то предварительный дизайн, но главная цель не в разработке всего продукта, а в обеспечении общей архитектуры / направления, чтобы ваша команда могла визуализировать общую картину, над которой мы все работаем. Если у вас есть куча кусочков куба и треугольника, полезно набросать, как будет строиться замок, прежде чем просто начать складывать кусочки вместе.
Поскольку я пришел из ОО-земли, для меня каждый блок является классом, а площадь поверхности этого блока является открытым интерфейсом (что видно внешним или производным классам). Если вы будете следовать хорошим принципам SOLID, вы убедитесь, что каждый блок максимально прост и имеет интуитивно понятный общедоступный интерфейс. Возвращаясь к моей аналогии, вы хотите убедиться, что ваш код создает только простые фигуры. Всякий раз, когда вы создаете слишком сложные классы (много функций, много переменных), вы создаете фигуры, которые сложно использовать при изменении требований.
Я согласен с Фаулером в том, что наибольший риск / проблема для эволюционного дизайна заключается в том, что вы оставляете проектные решения на время написания кода и ожидаете, что каждый отдельный разработчик примет эти решения. Это где система может сломаться, если у вас нет надлежащих механизмов обратной связи на месте. Всякий раз, когда запрашивается новая функция, крайне заманчиво просто найти функцию, которую нужно расширить, поместить в нее какую-то условную форму и просто добавить целый набор кода прямо внутри этой функции. И иногда, это может быть все, что нужно, но это также (ИМО) единственная наиболее распространенная практика, которая приводит к тупиковым компонентам. Это не имеет ничего общего с эволюционным дизайном. Это то, что называется «без дизайна».
Если вы потратите время на то, чтобы отступить и сказать: подождите минуту, в этом классе уже есть 15 переменных-членов, позвольте мне извлечь 6 из них и поместить в их собственный автономный класс, ваше программное обеспечение будет очень легким. легкие, гибкие и многоразовые строительные блоки. Конечно, если премьер-министры приходят и меняют половину требований к продуктам, вам, возможно, придется вынуть некоторые из своих блоков, положить их обратно на полку и собрать некоторые новые (как при строительстве замка, вы можете не использовать все ваши цилиндры). Но в этот момент это просто часть ведения бизнеса. Требования изменились, и благодаря тому, что ваш код будет гибким и модульным, вы сможете изменить свой продукт в соответствии с новым бизнес-направлением.
Я считаю, что этот эволюционный подход к дизайну работает с каждым уровнем квалификации инженера. Лично я занимался программным обеспечением в течение очень долгого времени, и до того, как наша команда перешла на гибкую методологию, я отвечал за доставку нескольких основных компонентов с моего ПК разработчика почти напрямую клиенту практически без какого-либо контроля качества. В то же время эти компоненты всегда оставались гибкими и ремонтопригодными.
Я только пытаюсь сказать, что считаю себя достаточно приличным в разработке программного обеспечения. В то же время, если бы вы попросили меня написать 100-страничный проектный документ, передать его кодировщику и ожидать, что он будет работать, я, вероятно, не смогу оформить себя из бумажного пакета. Приступая к работе, я иногда набрасывал несколько UML-подобных (очень упрощенных, не полноязычных) диаграмм, но, как только я начну кодировать, я буду рефакторинг по мере необходимости, и мой окончательный код никогда не будет выглядеть так, как я нарисовал изначально. Даже если я потрачу месяц или два на размышления о каждой мелочи, я не могу представить, чтобы кто-то еще мог взять мои диаграммы и придумать солидную часть программного обеспечения, не изменяя дизайн, поскольку они кодируют.
На другом конце спектра, в настоящее время в моей команде (сейчас это гибко, и я полностью поддерживаю это), у нас есть пара парней, которые присоединились к нам со встроенной земли, где они только делали C в течение последних 15 лет. Я, очевидно, помог с некоторым начальным планированием и планированием классов, но я также удостоверился, что продолжу проводить регулярные обзоры кода и мозговые штурмы, где мы обсуждаем приложения SOLID и принципы проектирования. Они действительно произвели некоторый код спагетти, который заставил меня немного съежиться, но с небольшим толчком от меня, они начали рефакторинг того, что уже было произведено, и забавно то, что один из них вернулся ко мне несколько дней спустя и сказал, что я ненавижу сказать это, но после перемещения этого кода, это выглядит намного более читабельным и понятным. Тупик предотвращен. Точка I ' Я пытаюсь сделать так, чтобы даже тот, кто совершенно не знаком с ОО, мог создавать несколько приличный код, если у него есть наставник с большим опытом, чтобы напомнить ему, что «эволюционный дизайн» - это не то же самое, что «отсутствие дизайна». И даже некоторые из его «более сложных» классов не так уж страшны, потому что каждый класс не несет такой большой ответственности (т.е. не так много кода), так что худшее становится хуже, если этот один класс «тупиковый», мы бросьте его и напишите класс замены, который имеет такой же общедоступный интерфейс (до сих пор я никогда не видел необходимости в этой непредвиденной ситуации во всем, что мы писали, и я делал обзоры кода два раза в неделю).
В заключение, я также твердо верю в проектные документы (по крайней мере, для бизнес-условий моей текущей команды), но основная цель для наших проектных документов - Организационная память , поэтому фактические документы пишутся после того, как код произведен и переработан. Перед кодированием у нас обычно есть быстрая (иногда не такая быстрая) фаза проектирования, когда мы набрасываем классы на салфетках / mspaint / visio, и я всегда напоминаю людям, что эта фаза дает путь, а не план, и когда они начинают кодировать, все, что не имеет смысла, должно быть изменено. Даже с этими напоминаниями новые парни стараются втиснуть код в оригинальный дизайн, независимо от того, насколько это неестественно для них. Это обычно появляется в обзорах кода.
Черт, я много писал. Прости за это.