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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

См. Рэндс в теории струйки Repose для аналогичной проблемы, с которой он столкнулся с огромным количеством ошибок. Его рекомендация:

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

Answer 5

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

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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

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

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

Answer 10

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