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