Рефакториться безжалостно или создать один, чтобы выбросить?

Question

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

- Фред Брукс, Мифический человеко-месяц [Выделение мое]

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

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

Answer 1

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

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

Answer 2

Выбрасывай рано, рефакторинг позже

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

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

Answer 3

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

Answer 4

Одним из центральных моментов Мистического Месяца Человека было то, что сложная часть разработки программного обеспечения состоит в том, чтобы понять, что сказать, а не как это сказать.

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

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

Answer 5

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

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

Answer 6

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

С уважением

Answer 7

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

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

Answer 8

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

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

TL; DR: Вы можете избавиться от большинства неприятностей. Тем не менее, иногда вы не сможете изменить некоторые элементы дизайна. Когда это произойдет, пришло время начать все сначала - хотя, надеюсь, вы сможете повторно использовать некоторые из имеющихся у вас компонентов.

Answer 9

В более позднем эссе в «Мифическом месяце человека» Брукс предупреждает, что он обнаружил, что если вы действительно планируете выбросить 1, вы в конечном итоге выбросите 2!

Я лично видел, как это происходило в реальной жизни; мы определили версию 1 проекта как быструю замену посредственному программисту, потому что «мы планируем выбросить ее позже - мы все равно будем». В итоге нам пришлось переписать его для версии 2, но эту версию тоже выбросили. Я никогда не видел версию 3 - компания обанкротилась.

Я думаю, что когда Брукс говорит: «Планируй выбросить, ты все равно будешь», это больше похоже на утверждение «количество найденных ошибок -« n + 1 »». То есть это серьезное утверждение о законе Мерфи, а не практический совет. Уроки, которые можно извлечь из этого, состоят в том, что прототипы ценны, хорошая письменность - это переписывание, и не бойтесь отказаться от того, что не работает.

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

Answer 10

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

Например, я написал большую кодовую базу на Ruby on Rails, и за последние 2-3 года RoR значительно продвинулся вперед. Я также принял некоторые решения в архитектуре, которые нужно было исправить. Итак, я выбрасываю один и строю новый с нуля. Тем не менее, я все еще могу использовать 70-80% моего старого кода, так как я все еще пишу на Ruby и Rails.

Основным фактором, который помог в этом, является то, что Rails заставляет вас писать хорошо структурированный код с разделением бизнес-логики и уровней представления. В первый раз я не достиг совершенства, но, поскольку все довольно хорошо разделено и DRY, перенос кода на Rails v2.1, реорганизация проблемных областей и переписывание некоторых «проблемных» функций стали довольно безболезненный опыт.

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