Осуществить рефакторинг беспощадно или создать для выбрасывания?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С наилучшими пожеланиями

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

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

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

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

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

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

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

я думаю, когда Brooks скажет "план выбросить один, Вы будете так или иначе", он больше похож на оператор "количество ошибок, остающихся быть найденными, 'n+1'". Таким образом, это - ha-ha-only-serious оператор о законе Murphy's, а не практический совет. Уроки для отнимания у него - то, что прототипы ценны, хорошая запись переписывает, и не бойтесь отказаться от чего-то, что не работает.

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

Я думаю, что ваша система контроля версий играет здесь большую роль. Если вы запустите распределенную систему управления версиями с легким ветвлением (в наши дни git, mercurial), тогда вы сможете проще создавать прототипы и проще проводить рефакторинг, при этом все еще имея действующую рабочую копию. Все остальное требует гораздо большей дисциплины.

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

Я (ab) использую это правило, чтобы выбить быстрый, грязный проверочный код, который решает ту или иную точку преткновения, затем я проверяю его в системе контроля версий, указываю на него «правильному» разработчику и говорю: « Вот как это делается, теперь сделайте это правильно »

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

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

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

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

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

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

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

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

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