Является ли дизайн сейчас подмножеством рефакторинга?

Question

Глядя на крутые новые принципы разработки программного обеспечения:

• Проворный
• Вам это не нужно
• Меньше конкурентного преимущества
• Разработка, ориентированная на поведение
• зло преждевременной оптимизации

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

Я не прав?

Answer 1

Я бы сказал, что это так, как вы описываете, - это путь к катастрофе, но я все равно рекомендовал бы сделать общий дизайн заранее. Конечно, во время проекта вам нужно будет изменить дизайн, он никогда не будет каменным, гибкость необходима! (Вот где рефакторинг должен войти). Я также рекомендовал бы сделать более детальный дизайн для модуля непосредственно перед тем, как вы начнете кодировать его.

Но солидный общий дизайн ценится на вес золота: он дает всем разработчикам общую основу для начала, общую идею или, возможно, видение цели.

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

Answer 2

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

Answer 3

Неправильно? Частично.

«Ваша кодовая база растет постепенно и никогда не имеет большой стадии планирования / иерархического проектирования».

Correct.

«Для меня это говорит о том, что разработка программного обеспечения (хотя и достойная) была включена в рефакторинг…»

Не совсем правильно.

Существует огромная пропасть между Big Design Up Front (BDUF) и более гибким подходом к дизайну.

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

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

Дизайн все еще король. Agile Design лучше, чем монолитный дизайн.

Следствием Agile Design являются YAGNI, DRY и Less-is-More. Они не заменяют дизайн, а являются следствием того, как вы расставляете приоритеты и делаете дизайн.

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

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

Agile должен помочь вам сфокусироваться на общей картине: Что на самом деле люди будут делать с настоящим программным обеспечением и избегать дыр в технологиях.

Это не заменяет инженерию. Это перефокусирует это.

Answer 4

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

Дизайн на сегодня, код на завтра .

Answer 5

напоминает мне следующую цитату:

Цель - чистый код, который работает. [...] Сначала мы решим часть проблемы, которая «работает». Тогда мы решим часть «чистого кода». Это противоположность архитектурно-ориентированной разработке, где вы сначала решаете «чистый код», а затем пытаетесь интегрировать в проект то, что вы изучаете, когда решаете проблему «что работает». (Кент Бек, «Пример TDD»)

Answer 6

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

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

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

Answer 7

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

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

Я не прав?

ИМХО, довольно много.

Редактировать: Причина, по которой я принимаю много проектных решений на ранних этапах процесса, а не в середине процесса, заключается в том, что это часто может быть самым дешевым временем для этого. Например, если мы начнем писать приложение с использованием технологии, зависящей от платформы, это может оказаться очень дорогим решением. Если мы уделим время рассмотрению платформ, которые мы хотим поддерживать, прежде чем начинать кодировать, это будет намного дешевле. Мы не можем и не будем все делать правильно с первого раза, но это не освобождает нас от обязанности изучать все важные варианты дизайна. Каждый пробовал рефакторинг программы MS MDI в MVC? Я имею, и не рекомендовал бы это;)

Answer 8

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

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

Answer 9

Посмотрим, сможем ли мы получить определение. Я собираюсь предположить, что может быть книга, на которую мы могли бы ссылаться. Как насчет Мартина Фаулера ?

«Рефакторинг: улучшение дизайна существующего кода»

Теперь давайте возьмем в качестве примера мантру TDD:

пока не закончите, сделайте

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

конец

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

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