Да, заголовок правильный: я не хотел писать экстремальных программистов.
Если вы не практикуете TDD, вы не можете считать себя профессиональным разработчиком.
Парное программирование является обязательным для серьезных разработчиков: это намного быстрее, чем одиночная разработка и асинхронная проверка кода.
Моб-программирование — единственный способ добиться быстрой разработки и обмена знаниями внутри команды
Test Driven Development делает кодовую базу надежной и готовой к выпуску в производство в любое время.
Вы когда-нибудь слышали что-нибудь подобное?
Нас окружают подобные сообщения: « абсолютная истина», «единственный путь»: предложения, написанные известными и менее известными личности в пространстве развития, и попугай-повторяется многими другими.
Верны ли эти предложения? Кто-нибудь предоставил данные и измерения, чтобы доказать, что они действительны в любом контексте? Простой ответ: нет, это не так. Это всего лишь мнения, замаскированные под факты, которые, к сожалению, можно услышать в разных рабочих средах, найти в различных статьях, прочитать во многих лентах LinkedIn и т. д., и проблема в том, что, по моему скромному мнению, они негативно влияет на профессию разработчика.
Как инженеры, мы работаем в режиме, основанном на фактах; когда мы решаем проблемы, мы проверяем с помощью тестов и данных, что решение работает - мы используем все виды инструментов и методов, чтобы получить убедительные доказательства того, что то, что мы поставили, делает работу правильно!
Тогда почему мы не применяем один и тот же образец доказательства к любой методологии?
Давай готовить
Я люблю готовить, так что можете себе представить мое удивление, когда в бывшей компании я начал видеть эти «таймеры для приготовления пищи» в форме помидоров, появляющиеся на столах многих разработчиков. Я был хорошо знаком с этими устройствами, так как использовал их в качестве таймеров на своей кухне.
Когда я спросил своих коллег, почему они используют эти раздражающие и гремящие устройства во время кодирования, они ответили:
«Это техника Pomodoro, мы используем ее, чтобы сохранить темп разработки в 25 минут: это идеальная единица рабочего времени для мозга.
Работаем 25 минут не отвлекаясь, потом пауза, потом опять 25 минут и т.д.»
В то время у меня было несколько лет опыта работы, достаточного, чтобы кое-что знать о себе.
- когда я программирую, я люблю тишину, уж точно не гремящее устройство вокруг меня
- когда я в потоке, я не хочу, чтобы меня прерывали, если нет веской причины
- мое идеальное время для написания кода составляет около 60/75 минут, после этого мне нужен хороший 15-минутный перерыв.
Я долго документировал себя, пытаясь найти какую-нибудь научную статью об этих 25 минутах работы мозга. Угадайте, что: нет никаких научных доказательств, на самом деле парень, который создал это, был студентом университета, и это рабочий интервал, который он использовал во время учебы.
Почему все тратили деньги на это тикающее устройство, а не на бесплатный и бесшумный цифровой таймер? Почему все приняли 25 минут за идеальную единицу рабочего времени? Я ответил себе, что они хотели, чтобы другие люди знали, что они являются частью «группы Pomodoro», они принадлежат сообществу.
Измеримое улучшение
Дик Фосбери: Мексика, 1968 год.
Это звоночек?
Вероятно, нет, но даже если вы не знакомы с этим человеком и связанным с ним событием, вы, скорее всего, знаете его технику!
Дик Фосбери, прыгун в высоту на пенсии, считается одним из самых влиятельных спортсменов в истории этого вида спорта: он совершил революцию в прыжках в высоту, введя в 1968 году технику прыжка назад с первого шага, которая до сих пор остается самой популярной. чаще всего используется прыгунами в высоту во всем мире!
Почему все используют технику Фосбери? Просто он представил новый способ сделать что-то, доказав ощутимыми результатами не только то, что он эффективен, но и намного лучше, чем предыдущий.
Он выиграл Олимпийские игры, используя эту технику. Используя эту технику, он установил новый олимпийский рекорд.
Фосбери никому не говорил, что его техника — единственный способ прыгнуть в высоту, но доказательств было достаточно, чтобы все остальные профессиональные спортсмены перешли к его стилю.
Ущерб
Цитаты, которые я приводил ранее, звучат крайне экстремально. Они не рекомендуют использовать технику или способ работы: они говорят вам, что вы ошибаетесь (или, что еще хуже, непрофессионально), если не используете их, и это большая ложь. Проблема в том, что этот радикализм приносит больше вреда, чем пользы, и я уже стал свидетелем нескольких побочных эффектов.
- Некоторые люди слепо верят в эти заявления, особенно если они исходят от известных личностей, заставляя себя вносить изменения, которые потребуют времени и усилий и для которых нет гарантии лучшего результата.
- Несколько компаний буквально применяют некоторые из этих идей, заставляя своих разработчиков работать в обычном (и навязанном) порядке, вместо того, чтобы предоставить каждой команде свободу самоорганизации.
- У некоторых разработчиков возникает ложное ощущение защиты: «поскольку я использовал TDD, у меня не будет проблем в продакшене»!
404: сервер не найден
Новая функция, полностью разработанная в TDD: клиентский репозиторий HTTP, предназначенный для вызова службы на сервере, который... еще не существовал.
Разработчик знал, что сервер (и связанное с ним веб-приложение) будет выпущен через несколько недель, но на этапе
«красно-зеленый-рефакторинг» «утверждал», что клиент получили HTTP 404 (насмешливое поведение) при вызове несуществующей службы, и это исключение было бы заглушено невинным журналом, в котором говорилось, что сервер еще не готов.
Несуществующий сервер не возвращает 404: проблемы находятся непосредственно на сетевом уровне, где вы получаете исключение неизвестного хоста, если DNS не разрешается, или тайм-аут соединения, если соединение не может быть установлено.
Когда клиент был выпущен в рабочую среду, файл журнала начал расти, и в нем появились тысячи записей на уровне ERROR, в результате чего система оповещения передала проблему на уровень поддержки, вызвав откат. Неверное предположение загнало разработчика в эту ситуацию, и TDD не смогла его спасти.
Означает ли это, что TDD — это плохо?
Нет. Это просто означает, что нет никакой волшебной методологии или техники! Тест сначала, тест после или вообще никакие тесты не дали бы точно такой же результат с тем же предположением.
Нет единого размера для всех
Вопреки мнению многих людей, не существует волшебной палочки, которая решит все ваши проблемы. Вы должны изучить все методологии и техники, вы должны практиковать их, овладеть ими и выяснить, что лучше всего использовать для вас и вашей команды.
Заполните свой набор инструментов очень хорошими инструментами, практиками и принципами. Это справедливо для всего, включая методологии Agile. Мой личный взгляд на эти
- Мне нравится парное программирование, когда мне приходится тренировать юниора через старшего.
- Я люблю парное программирование, когда мне нужно разработать особенно сложную функцию, где наличие еще двух глаз и немедленная обратная связь могут привести к лучшей реализации.
- Мне нравится TDD, когда у меня есть очень младшие разработчики, потому что они могут легко добиться достойного дизайна, слабо связанного и протестированного.
- Мне нравится групповое программирование, когда я тренируюсь с Ката в группе, так как я нахожу его очень инклюзивным.
«Я вижу это место, оно сумасшедшее, похоже на клоунское шоу, и все же все работает очень хорошо. Они ничего не делали в моих книгах». […] «Теоретически этот процесс должен быть катастрофой, но на практике он работает очень хорошо в двух вещах одновременно; при масштабировании и исследовании» […] «Первый, почти год, я провел, работая над конфиденциальностью и серверной частью обмена сообщениями, и обнаружил, что я, вероятно, был худшим разработчиком C++ в Facebook. У меня плохой отзыв. Было ясно, что просто попытка перекинуть код не была моим отличительным преимуществом».
— Кент Бек, изобретатель TDD, во время своего опыта работы в Facebook
(отрывок из «Facebook Engineering Process with Kent Beck», ежедневник по разработке программного обеспечения)
