Управление регрессией

Question

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

Итак, мой вопрос: если вы поддерживаете существующий код, как вы охватите все основы и убедитесь, что не оставляете выбоины? Какие стратегии вы используете, когда не знаете, где код может сломаться?

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

Это не доказательство, но лучше, чем ничего!