По ту сторону кодинга

Алексей Башкеев

Спецвыпуск: Хакер, номер #053, стр. 053-068-3

Юнит-тесты

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

Иногда, меняя один из модулей программы, ты каким-то неявным образом затрагиваешь другой. И при этом можно потратить уйму времени на поиск "того, из-за чего все не работает". В ХП в этом случае запускаются юнит-тесты. Они выявляют те модули, которые работают с ошибками и облегчают процесс их поиска. К тому же когда в команду вливается новый человек, ему может быть полезно убедиться, что изменения, которые он внес, не изменили целостности всей программы: большую часть всего проекта он мог и не видеть. Юнит-тесты также очень сильно облегчают процесс рефракторинга.

Рефракторинг

Есть золотое правило программиста: если это работает – не трогай это. Экстремальные программисты на то и экстремальные - они его всячески нарушают. Рефракторинг - это о процессе, в котором код подвергается постоянной оптимизации и всяческим улучшениям. "Безжалостно рефракторить!" - вот один из девизов ХП. Вообще, идея "А не переписать бы тут все..." не нова и часто приходит в голову одному разработчику, когда он смотрит на код другого. При этом процесс переписывания может продолжаться неоправданно долго и в конечном итоге не принести результатов – его бросят и оставят так, как есть, потому что "то, что было, хотя бы работает". Но как ты уже догадался, у грамотного рефракторинга тоже есть свои принципы.

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

Когда использовать правила ХП

Я огласил далеко не весь "свод правил экстремального программирования". Их больше - подробнее можешь почитать на сайте или купить книгу. Однако крайне редко при разработке проекта используются все правила. Иногда из-за жестких сроков, иногда из-за того, что использование ХП требует больших трудозатрат и, как следствие, приносит меньше прибыли. Бывали случаи, когда написание юнит-тестов требовало больше времени, чем написание самой программы. К тому же при внесении изменений в программу приходится изменять и юнит-тесты...

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