Кошмар унаследованного кода [закрывается]

Я работаю в аналогичной ситуации.

, Если это не маленькая утилита, а проект крупного предприятия тогда, это:

a) слишком поздно для фиксации его
b) вне возможностей единственного человека делать попытку a)
c) может только быть зафиксирован полной перезаписью материала, который является вне рассмотрения

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

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

РЕДАКТИРОВАНИЕ: Каждый раз, когда я пытаюсь обратиться к вопросу истинной архитектуры и выполнения вещей правильным путем, я обычно получаю LOL в своей поверхности непосредственно от ответственных менеджеров, которые говорят что-то как, "Меня не волнует хорошая архитектура" (предпринятый перевод из немецкого языка). Я лично принес один очень плохой компонент на грани non-hackability, в то время как, конечно, дававший усовершенствовал месяцы предупреждений заранее. Они тогда должны были отменить некоторые обещанные функции клиентам, потому что это не было выполнимо больше. Никто больше не касается его...

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

Первая вещь - получает исключение, входящее в приложение, если это уже не существует. Мы использовали FogBugz, и нам потребовался приблизительно месяц для получения создания отчетов, интегрированного в наше приложение; это не было прекрасно сразу же, но это сообщало об ошибках автоматически. Обычно довольно безопасно реализовать блоки try-catch во всех Ваших событиях, и это покроет большинство Ваших ошибок.

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

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

Одна вещь отнять это - то, что это - большой опыт. Это будет печально, но Вы изучите много.

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

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

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

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

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

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

Главным образом это звучит довольно плохим. Но я не понимаю эту часть:

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

, Который звучит достаточно близким к способу, которым я часто пишу вещи. Что случилось с этим? Каков корректный путь?

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

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

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

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

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

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

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

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

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

Посмотрите сообщение в блоге Анатомия Антикоррупционного Слоя, Анатомия Части 1 и Антикоррупционного Слоя, Часть 2 .

, Это цитирует Eric Evans, Управляемый Доменом Дизайн: Занятие Сложностью в самом центре программного обеспечения :

Получают доступ к дерьму позади фасада

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

таким образом, все - или 'противный старый материал' или 'хороший новый материал'. Одна сторона строки или другого.

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

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

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

Удача, которая является жесткой частью того, чтобы быть разработчиком.

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

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

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

Вы могли бы найти следующее сообщение полезным: http://refactoringin.net/?p=36

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

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