Кент Бек сделал для IT столько, что его имя упоминается на Хабре в сотнях разных постов. Но при этом до сих пор не было хабрапоста о нём самом. Исправим это упущение.
Во вторник Кент выступит на нашей онлайн-конференции по тестированию Heisenbug. Там этот человек, когда-то популяризовавший подход TDD, поговорит о куда более новой концепции TCR («Test && Commit || Revert»). То есть даже к 60 годам он не стал жить былыми заслугами, а продолжает предлагать новое.
Идея TCR кажется многим безумной и нежизнеспособной. Но давайте вспомним все предыдущие достижения Бека — и заметим, что многие из них тоже когда-то казались людям совершенно непрактичными, а потом оказались очень осмысленными.
Паттерны проектирования
В 1961-м Бек родился, в 1979-м поступил в Орегонский университет, а в 1984-м устроился в компанию Tektronix — и прямо с первого же места работы начинается список его достижений. Тут сыграло важную роль знакомство со старшим коллегой Уордом Каннингемом, который тоже значим для истории IT (он позже создал первую wiki-систему). Кент и Уорд быстро спелись: например, вместе получили патент «System for graphically representing operation of object-oriented programs». Но главная их заслуга в 80-х — паттерны проектирования (они же шаблоны проектирования, design patterns).
Сейчас мы так привыкли к паттернам, что сложно представить время, когда разработчики о них не говорили. Но тогда эта идея даже за пределами IT была новой: всего лишь за десять лет до этого, в 1977-м, архитектор Кристофер Александр опубликовал основополагающую книгу «A Pattern Language». Бек был знаком с ней — и вместе с Каннингемом решил применить эту концепцию к разработке программного обеспечения. В 1987-м они представили результаты на конференции OOPSLA.
Нельзя сказать, что паттерны немедленно покорили мир. Популярность к этой концепции пришла позже — в частности, большую роль сыграла классическая книга «Design Patterns» от «банды четырёх», вышедшая в 1994-м. Зато когда программисты распробовали её, стало ясно, что уже не откажутся. В общем, уже тут возникла ситуация «мир не сразу оказался готов к идеям Бека».
Smalltalk
В 1987-1989 годах Бек работал в Apple. И в числе его коллег снова оказался важный человек: Алан Кей, создатель языка Smalltalk. Сейчас этот язык подзабыт, но тогда он не просто был востребован, а во многом определял развитие ООП — многие современные языки вдохновлены им.
Поэтому в Apple Бек занялся разработкой Macintosh Smalltalk. И хотя конкретно этот проект так толком и не реализовался, язык всё равно занял громадное место в жизни Бека. Например, позже он написал книгу «Smalltalk Best Practice Patterns». И это раскрывает нам ещё одну важную сторону его жизни: он не только разработчик, но и значимый книжный автор. Как написано в его профиле LinkedIn, «единственное, что лучше, чем программировать — преподавать программирование».
А Smalltalk он любит до сих пор, хоть в продакшн на нём сегодня и не пишут:
«Он настолько согласованный, что мои возможности для решений крайне обширны. Поскольку всё построено из объектов, если можно придумать решение с объектами, то препятствий для этого, как правило, немного».
Другая его цитата о языке подводит нас к его следующему достижению:
«Smalltalk, с его акцентом на человеческом аспекте программирования, был той питательной средой, на которой выросло экстремальное программирование. Smalltalk всё еще не имеет себе равных по уменьшению стоимости изменений в течение всего времени жизни проекта. А это то, без чего существование XP невозможно».
Экстремальное программирование
В 1994-м компания Chrysler начала разработку проекта Chrysler Comprehensive Compensation System. Проект был на Smalltalk, и в какой-то момент привлекли Бека — изначально для работы с производительностью. Но он увидел проблемы не только с производительностью, а вообще с подходом к разработке, и закончилось дело тем, что он возглавил команду.
Разработку тогда явно требовалось ускорить (проект был в работе уже два года, но ещё не показал реальных результатов). Бек решил подойти к этому радикально, «выкрутить на максимум главное и отбросить остальное». В результате ситуация со сроками улучшилась, но вопросы к этому подходу тоже возникли, и в Chrysler он не прижился. Зато в 1999-м по итогам полученного опыта Бек опубликовал книгу «Extreme Programming Explained: Embrace Change», объясняющую этот новый подход.
В чём именно он заключается? С первого взгляда может показаться винегретом из разных вещей: парного программирования, юнит-тестирования, принципа YAGNI и других. Но прослеживается и общая идея «взять уже зарекомендовавшие себя практики и довести их до предела» (отсюда слово «экстремальное»).
Скажем, есть стандартная практика ревью: один человек пишет код, другой позже читает. А в экстремальном варианте получается парное программирование, когда эти два человека садятся за компьютер вместе. Это ревью в реальном времени, когда каждая строчка проходит его немедленно после появления.
Появление XP (eXtreme Programming) поляризовало сообщество, у него возникли как фанаты, так и противники. И разные его практики оказались по-разному приняты индустрией: юнит-тестирование используется очень широко, а вот парное программирование осталось экзотикой. Но есть компании, которые живут по заветам Бека и утверждают, что им хорошо — мы недавно публиковали рассказ одной из них.
А кто недостаточно радикален для XP, тем может использовать хотя бы Agile. Обеим этим концепциям подходят короткие итерации и оперативная реакция на изменения — так что неудивительно, что в числе 17 человек, подписавших в 2001-м Agile Manifesto, был Бек. Кстати, ещё в том же списке есть и Уорд Каннингем, они снова оказались бок о бок.
xUnit
Бек не только продвигал идею юнит-тестирования, но и породил целое семейство известных инструментов для этого.
В 1994-м он создал проект с расплывчатым названием TestingFramework. Позже оно сменилось на SUnit, и вот такой вариант уже конкретизирует ситуацию: речь идёт не просто о любом тестировании, а конкретно о юнит-тестах и конкретно языке Smalltalk.
Общие принципы, заложенные в SUnit, не были жёстко привязаны к языку, и их можно применять к другим ООП-языкам. И позже Бек сам это и сделал при помощи ещё одного важного для IT человека. Эрих Гамма известен в основном как соавтор книги «Design Patterns», то есть он развил и популяризировал идеи Бека о паттернах проектирования. Как-то они с Беком летели вместе из Цюриха в Атланту — полёт долгий, надо себя как-то развлечь. И по пути в качестве мелкого проекта они создали JUnit, портирующий идеи SUnit на Java. Думали ли они тогда, что спустя годы это станет одной из самых популярных библиотек для одного из самых популярных языков?
В результате, хотя исторически SUnit был первее и значимее, теперь JUnit гораздо известнее: Smalltalk скрылся с радаров, а Java стала суперпопулярной. Впрочем, над новыми версиями JUnit Бек уже не работает, сейчас проект развивают другие люди.
А кроме того, другие люди начали использовать те же идеи для других языков: например, появились NUnit для .NET и RUnit для языка R. И все такие проекты вместе стали обозначать общим названием xUnit, подразумевая, что букву x можно заменить чем-то конкретным.
Со временем и NUnit оказался полностью переписан, и JUnit в пятой версии претерпел большие изменения, так что от написанного в самолёте осталось немногое. Тем не менее, современное юнит-тестирование очень многим обязано Беку.
TDD
И от xUnit нельзя не перейти к смежной теме, связанной с тестированием. В 2002-м Бек выпустил книгу «Test-Driven Development by Example», став главным популяризатором подхода TDD (Test-Driven Development, «разработка через тестирование»). Этот подход отчасти связан с идеями экстремального программирования, но вырос в отдельное явление.
Вкратце суть TDD сводится к следующему: вначале пишутся тесты под желаемое изменение, а уже затем создаётся код, позволяющий пройти этим тестам. Не то что бы эту идею все сразу приняли с распростёртыми объятиями. На Хабре и поныне можно увидеть дискуссии о том, повышает или понижает этот подход эффективность разработки.
Тем не менее, адептов у него немало. То есть идея Бека, которая в первый момент казалась многим странной, в итоге заняла своё место и оказалась вполне жизнеспособной. В какой уже по счёту раз за его жизнь?
Любопытно, что хотя для человечества слова «TDD» и «Кент Бек» плотно связаны, сам он говорит, что не открыл этот подход, а только «переоткрыл». На сайте Quora как-то спросили о таком выборе слов, в ответы пришёл сам Бек и всё пояснил. Оказывается, ещё в какой-то древней книге по программированию он видел то, что считает описанием TDD: «сначала наберите что ваша программа должна выводить, а потом программируйте, пока она не начнёт действительно выводить именно это». Поэтому считает, что вернул человечеству утраченное им знание.
Наше время
Чем Бек занимается сейчас? Ну, в числе прочего — делает сыр и разводит коз. Его жизнь не ограничивается IT, так что в его блоге на Medium можно встретить записи и о медитации, и о покере.
А что с технологиями? В интервью он рассказывал о сложности, из-за которой теперь физически не может писать код в одиночку:
«У меня проблемы с памятью. Так что мне затруднительно удерживать в голове большие и сложные программы, а то и маленькие. Я вполне могу быть партнёром по парному программированию, потому что тогда могу полагаться на память своего партнёра, а вот сесть и написать большую сложную программу — теперь я просто не способен это сделать. Могу программировать в командной строке UNIX, потому что там видишь команду целиком: если можно писать однострочниками, тогда могу выполнять задачи. Но это не поддерживаемый код, а одноразовый».
И в последние годы он занимается не кодом, а коучингом: с 2011-го по 2019-й в Facebook, теперь — в стартапе Gusto (о своей деятельности он в прошлом году сочинил отдельный пост).
Но у него по-прежнему появляются и тексты про техническую конкретику. Один из них описывает подход «Test && Commit || Revert»: если при добавлении нового кода тесты проходят, то код коммитится, а если они падают, то код отбрасывается.
Для многих это звучит странной штукой, неприменимой в реальной разработке. Но тут интересна оценка Мартина Фаулера (ещё одного важного для IT человека, который тоже был среди 17 первых подписантов Agile Manifesto):
«Идея очевидно безумная. Но если начать считать все безумные идеи Кента, которые в итоге сработали, то пальцев не хватит».
Действительно, если прошлый опыт нас тут чему-то учит, так это тому, что даже к самым неоднозначным идеям Бека стоит внимательно прислушиваться. Не факт, что они подойдут вам лично, но как минимум вдуматься в их суть в любом случае полезно.
Этим и займёмся на Heisenbug. Во-первых, 5 октября там будет доклад Бека «Test Run Latency»: и конкретно о подходе TCR, и в целом об идее «чем быстрее увидишь первое падение теста, тем лучше». Во-вторых, ещё Бек поучаствует в небольшой дискуссии о применимости TCR в энтерпрайзной разработке. Ну и, наконец, после доклада можно будет задать ему вопрос — а такого легендарного человека явно есть о чём спросить.
Комментарии (8)
andreyverbin
02.10.2021 03:05А какие идеи Бека прижились? Я не вижу, чтобы XP кто-то всерьёз использовал.
phillennium Автор
02.10.2021 13:32+2Гм, по-моему, текст уже даёт ответ на этот вопрос :) Ну давайте ещё раз:
Бек — это не только XP (уж паттерны проектирования люди явно всерьёз воспринимают)
XP не стало супермассовым целиком, но отдельные его составляющие прижились. Например, насколько понимаю, XP агитировало за короткий релизный цикл ещё в 90-х, до появления Agile Manifesto. И с 90-х люди действительно стали релизить куда чаще.
Существуют и компании, всерьёз использующие XP целиком, в тексте даже ссылка на конкретный пример есть. Это не для всех, нишевая история, но это тоже работает.
HellWalk
02.10.2021 15:20Но у него по-прежнему появляются и тексты про техническую конкретику. Один из них описываетподход «Test && Commit || Revert»: если при добавлении нового кода тесты проходят, то код коммитится, а если они падают, то код отбрасывается.
Для многих это звучит странной штукой, неприменимой в реальной разработке.
«Идея очевидно безумная. Но если начать считать все безумные идеи Кента, которые в итоге сработали, то пальцев не хватит».
Эм... это же обычный CI/CD на GitLab, когда на каждый коммит автоматически прогоняются тесты, и если тесты падают - GitLab не позволяет смержить этот пулл реквест.
funca
Разве перед тем как тестировать, не нужно сделать изменение? А прежде, чем сделать откат (revert), не должно-ли изменение быть сохранено (commit)? Паттерн скорее выглядит так: Fix && Commit && Test || Revert.
DirectoriX
Если речь о revert как о revert-коммите — очевидно, нужно. А если речь о откате изменений в более широком смысле (и как я понимаю, речь именно о таком) — то это скорее git restore, но всё равно revert changes
funca
Он там рассуждает об этом как о партерне. Поэтому я думаю термины стоит трактовать в более широком смысле, нежели конкретные инструменты. Прежде чем запускать тексты, измененный код нужно сохранить - это commit на файловую систему. Там же вы будете выполнять restore если что-то серьезно пошло не так. Система контроля версий и CI это следующий уровень, где все тоже самое повторяется.
zloddey
Есть разные варианты, можно и свой подобрать (в зависимости от используемого языка и тулзов). Основная идея состоит в том, чтобы некорректный код (который не проходит тесты) вообще не попадал в историю изменений.
Я несколько раз пробовал такой подход. Он довольно забавный. Не уверен, что получилось бы в таком режиме работать в продакшн-коде (в первую очередь, из-за того, что для TCR нужны быстрые тесты, а в легаси-проектах такое бывает весьма редко). Но как отдельное упражнение это стоит попробовать. Позволяет тренировать навык писать код маленькими кусочками, буквально отдельными штрихами. Это полезное умение.