Когда хорошо (если когда-нибудь) фрагментировать производственный код и запуститься? [закрытый]

Когда код достиг точки, которая не удобна в сопровождении или больше расширяема. Полно краткосрочного hacky, фиксирует. Это имеет большую связь. Это имеет долго (100+lines) методы. Это имеет доступ к базе данных в UI. Это генерирует много случайных, невозможных для отладки ошибок.

Нижняя строка: При поддержании это более дорого (т.е. занимает больше времени), чем перезапись его.

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

существует много недостатков для опасаний.

• Перезаписи мешают новым возможностям быть разработанными холод в течение многих месяцев/годы. Немногие, если какие-либо компании могут предоставлять бездействию для этого долго.
• Большинство графиков разработки является трудным к гвоздю. Эта перезапись не будет никаким исключением. Усильте предыдущую точку, теперь, задержка разработки.
• Ошибки, которые были исправлены в существующей кодовой базе через болезненный опыт, будут повторно представлены. У Joel Spolsky есть больше примеров в эта Опасность для статьи .
• пасть жертвой эффект Второй системы - таким образом, ''Люди, которые разработали что-то только однажды, пытаются сделать все вещи, которые они "не получили, чтобы сделать в прошлый раз", загрузив проект всеми вещами, которые они откладывают при создании версии один, даже если большинство из них должно быть испугано в версии два также''.
• , Как только эта дорогая, обременительная перезапись завершается, очень следующая команда, которая наследует новую кодовую базу, вероятно, будет использовать те же оправдания за то, что сделали другую перезапись. Программисты очень не хотят изучить чужой код. Никто не пишет идеальный код, потому что совершенство таким образом субъективно. Найдите меня любым реальным приложением, и я могу дать Вам заслуживающий осуждения обвинительный акт и объяснение для того, чтобы сделать с нуля перезапись.

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

Я собираюсь отправить эту книгу каждый раз, когда я вижу обсуждение Рефакторинга. Все должны считать "Работу Эффективно с Унаследованным кодом" Michael Feathers. Я нашел, что он был превосходной книгой - если ничто иное, это - забавное чтение, и мотивационный.

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

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

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

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

программное обеспечение работает хорошо с потребительской точки зрения? (Если да быть очень осторожным относительно изменений). Я думал бы, что будет мало точки re-witting, если Вы не разворачивали набор функций, если система работала. И Вы планируете развернуть функции и клиентскую базу программного обеспечения? Раз так тогда у Вас есть намного больше причины измениться.

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

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

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

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

Я полностью никогда не выводил код. Идя от системы FoxPro до c# системы.

, Если старая система работала тогда, почему просто выводят его?

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

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

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

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

, Когда хорошо (если когда-нибудь) фрагментировать производственный код и запуститься?

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

Я думаю, что правило было...

• первая версия всегда является броском далеко

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

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

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

В прошлом, когда специалист по обслуживанию получил новый код для поддержания, эмпирическое правило было, "Если необходимо измениться больше чем на 40 процентов чужого кода, Вы выводите его и запускаетесь". Индекс пригодности для обслуживания [MI], обращенный здесь, дает намного больше измеримого метода для определения, когда "вывести его и запуститься". Эта работа спонсировалась американским Центром Войны информации о Военно-воздушных силах и американским Министерством энергетики [DOE], Филиалом Айдахо, Контрактом № DE-AC07-94ID13223 DOE.)

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

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

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

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

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

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

Фрагментируйте старый код рано и часто. Когда в сомнении, выведите его. Твердая часть убеждает нетехнических людей cost-maintain.

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

Помнят, инвестиции в перезапись однажды только. Возврат на инвестициях в перезапись длится навсегда. Навсегда .

Фокус вопрос о значении вниз конкретным вопросам. Вы перечислили набор их выше. Палка с этим.

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

• "Мы получим больше значения от отбрасывания спама, это ненадежно и повреждения?"

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

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

• "Это повреждается?" И когда Вы говорите, что "Это не , отказал как таковой", Они скажут, что "Это не, повредился - не фиксируют его".

• "Вы сделали анализ кода, Вы понимаете его, Вы больше не должны фиксировать его".

, Что Ваш ответ им?

Это - только первое препятствие. Вот худшая ситуация. Это не всегда происходит, но это действительно происходит с пугающей частотой.

у Кого-то в Вашем исполнительном foodchain будет эта мысль:

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

проект А, где объем расширен - искусственно - для увеличивания стоимость, обычно обрекается.

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

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

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

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

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

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

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

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

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

, Но, на основе codereview, не кажется, что были бы любые чистые границы.

Я думаю, что строка в песке - когда базовое обслуживание берет на 25% - 50% дольше, чем это должно. Там прибывает, время при поддержании унаследованного кода становится слишком дорогостоящим. Много факторов способствуют окончательному решению. Время и стоимость, являющаяся наиболее важными факторами, я думаю.

Два потока мысли об этом: у Вас есть исходные требования? Вы уверены, что исходные требования точны? Что относительно планов тестирования или модульных тестов? Если у Вас есть те вещи на месте, это могло бы быть легче.

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

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

• у Вас уже есть клиенты, использующие его. Они знакомы с ним и, возможно, создали некоторые свои собственные активы вокруг этого. (Другие системы, которые взаимодействуют через интерфейс к нему; продукты на основе его; процессы они должны были бы измениться; штат они должны были бы, возможно, переобучиться). Все это стоит потребительских денег.
• Перезапись это могло бы стоить меньше в долгосрочной перспективе, чем внесение трудных изменений и фиксирует. Но Вы еще не можете определить количество этого, если Ваше приложение не не более сложно, чем Привет Мир. И перезапись означает перетест и повторно развертывание, и вероятно процедуру обновления для Ваших клиентов.
• , Кто говорит, перезапись будет немного лучше? Можно ли честно сказать, что фирма пишет блестящий код теперь? Имейте методы, которые повернули исходный код к спагетти, исправленный? (Даже если основной преступник был единственным разработчиком, где были его коллеги и управление, гарантируя качество через обзоры, тестирование, и т.д.?)

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

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

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

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

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

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

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

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

Быть очень осторожным с этим:

1. Вы уверенный, что Вы только ленивы и не потрудились читать, код
2. Вы являющийся высокомерным о большом коде, который Вы запишете по сравнению с мусором, который кто-либо еще произвел.
3. Помнят, что тестируемый работавший код стоит намного больше, чем мнимый код yet-to-be-written

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

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

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

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

На самом деле фрагментировать и запуститься?

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

я уверен, что кто-то теперь свяжет статью Joel о Netscape, выбрасывая их код и как это - oh-so-terrible и огромная ошибка. Я не хочу говорить об этом подробно, но если Вы действительно связываете ту статью, прежде чем Вы сделаете так, рассмотрите это: механизм IE, механизм, который позволил MS выпускать IE 4, 5, 5.5, и 6 в быстрой последовательности, механизм IE, который полностью уничтожил Netscape..., это было новым. Трайдент был новым механизмом после того, как они выбросили механизм IE 3 , потому что это не обеспечило подходящее основание для их будущей технической разработки . MS сделал это, которое Joel говорит, что Вы никогда не должны делать, и это , потому что мс сделала так, чтобы у них был браузер, который позволил им полностью затмевать Netscape. Таким образом... просто размышляйте на той мысли на мгновение, прежде чем Вы свяжете Joel и скажете, "о, что Вы никогда не должны делать этого, это - ужасная идея".

Я раньше верил в просто перезапись с нуля, но это неправильно.

http://www.joelonsoftware.com/articles/fog0000000069.html

Передумал.

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