Вопрос по refactoring, unit-testing, testing – Что бы вы сделали, когда собираетесь добавить некоторые новые функции в большую (и грязную) кодовую базу, которая содержит практически * НЕТ * код модульного тестирования?

9

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

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

Но это'большая база кода. Добавление полного набора тестов кажется неосуществимым.

Что бы вы сделали в этом случае?

Ваш Ответ

14   ответов
0

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

3

Дон»не думаю об этом какили / или предложение. Существует добавленная стоимость, добавив модульные тесты - вы неЧтобы получить преимущества от добавления некоторых тестов, нужно добавить целый пакет.

11

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

3

Я нахожусь в такой ситуации довольно часто, так какв значительной степени то, что яя застрял в течение последних двух лет.

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

Ожидаемое право собственности на рассматриваемый проект. Если вы ожидаете, что станете значительной заинтересованной стороной в этом конкретном программном обеспечении в обозримом будущем, это 's аргумент в пользу внесения более обширных модификаций в плохую базу кода b / c it 'Я буду платить больше, если вы будете поддерживать его в будущем. Если ты'добавив функцию «Drive-by», выберите более практичный подход.

Сложность вносимых изменений. Если ты'вносить очень сложные изменения в кодовую базу (типичный случай вгрязный» codebase, b / c такой источник обычно тесно связан и непоследователен), скорее всего, потребуется некоторый рефакторинг. Таких изменений нетт результат быть ниндзя кода, так как ониВам необходимо простопричина об изменениях, которые выделает заново. Это также связано свредность» кодовой базы выповторная модификация. Это'Практически невозможно создать даже простейшие юнит-тесты для тесно связанного, невосприимчивого беспорядка. (Я говорю по опыту. Один из проектов, которые я почти застрял, занимал около 20 тыс. Строк, исключая сгенерированный код, в двенадцати файлах. Все приложение представляло собой один класс под названием "Form1", Это пример того, как разработчик злоупотребляет функцией частичного класса.)

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

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

Основной вопрос, на который вам нужно ответить при рассмотрении любого вида временных вложений, подобных этому, "Где лежит ценность? Тогда вам нужно преследовать это значение.

10

Добавьте модульные тесты в код, который вы собираетесь использовать в Refactor.

Да, вы должны сделать это, чтобы предотвратить регресс. Старый, уродливый код может быть трудным для понимания, не позволяя вам избежать каких-либо побочных эффектов при изменении, которое выделает заново. Недостатком является то, что вы можете в конечном итоге найти и исправить тайные, скрытые ошибки в существующем коде! Ateş Göral
Старый код часто тесно связан, что затрудняет добавление тестов. Книга Ларса А. Бреккена рекомендует непосредственно обратиться к этому и предлагает "safeish» способы развязки. JeffH
+1. Обычно вы можете создать тест, чтобы подтвердить, что вы не меняете поведение (даже если вы нене знаю, является ли текущее поведение тем, что было изначально задумано.) finnw
2

Фаулер также предлагает, чтобы вы никогда не рефакторинг без безопасности испытаний. Но как вы получите эти тесты на месте? И как далеко вы идете?

Ранее рекомендованная книга (Эффективная работа с устаревшим кодом Майкл Фезерс) является окончательной работой на эту тему.

Нужно быстрее прочитать? Посмотри на Майклараньшестатья (PDF) с тем же именем.

+1 за ФаулераПредложение не проводить рефакторинг без тестов. JeffH
Мы уже позаимствовали книгу из библиотеки. Это'хорошее чтение Спасибо вам, ребята! Owen
2

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

Если оно'хороший объем работы (пустьскажем, человек в год или 3 человека в течение 4 месяцев) тогда вы, вероятно, захотите, чтобы кто-то разорвал код и сначала проанализировал его.

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

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

5

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

Модульные тесты - отличный сервис для программиста, но онине единственный вид тестирования там.

2

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

9

УвидетьРэндс в состоянии покояТеория Трикла за подобную проблему он столкнулся с огромным количеством ошибок. Его рекомендация:

Мой совет: СТАРТ

Если добавление набора тестов нецелесообразно,т. Делай, что можешь, но не делайне быть парализованным страхом за то, что вы можетет изменить. Clinton Pierce
Всегда хорошо читаю Rob Allen
1

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

14

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

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

1

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

Добавление нового кода инадеясь Это просто работает плохо.

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

Это довольно наивно. Кодовая база может быть огромной, старой и беспорядочной, но это незначит, это не таку меня нет никаких испытаний. Если оно'используется, и клиенту это нравитсяправильно. Clinton Pierce
0

коснись как можно меньше. И молись.

Похожие вопросы