Я работаю программистом более 30 лет, но никогда не мог писать код так быстро и безопасно, пока не нашел правильную технику.
Все слышали выражение программиста клейкой ленты.
Он программист, который может реализовать что угодно практически в кратчайшие сроки. Когда его просят быстро доставить что-то сложное, он делает.
Программист клейкой ленты — любимец босса и ужас для его коллег.
Получается, что программирование в команде напоминает принципы трагедии общего достояния: срезание углов вносит в проект технический долг, который платят все программисты, поэтому некоторые программисты могут быть быстрее, замедляя всех остальных.
Быть программистом изоленты не для меня.
Я могу кодить быстро, но если у меня нет подстраховки, когда я работаю, я чувствую себя тяжеловесом. Кодирование функциональности — это не просто добавление кода, это также уверенность в том, что вы ничего не сломаете.
Например, несколько лет назад один релиз был остановлен из-за серьезных проблем с производительностью кода другой команды. Поскольку я действительно хорош в оптимизации кода, они дают мне решить проблему.
Но мне дали один день. Всего за один день мне пришлось изменить почти весь код и переписать некоторые поведения. Когда я закончил, я почувствовал себя грязным. Я был незнаком с проектом и его поведением, и я не знал, нарушил ли я что-нибудь, поэтому я передал это QA.
Все работало. Я чувствовал себя счастливым. Я изменил так много кода, что до сих пор являюсь участником номер один.
Это опыт, который я не хочу повторять.
Работа программиста состоит из трех частей: решить, спланировать и очистить.
Во-первых, разработчик планирует новую функциональность: ему нужно знать, какой код нужно изменить, чтобы внедрить новую функциональность. Именно в этом программатор Duct Tape Programmer преуспевает, но не во всем остальном.
Второе — это план. Кодировщик не может писать новый код как есть, весь код похож на экосистему, поэтому им нужно найти способ внедрить его и больше ничего не ломать. Программисты тратят много времени, пытаясь запомнить всю сложность кода. И последний чистый.
Если код не чистый, то следующие результаты займут больше времени или будут содержать больше ошибок.
У меня есть утверждение: если вы используете правильную технику, вы можете работать быстрее, чем программатор для клейкой ленты, но без каких-либо опасностей.
Представьте, что у нас есть волшебная кнопка.
Кнопка, которую мы, как программисты, можем нажать, и через несколько секунд мы узнаем, все ли работает или что-то сломалось.
Представьте, что нам нужно закодировать что-то новое, у нас есть интуиция, но мы не уверены, сработает ли это. С помощью волшебной кнопки мы можем записать нашу интуицию, не задумываясь, нажать кнопку и убедиться, что она была верной. А так как все работает, доставляй. Вместо того, чтобы тратить время на обдумывание, обдумывание и планирование, мы просто действуем с первой идеей, которая у нас появилась. Это смело.
Оказывается, TDD создает такие тесты, которые дают нам волшебную кнопку. TDD вместо модульных тестов генерирует тесты для разработчиков:
TestDrivenDevelopment создает тесты DeveloperTest. Неудача тестового примера связана только с самой последней правкой разработчика. Это означает, что разработчикам не нужно использовать MockObjects для разделения всего своего кода на тестируемые блоки — Уорд Каннингем
Тесты для разработчиков имеют высокий уровень достоверности и выполняются быстро, очень быстро. Это волшебная кнопка. Кроме того, у них также есть особое свойство: сбой подразумевает последнее редактирование. Другими словами, кодеру не нужно искать сбой везде, а только в последнем коде, к которому он прикасался. И Уорд Каннингем дает нам последний совет:
И это означает, что разработчик всегда может избежать отладки, отменив последнее редактирование. (Совет: верните его!) — Уорд Каннингем
Таким образом, с TDD разработчик может написать код, запустить тесты, и, если он работает, работа выполнена, а если нет, отменить последнее редактирование и попробовать другой подход.
Если это работает, если это не нуждается в чистке, больше ничего не нужно. Разработка сократилась с часов до минут. Разработчик может работать с интуицией, ни разу не подумав, что не всегда получается, но быстрее. Но если это не сработает, он узнает, поэтому они могут рискнуть, потому что риска нет.
Если это не работает, то программист должен перестать думать.
Сначала они отменяют последнее редактирование, а потом он должен принять решение. Они могут либо попробовать другой подход, либо пойти на более традиционное и дорогое решение.
Этот подход настолько силен, что даже Кент Бек предложил альтернативу TDD: «test && commit || реверс» (TCR). Идея почти та же, но она переплетает разработку с репозиторием кода. Каждый раз, когда код проходит успешно, средство выполнения тестов делает фиксацию, но если это не удается, он возвращается к предыдущей фиксации.
Этот метод побуждает разработчика смело писать код и практически не отлаживать его.
Должен признаться, что я не пробовал TCR, но обычно использую очень близкий подход при использовании TDD. И оба имеют одни и те же свойства, если им хорошо следовать.
Если вы разработчик, особенно если вы используете TDD, вам следует попробовать: как только у вас будет готов тест, напишите первый код, который, по вашему мнению, пройдет. Не думайте дважды, не пытайтесь планировать, просто пишите. Если пройдет, то можно чистить, если надо. Если нет, попробуйте альтернативное решение. Этот подход действительно быстрый, безопасный и смелый способ написания кода, который вы никогда не пробовали раньше.
Спасибо за чтение. Это мой второй рассказ из серии о преимуществах TDD, в котором я хочу поделиться и улучшить понимание этой практики. Открытие было Поиск лучшей практики программирования, а следующее — Снижение когнитивной перегрузки программиста.
Want to Connect? If you liked the article, check my most successful stories on Medium to read more.
