Да, это не ошибка: сегодня мы поговорим о самых что ни на есть экстремистских подходах к программированию.
«Если вы не практикуете 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», журнал по программной инженерии.
Комментарии (24)
funca
30.10.2022 23:41+2Тогда почему же мы не применяем доказательную модель к различным методологиям и техникам разработки?
В крупных системах такие решения принимаются не на уровне отдельных разработчиков или даже команд, а спускаются им свыше в виде таких вот постулатов. Всей картинки в смысле why они могут и не видеть. Даже если архитекторы объяснили им свой vision на старте, то проблема в последствии повторяется при онбординге новых людей, которым уже ни кто ни чего персонально не объясняет.
tandzan
30.10.2022 23:48У меня на столе 30-минутные песочные часы, никакого шума :)
Akina
31.10.2022 09:03А как они дзынькают, когда 30 минут пройдёт? ну не пялиться же на них вместо работы...
tandzan
31.10.2022 14:11Можно конечно приделать ардуину, чтоб задорный рингтон был, мощная rgb нотификация, зато не тикает, да. В опенспейсе. В песочных ничего не двигается, можно прям у монитора ставить, не отвлекает.
edo1h
31.10.2022 17:52гхм, вы правда хотите отвлечься на «дзынь» если у вас работа прёт и вы не заметили, что время кончилось?
K_Chicago
31.10.2022 21:06+3Очень верное замечание. Я работаю из дома уже третий год. Были случаи когда "работа прёт" и я знаю, что нужно лечь спать максимум в час чтобы быть на утреннем (9 утра) созвоне. А она, суко, прёт. И я добираюсь до подушки в пол-пятого утра. И я никакой весь следующий день. Но я нашёл баг, с которым воевал последние две недели и теперь все работает. Оно того стоит.
А как иначе? Она, типо, прёт, я смотрю на часы, 10 вечера, так, всё, шабаш, на горшок и спать. Так чтоли? Это тогда Рахметов получается, а не программист которому нравится его работа и другой он не хочет.
Didimus
01.11.2022 06:40Очень удобно, когда кто-то подходит побеспокоить, покажешь на часы: «у меня перерыв»
mSnus
31.10.2022 00:21+17Культ карго как он есть: когда-то Большой Белый Разработчик использовал Тикающий Овощ, и стал легендой. Потом он деплойнулся за океан, но успел показать нам путь! Поэтому, сынок, вот тебе тыква с кукушкой, поставь её на свой рабочий стол. И не забывай кормить кукушку...
K_Chicago
31.10.2022 21:09+1также и аджайлом. 17 хипарей собрались в Юте, дунули как следует, поймали гармонию, дунули еще и решили: нахер документацию, нахер спецификацию, если нужно - пригласим заказчика, дунем как следует и все тип-топ. Так и записали.
А потом такая фигня получилась что до сих пор блевать хочется.
Программисты! Если вы под кайфом чего-то придумали, пожалуйста, не публикуйте манифестов!!!
Nilomar
31.10.2022 04:51Единственно верный путь для чего?
Если единственно верный путь для того, чтобы код гарантированно покрывал все кейсы, то для этого есть любой язык с автоматическим доказательством теорем, например Idris
Однако в суровых реалиях почти всегда случается, что для бизнеса наиболее выгодно слепить очередной проект из кучи навоза и веток на фреймворке, специально именно для таких кейсов и предназначенном
Если взлетит - перепишут, если не взлетит - выкинут
vkni
31.10.2022 07:30+1то для этого есть любой язык с автоматическим доказательством теорем, например Idris
Со мной случилась однажды очень поучительная история — я нашёл ошибку в самоучителе F*, где много лет назад был пример с факториалом. Там в тексте рассказывалось про доказательство одного факта, а в коде доказывался совершенно другой. :-)
В общем, студент-медик должен быть небрезгливым и всегда внимательным.
oleg_shamshura
31.10.2022 05:12+9Есть в этом что-то из подростковой психологии.
Изощренная классификация музыкальных стилей, лютая непримиримость субкультур, яркие и примитивные маркеры "свой/чужой", всенепременная "нетаковость" (think different, ага), тяга к коллекционированию и страх "не успеть за всеми".
Когда все это проходит к 40 годам (привет соседнему thread'у) и вся пурга становится явственной, программист объявляется устаревшим и отупевшим.vkni
31.10.2022 07:28+3Когда все это проходит к 40 годам (привет соседнему thread'у) и вся
пурга становится явственной, программист объявляется устаревшим и
отупевшим.Вы таки не поверите, но не у всех...
zynaps
31.10.2022 06:00+1Отличная статья. Специально зашел похвалить за то, как хорошо написано. Прямо отличное начало дня! :)
HellWalk
31.10.2022 13:35-1Слышали ли вы когда-нибудь подобные заявления?
И слышал, и сам так считаю.
Не понимаю программистов, которые имеют много лет опыта и не пишут авто-тесты. Для меня это люди навсегда застрявшие в джунах.
Меня сам по себе код не интересует. Слова Васи "он вчера работал" тоже. Я хочу в любой момент запустить тесты и увидеть, что они выполняются. Запустить покрытие кода тестами, и увидеть, что там 90+% (не показатель полноценного покрытия тестами всех ситуаций, но лучше чем 10%), так же как и не интересны проекты без CI/CD, где прод по старинке обновляют руками, регулярно сталкиваясь с проблемами, что Вася забыл выполнить какой-то там скрипт или миграции, и прод упал.
rmrfchik
31.10.2022 13:50+1TDD!=автотесты.
Но давайте, для простоты рассуждений, приравним одно к другому. Автотесты не гарантируют ничего сверх того, что [не]выполняются автотесты. По результатам автотестов нельзя сделать осмысленный вывод.
Автотесты, равно как и другой баззворд в этом тредике это инструмент, который становится осмысленным только в руках сапиенса. Вот только сапиенс может применять ДРУГИЕ инструменты с тем же успехом.
Мир очень и неожиданно. разнообразен. Например, нужен ли CI/CD в тех проектах, где нет прода и нет D?
HellWalk
31.10.2022 15:33Автотесты не гарантируют ничего
О, обожаю такие рассуждения.
Добавлю:
Хорошее образование не гарантирует счастья в жизни - значит бесполезны
Большие деньги не гарантируют счастья в жизни - значит бесполезны
подствьте_что_угодно - не гарантирует счастья в жизни - значит бесполезны
Например, нужен ли CI/CD в тех проектах, где нет прода
Да, нужен. Вы никогда не работали с нормально настроенным CI/CD на GitLab? Когда чей-нибудь хреновый мерж реквест, который ломает билд проекта или тесты просто на уровне самого GitLab не может быть смержен? Соответственно не нужно даже тратить время на анализ плохого мерж реквеста - упал CI - иди чини. А уже после этого, мерж реквест который прошел CI глазами посмотрят другие программисты на ревью.
rmrfchik
31.10.2022 20:29+1Нет, не бесполезны. Но не панацея. И не гарантия. Это как мыть руки -- какую-то болезнь не подцепишь. Но не значит "мою руки, значит ничем не заболею".
Куда делать CD, если делать некуда? Нет продуктива.
CI это не "упали тесты", CI это "наш код интегрируется с другим кодом". Этого другого кода может и не быть.
HellWalk
01.11.2022 13:10Куда делать CD, если делать некуда? Нет продуктива.
Вы в CI/CD видите только CD?
CI это не "упали тесты"
Разумеется. Если тестов нет, то и падать нечему.
Этого другого кода может и не быть.
Первый коммит в проекте?
В общем, чтобы не продолжать этот бесполезный разговор (я на последователей "тесты не нужны" насмотрелся в реальной работе, и то, какого уровня код они пишут), в заключение: работать без тестов и CI/CD можно, но для меня это тоже самое, что работать без git'а, а проект обновлять загружая файлики по FTP - можно, но это не уровень серьезного проекта. И в команде таких "программистов" мне находится неприятно. Хотя, конечно, каждому свое. Свинье и в грязи комфортно.
P.S. Код выполняющий работу - вторичен. Первичен - код который проверяет, что все работает как надо, и код который организует проверку и доставку нового кода. Но я понимаю, что эти слова за гранью понимания тех, кому "тесты не гарантируют"
K_Chicago
31.10.2022 21:12+1а что, тут всем так стыдно прямо сказать, что самое лучшее тестирование - это задеплоить в продакшен и ждать тикетов. Нет лучше тестировщика чем тупейший юзер у которого горит дедлайн.
Ну да, это не по канону, но ведь мы все в глубине души это знаем?
khablander62
Все относительно. Фраза "пешеходы должны передвигаться по тротуарам" звучит правильно, если вы в городе. И не имеет смысла, если вы находитесь в лесу.
Ну а пример про 404 - это прокол программиста. Он не написал тест для сценария где внешняя система возвращает что-то еще помимо ожидаемых кодов.
SerjV
В статье не просто так сказано "при том же самом изначальном предположении" ;) Неправильным было именно оно, а чтобы написать тесты еще для чего-то - это надо было сначала хотя бы предположить.
В частности, у вас тоже ошибка - вы не предусмотрели, что внешняя система может вообще ничего не возвратить.
Потому да, ожидаемое поведение в нормальной ситуации - код 404, а дальше начинается нелюбимое многими "а что, если?" - а если код не такой, а если вообще с той стороны никто не ответит (где возможны два подварианта - "мы об этом узнаем быстро", например, не разрезолвился DNS, но это не единственный сценарий, и "мы об этом узнаем по тайм-ауту" - например, пакеты дропнулись по пути, но это тоже не единственный вариант - хуже, если TCP-соединение установилось, и на этом "всё")?..