Какой-нибудь совет для разработчика с учетом задачи по улучшению и рефакторингу критически важного приложения?

Question

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

Есть ноль единиц и ноль системных тестов. Логика взаимосвязана (а иногда дублируется без причины) между хранимыми процедурами, представлениями (да, я сказал представления) и кодом. Документация? Да правильно. Я боюсь. Да, очень свято делать даже самые минимальные из «настроек» или рефакторинга. Одна небольшая неудача, и у моего работодателя будут большие потери дохода и потенциальные юридические проблемы.

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

Answer 1

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

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

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

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

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

5. Изъять код отладки повсюду во время перезаписи - утверждения, ведение журнала, распечатки консоли (у вас должна быть возможность включать и выключать их, а также указывать различные уровни вывода, т. Е. Контролировать многословие). Это необходимо в моем опыте, и очень помогает при переписывании.

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

7. Старайтесь избегать взломов при переписывании (это одна из причин, по которой вы его переписываете). Подумайте о сложных проблемах, с которыми вы сталкиваетесь. Обсудите их с другими людьми, отразите ваши идеи против них (ничто не сравнится с этим) и внесите чистые решения. Посмотрите на все задачи, которые вы поместили в список задач - создайте картину существующего дизайна на 10 000 футов, затем решите, как будет выглядеть новое переписывание (с точки зрения модулей, подмодулей, как они сочетаются друг с другом и т. *

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

Answer 2

У меня была эта проблема раньше, и я спрашивал (до дней переполнения стека), и эта книга всегда рекомендовалась мне. http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

Answer 3

Две вещи, помимо большого списка @ Судханшу (и, в некоторой степени, не согласны с его # 8):

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

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

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

Answer 4

1. Получите очень твердый список требований.

2. Убедитесь, что у вас есть как явные, так и явные требования, т. Е. С какими программами он должен работать и как.

3. Напишите все сценарии и варианты использования для того, как он используется в настоящее время.

4. Напишите множество юнит-тестов.

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

6. Поговорите со всеми, кто использует программу, чтобы узнать более скрытые требования.

7. Тестирование, тестирование, тестирование изменений перед началом производства.

8. CYA:)

Answer 5

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

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

Удачи!

Answer 6

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

Answer 7

Задайте себе вопрос: чего вы пытаетесь достичь? Какова ваша миссия? Сколько времени у вас есть? Каково измерение успеха? Какие есть риски? Как вы смягчаете и справляетесь с ними?

Ничего не трогай, если не знаешь, чего пытаешься достичь.

Код может быть "плохим", но что это значит? Код работает правильно? Так что, если вы переписываете код так, чтобы он делал то же самое, вы потратили много времени на переписывание чего-то, вносящего ошибки в процессе, чтобы код делал то же самое? Для чего?

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