Совет для разработчика, учитывая задачу улучшения и рефакторинга критически важного для бизнеса приложения?
Недавно я наследовал критически важный для бизнеса проект на работе для "улучшения". Код работался на и проходился, многие передают прошлые пять лет. Консультанты и штатные сотрудники, которые больше не являются с компанией, забили это очень тонкое и чрезмерно чувствительное приложение. Большинство из нас должно иметь дело с унаследованным кодом или этим типом проекта... его часть того, чтобы быть разработчиком..., но...
Существуют нулевые единицы и обнуляют тестирование системы. Логика смешивается (и иногда не дублируется ни по какой причине) между хранимыми процедурами, представления (да, я сказал что представления), и код. Документация? Да, право. Я боюсь. Да, очень священный, чтобы сделать даже самую минимальную из "тонкой настройки" или осуществить рефакторинг. Одна небольшая неудача, и была бы крупной доходной потерей и потенциальными юридическими вопросами для моего работодателя.
Так, совет? Моя первая мысль состояла бы в том, чтобы начать писать утверждения/модульные тесты против существующего кода. Однако это может только пойти до сих пор, потому что существует большая логика, встроенная в хранимые процедуры. (Я знаю, что ее возможное тестирует хранимые процедуры, но исторически его намного более трудное по сравнению с логикой исходного кода поблочного тестирования). Другой или дополнительный подход должен был бы сравнить состояние базы данных прежде и после того, как приложение выполнило функцию, вносит некоторые изменения кода, затем сделайте состояние базы данных выдерживает сравнение.
7 ответов
Я просто переписал тысячи линий самой сложной подсистемы корпоративной файловой системы, чтобы сделать ее многопоточной, поэтому все это исходит от опыта. Если перезапись оправдана (именно в том случае, если переписывание делается для значительного повышения возможностей, или если существующий код наступает на пути ввода в размере большего количества улучшений), то вот указатели:
Вы должны быть уверены в Ваши собственные способности прежде всего делать это. Это приходит только в том случае, если у вас достаточно предыдущего опыта работы с вовлеченными технологиями.
Общаться, общаться, общаться. Пусть все вовлечены владельцы заинмиер, это беспорядок, это рискованно, это не может быть сделано в спешке, это нужно будет делать кусок - приступить к одной области за раз.
Поймите систему наизнанку. Документируйте каждый нюанс, трюк и взломать. Документируйте общий дизайн. Спросите любые старики об исторических причинах существования любого кода, который вы не можете оправдать. Это мины, которые вы не хотите наступать - вы можете подумать, что это бесполезные кусочки кода, а затем сожалеют позже после избавления от них.
тест на единицу. Работайте системой через любой тестовый набор, который уже существует, в противном случае сначала напишите тесты для существующего кода, если они не существуют.
Проверяйте код отладки по всему месту во время перезаписи - утверждает, ведение журнала, консоли (у вас должна быть возможность включать и выключать их, а также указывать разные уровни вывода I.E. Verbity). Это обязательно в моем опыте, и чрезвычайно помогает во время перезаписи.
При прохождении кода сделайте список всех, которые необходимо сделать - вещи, которые вам нужно выяснить, вещи, которые вам нужно написать тесты, вещи, которые вам нужно задать вопросы, отмечает, как напомнить вам, как Refactor Некоторый код кода, все, что может повлиять на ваш перезапись ... Вы не можете позволить себе что-нибудь забыть! Я делаю это, используя задачи Outlook (просто убедитесь, что все, что вы используете, всегда перед вами - это первое приложение, которое я открытую, как только я сажусь на столом). Если я прерванию, я записываю все, о чем я думал, и намекает на то, куда продолжать после возвращения к задаче.
Попробуйте избежать взлома в вашем перезаписи (это одна из причин, по которым вы его переписываете). Подумайте о жестких проблемах, которые вы столкнулись. Обсудите их с другими людьми и отскакивают свои идеи против них (ничто не сравнится), и поставить в чистые решения. Посмотрите на все задачи, которые вы помещаете в список Todo - создайте 10 000 футов, изображение существующего дизайна, а затем решить, как будет выглядеть новое перезапись (с точки зрения модулей, подмодулей, как они подходят вместе и т. Д.).
решать самые сложные проблемы перед любым другим. Это спасет вас от пробега в проблемы, вы не можете решить рядом с концом туннеля и сэкономить вас от приема каких-либо шагов назад. Конечно, вам нужно знать, какие самые сложные проблемы будут - так опять же, лучше задокументировать все сначала во время наличия в существующий код.
Получите очень точный список требований.
Убедитесь, что у вас есть неявные и явные требования, то есть с какими программами он должен работать и как.
Напишите все сценарии и варианты использования того, как он используется в настоящее время.
Напишите много модульных тестов.
Напишите множество интеграционных тестов, чтобы проверить интеграцию программы с существующими программами, с которыми она должна работать.
Поговорите со всеми, кто использует программу, чтобы узнать больше неявных требований.
Тестируйте, тестируйте, тестируйте изменения перед запуском в производство.
CYA :)
Спросите себя: чего вы пытаетесь достичь? Какая у вас миссия? Сколько у тебя есть времени? Что является критерием успеха? Какие есть риски? Как вы смягчаете их и боретесь с ними?
Не трогайте ничего, если не знаете, чего пытаетесь достичь.
Код может быть «плохим», но что это значит? Код работает правильно? Итак, если вы переписываете код так, чтобы он выполнял то же самое, вы потратили много времени на переписывание чего-то, что приводило к появлению ошибок, чтобы код делал то же самое? С какой целью?
Самое простое, что вы можете сделать, - это задокументировать, что делает система. И я не имею в виду писать ошеломляющие документы Word, которые никто никогда не прочитает. Я имею в виду написание тестов на ключевую функциональность, рефакторинг кода, если необходимо, чтобы можно было писать такие тесты.
/^ www/ позволяет проверить, начинаются ли темы с www .
Вы также можете прочитать « Почему методы getter и setter являются злыми »:
-121--725562-Хотя методы getter/setter являются обычным явлением в Java, они не являются особенно объектно-ориентированными (OO). Фактически, они могут повредить ремонтопригодность кода. Кроме того, наличие многочисленных методов получения и установки является красным флагом того, что программа не обязательно хорошо разработана с точки зрения ОО.
В этой статье объясняется, почему вы не должны использовать приемники и установщики (и когда вы можете использовать их), и предлагается методология проектирования, которая поможет вам вырваться из менталитета получателя/установщика.
Две вещи, помимо великого списка @ Sudhanshu (и, в некоторой степени, несогласия с его # 8):
Во-первых, имейте в виду, что непроверенный код является кодом багги - то, с чего вы начинаете, почти наверняка, работает неправильно, ибо любое определение «правильного», кроме «работает так же, как и немодифицированный код». То есть будьте готовы найти неожиданное поведение в системе, спросить экспертов в системе о таком поведении, и чтобы они пришли к выводу, что оно работает не путь должно. Подготовьте их , чтобы они предупредили, что без тестов или другой документации нет причин думать, что это работает, пути они думают, что это работает.
Далее: Рефактор Низко висящий плод Легко, медленно, очень осторожно. Заметьте что-то легкое в коде - дублирование, скажем - и проверьте к черту, какие методы содержат дублирование, а затем устраните его. Клер, полоскай, повторяй. Не пишите тесты для всего, прежде чем вносить изменения, а пишите тесты для того, что вы меняете. Таким образом, он остается съемным на каждом этапе, и вы постоянно добавляете ценность, непрерывно улучшая базу кода.
Я сказал «две вещи,» но я думаю, что добавлю третью: управление ожиданиями. Сообщите клиенту, насколько вы боитесь этой задачи; дайте им знать, как плохо то, что у них есть. Дайте им знать, насколько медленным будет прогресс, и дайте им знать, что вы будете держать их в курсе этого прогресса (и, конечно, сделать это). Ваш клиент может думать, что он просит «просто немного исправить» - и функциональность действительно может измениться лишь немного - но это не означает, что это не будет много работы и много времени. Ты это понимаешь; ваш клиент тоже должен.
Вы говорите, что вы напуганы, чтобы коснуться кода из-за юридических, потерь доходов и что есть нулевая документация. Так ты понимаешь код? Первое, что вы должны сделать, это документировать его и убедиться, что вы понимаете его, прежде чем даже думать о рефакторинге. После того, как вы сделали это и определили проблемные области, составляют список предложений по рефакторингу в порядке максимальной выгоды с минимальными изменениями и атаковать его постепенно. Рефакторинг имеет дополнительный смысл, если: ожидаемая продолжительность жизни кода будет длинными, будут добавлены новые функции, исправления ошибок многочисленны. Что касается тестирования состояния базы данных - я недавно работал над проектом, где именно то, что мы сделали с успехом.
У меня была эта проблема раньше, и я спросил вокруг (до нескольких дней переполнения стека), и эта книга всегда рекомендовала мне. http://www.amazon.com/working-effective-legacy-michael-feathers/dp/0131177052
Можно ли получить разделение деталей БД и не БД, так что DBA может принять задачу хранимых процедур и сами базы данных освобождая вас на работу над другими частями системы? Это также предполагается, что есть DBA, который может активизировать и принимать эту часть приложения.
Если это невозможно, то я бы сделал предложение о том, чтобы увидеть, насколько велика была кодовая база, и если можно получить некоторую помощь, так что это не все на вас. Хотя это можно рассматривать как ответственность на боковую ответственность, точка была бы то, что вещи не должны быть только в руках одного человека, как правило, поскольку они могут исчезнуть иногда.
Удачи!