Миру нужны фуллстек-крафтсмены

Спор «фуллстек против узкой специализации» вечный. Но одно дело — спорить в комментах, а совсем другое — создать собственную компанию и проверить экстремальный подход на практике. Антон Кекс пошел по этому пути: стал сооснователем компании Codeborne, где разработкой занимаются исключительно «фуллстек-крафтсмены» и практикуется экстремальное программирование. И по его словам, там командами из 2-4 человек получается сделать то, на что другим требуется человек 50.

Он подробно рассказал об этом на нашей конференции JPoint. Обычно на наших мероприятиях не услышишь слово «agile», потому что о методологиях много пустословия, а мы любим конкретику, код и хардкор. Но поскольку Антон не диванный теоретик, а обладатель большого нестандартного опыта, это как раз хардкор и ценная информация.

Можно не соглашаться с его позицией, но как минимум ознакомиться с ней полезно. И хотя доклад сделан еще пару лет назад, в 2021-м он продолжает собирать просмотры, поэтому мы решили сделать для Хабра текстовую версию. Под катом — и видеозапись, и текстовая расшифровка. Дальше повествование ведется от лица Антона.

Оглавление

1. Интро: о Таллине и Codeborne
2. Фрагментация комьюнити: что разделяет разработчиков
   — Конфликт 1: Админы vs Разработчики
   — Конфликт 2: Разработчики баз данных vs разработчики приложений
   — Конфликт 3: Изоляция по интересам
   — Конфликт 4: Фронтенд vs бэкенд
   — Конфликт 5: iOS vs Android vs все остальные
   — Конфликт 6: Переизобретение велосипеда, Kotlin vs Swift
   — К чему приводят конфликты
3. Фуллстек приходит на помощь
   — Extreme programming
   — Что важно знать фуллстеку
   — Побочные эффекты фуллстека
4. Саппорт роли: игра в испорченный телефон
5. Манифесты Agile, Scrum и Software Craftsmanship
6. Craftsmen, Craftsmen, Craftsmen!
   — Что должен уметь крафтсмен
   — Как решить проблему не кодом? Пример из жизни
   — Стартапы и крафстмены
   — Underengineering
   — Практики экстремального программирования
7. Codeborne Routine
8. Парное программирование
9. Заключение

Интро: о Таллине и Codeborne

Доклад на русском, но на слайдах английский, потому что я не местный. Я приехал из славного города Таллина: это самый хорошо сохранившийся средневековый город в Европе, а также европейская IT-столица. Все технологии Евросоюза берутся из Эстонии. Поэтому приезжайте к нам, у нас классно!

Мой доклад основан на опыте компании Codeborne, которую я создал с моими коллегами в 2010 году. Мы 9 лет работаем именно так, как я сейчас буду рассказывать, так что все проверено в бою. На мой взгляд, это самый лучший формат работы в IT.

Компания у нас небольшая, в ней 33 «крафтсмена», и других ролей нет. Слово «craftsman» иногда переводят на русский как «ремесленник», но мне больше нравится «мастер своего дела».
Почти все самые большие эстонские компании — наши клиенты, и у нас много клиентов за рубежом. В 2012 году мы принесли в Россию интернет-банкинг: сделали в России первый такой интернет-банк, какими мы привыкли их видеть в Эстонии до этого.

У нас маленькая команда, но эффективность очень большая: мы делаем очень много, никто не может в это поверить. И поэтому я сейчас буду рассказывать вам про наши секреты — никому не говорите.

Фрагментация комьюнити: что разделяет разработчиков

Начнем с напоминания. IT существует только потому, что мы делаем проекты для бизнеса, государства и так далее. Они платят нам деньги. Мы абсолютно бесполезны без них: можем кодить что-нибудь прикольное для себя, но это не то. И тем не менее мы постоянно делим друг друга на группы и спорим друг с другом.

Если мы посмотрим немного в прошлое, то увидим, что в прошлом все программисты были фуллстек-крафстменами. Но тогда еще не было таких слов, и они назывались просто «программистами». Кстати, не все знают, что первые программисты в основном были женщинами, так что это были не craftsmen, а craftswomen. В то время программисты должны были еще больше знать про железо. Сейчас статус фуллстека не подразумевает, что вы должны сидеть с паяльником. В то время вы должны были работать с машиной на очень низком уровне.

А потом всё изменилось: появились конфликты, токсичность, разные группы, комьюнити, которые не общаются друг с другом. Давайте на них посмотрим.

Эта картинка — хороший пример. Сверху можно поставить разные слова, необязательно «разработчик» и «тестировщик». Главное — это нож за спиной, и это не то, к чему мы шли. Это не то, что все эти люди в 50-х, которые с перфокартами бегали, ожидали от нас.

Конфликт 1: Админы vs разработчики

Давайте посмотрим на первый конфликт, который я наблюдал когда-то. Это были администраторы против разработчиков. Администраторы — это, наверно, одна из первых дополнительных ролей в IT, которые появились, когда начался активный рост IT. Появился интернет, но еще даже до интернета появились сервера, которые запускали какие-то приложения, и кому-то нужно было за ними наблюдать. Это отличная от программирования роль.

Проблема в том, что админы отвечают за стабильность своих систем, и поэтому они ненавидят изменения. А мы, разработчики — вся наша работа заключается в том, чтобы эти изменения создавать. И сразу первый конфликт налицо: люди не хотят друг с другом общаться.

Фразу «Дать права админа разработчику приведет к хаосу» я слышал в этом году, в 2019-м. Я был в шоке, что существуют такие люди, которые, несмотря на весь девопс и так далее, до сих пор говорят, что если дать разработчикам какой-то доступ, то начнется хаос.

Конфликт 2: Разработчики баз данных vs разработчики приложений

Потом в 2000-х был другой очень популярный конфликт — между разработчиками баз данных и разработчиками приложений. Очень интересный факт, что задолго до этого, появилась компания Oracle, которую мы все знаем и любим, и она занималась созданием баз данных. Их консультанты ездили по всему миру, и втюхивали свои продукты всем крупным банкам и другим компаниям. Чтобы втюхивать продукты лучше, им нужно было придумать новую специальность (DBA) и еще новую очень важную фразу — «data assets». Чтобы топ-менеджмент в компаниях понимал, что наша база данных — это сокровище, это наши активы, это так же важно, как наши бабки на счете в банке. И к сожалению, это создало отдельную роль для людей, которые специализируются только на базах данных.

У этих людей с разработчиками приложений был большой конфликт, в основе которого лежал вопрос: куда класть бизнес-логику? Человек, для которого весь мир — это его святая база данных, естественно, хочет все туда запихнуть, даже то, что туда не запихивается. Разработчик приложений наоборот. Для него база данных — это какая-то помойка, и он хочет все самое важное оттуда вытащить.

Базисты остались более консервативными. Я до сих пор вижу базистов, которые используют, например, CVS для разработки своих хранимых процедур в Oracle. Это вообще ужас, 2019 год. С другой стороны, разработчики приложений пошли в другую сторону и сказали: «NoSQL, давайте, реляционные базы данных дерьмо, нам нужны новые крутые фишки». И все стали переизобретать то, что уже в мире баз данных давно было, например, консистентность. И теперь такие вещи программисты сами должны писать в своих приложениях. Естественно, они делают там кучу багов.

Конфликт 3: Изоляция по интересам

Еще появилась куча других изолированных комьюнити в IT, связанных с разными вариациями. Например статические и динамические языки. Но мы, конечно, на Java-конференции, мы знаем, что динамические языки — это для детского сада, правда?

Потом, естественно, есть, например, open source и проприетарный софт. Есть люди, которые живут в мире Microsoft и вообще не представляют, что происходит вне этого мира. Они там сидят и пилят то, что им Microsoft показал, и все. На самом деле, это ужасно.

Такие примеры, как Ruby и Python, .NET и Java EE (царство ей небесное)… Это всё сделали люди, которые пытаются жить в своем мире, и они постоянно переизобретают вещи. Например, разработчики Ruby и Node только сейчас начинают ценить такие вещи, которые в Java были в 1995 году. Это многопоточность и обратная совместимость. Они только сейчас начинают это понимать, мы же это все давно знали.

Потом есть еще игровые разработчики. Это тоже отдельный мир. Эти чуваки еще меньше общаются со всеми нами, они даже не знают, что такое continuous integration и юнит-тесты. Но зато они работают в студиях, очень модно одеваются, классно тусуются и так далее.

И, конечно, есть еще те, кто до сих пор программирует на C, на С++, тоже абсолютно отдельный мир. Для них тоже появились альтернативы: Go, Rust (кстати, если кто-то из вас еще не смотрел на Rust, это офигенный язык, его стоит посмотреть).

Конфликт 4: Фронтенд vs бэкенд

Потом появилась новая терминология для разделения нас: фронтенд и бэкенд. До 2010-х годов такие слова вообще никто не употреблял. Это были странные слова. А все началось с того, что в какой-то момент все захотели делать более крутые UI, более сложные, и с этой сложностью появилась необходимость использовать новые технологии, делать как-то по-другому. То есть перестали просто фигачить jQuery куда-то в середину своего HTML, а начали думать, что нужно делать новые крутые тулзы.

Даже я в то время пропагандировал более четкое разделение между UI и остальным кодом, потому что они пишутся теперь на разных технологиях. Но я никогда не думал, что люди должны специализироваться либо на одном, либо на другом. А что получилось? Пришло новое поколение разработчиков: какой нафиг бэкенд? Вот UI — это секси, прикольно, давай будем колбасить на Node и компилировать JavaScript в JavaScript и переизобретать фреймворки каждый месяц. Сейчас много шуток про фронтенд. Причем, кстати, компиляция JavaScript в JavaScript занимает больше времени, чем компиляция Scala-кода, представляете? Я реально видел это.

И нас теперь понизили до API-разработчиков. Мы, бэкенд-разработчики на Java, теперь сидим и только колбасим API для крутых чуваков, которые делают «секси UI».

Конфликт 5: iOS vs Android vs все остальные

В то же время произошла вторая революция: очень круто развились наши мобильные девайсы. И знаете, Стив Джобс очень мудрый. Когда появился первый iPhone, он сказал, что там есть настоящий крутой Safari-движок, на нем можно писать офигенные web 2.0 и Ajax-приложения, которые выглядят и ведут себя точно так же, как приложение на iPhone, и Apple не нужны нативные приложения. Это он так говорил в 2007 году, и это было мудро — не создавало новую фрагментацию среди разработчиков.

Что произошло? Через месяц появился Jailbreak. В Apple увидели, что там появилось новое комьюнити: люди стали хачить и делать приложения для iPhone. У меня был первый iPhone, и это была классная игрушка: там можно было поставить ssh-сервер, заходить в терминале на свой телефон. И в итоге Apple ничего не оставалось, кроме как сделать App Store. История свершилась: теперь, к сожалению, у нас каждый маленький веб-сайт, каждый маленький магазин во дворе хочет иметь свое приложение, и чтобы все его устанавливали и зачем-то использовали.

И что это значит? Значит, что мы, как разработчики, опять получаем разделенное комьюнити. Потом появился Android. Царство небесное Windows Phone, к счастью, потому что это опять же фрагментация (хотя Windows Universal Apps все равно можно писать под Windows).

Теперь есть iOS и Android-разработчики, они перестали друг с другом общаться, они совсем разные. Идея Android была в том, чтобы использовать Java для привлечения огромного числа уже имеющихся разработчиков на новую платформу. Идея офигенная. Что мы видим сейчас? Новое поколение разработчиков, которые никогда в жизни не писали ничего на бэкенде. Они только фигачат Android и говорят: «я не хочу бэкенд — это не круто, вот Android — это совсем другое». И естественно, они снова стали переизобретать: как все это тестировать, какие новые языки нужны, потому что старые уже плохо подходят. Все усиленно учили Objective-C — теперь уже никто не хочет видеть никакого Objective-C.

Теперь мы пришли к тому, что компании обязаны переимплементировать все свои UI три раза как минимум: они пишут для Android, для iOS, для веба и потом для чего-нибудь еще. В каждой компании еще есть бэкенд-разработчики. Они делятся на микросервисы, у каждого микросервиса есть своя команда, и они занимаются только своим микросервисом. Они знают, что у них где-то здесь есть вот этот костыль, а вот про тот костыль они ничего не знают. Это всё ужасное переиспользование ресурсов нашей матушки-земли.

Конфликт 6: Переизобретение велосипеда, Kotlin vs Swift

Давайте посмотрим на Kotlin и Swift. Оба — отличные новые, современные языки, мне офигенно нравятся. Они очень похожи, удивительно похожи. Они разрабатывались независимо друг от друга, и получилось почти одно и то же. Опять же, сколько ресурсов было потрачено на это. Но в то же время там есть некоторые нюансы. Например, Kotlin научился у Java-комьюнити, что «checked exceptions» — это плохо, а в Swift это, наоборот, добавили как крутую инновацию, после Objective-C.

К чему приводят конфликты

Все доходит до того, что есть разработчик функции X и функции Y, и считается, что мы разные, и мы не общаемся. Это даже не совсем шутка: у нас есть serverless, у нас есть AWS Lambda, и мы действительно скоро станем разработчиками одной функции. Представляете, если бы так было у врача? У вас одно ухо окей, идите теперь к другому чуваку, он проверит ваше второе ухо. Ерунда же.

У этой ерунды есть название: по-английски это overspecialization. По-русски можно перевести как «чрезмерно узкая специализация». Это то, что мы сейчас, к сожалению, активно наблюдаем в IT. Это приводит к:

• Раздутым командам. Теперь, чтобы сделать что-то маленькое, нам нужно не 2 разработчика, а 25, потому что каждый из них делает свой маленький кусочек, а потом еще кто-то это пытается соединить, чтобы всё вместе оно работало;
• Низкому фактору грузовика (bus factor/truck factor). Это количество людей в вашей команде, которых может переехать грузовик, чтобы ваш проект все еще мог существовать. Если единственного iOS-разработчика вашей команды переедет грузовик, и ваше iOS-приложение потеряет смысл, то это очень плохо. Я работаю со многими компаниями-клиентами и вижу это постоянно;
• Медленным и дорогущим проектам. Мы как индустрия конкретно зафейлили наших заказчиков.

Второе, смежное слово — это overengineering. Это значит, что люди, имея очень узкую специализацию, пытаются в своей песочнице создать огромные замки и сделать её еще круче. Из этого получается, что сложность всей системы растет, все компоненты становятся более сложными, с ними сложнее взаимодействовать. Мы как разработчики должны всегда искать простоту. Оверинжиниринг я сейчас вижу везде.

Фуллстек приходит на помощь

На помощь приходит возвращение к старому-доброму фуллстек разработчику. Раньше все разработчики такими и были. Это мастер на все руки:

• Он обладает широким кругозором;
• У него есть опыт в разных областях и стеках;
• Он может выбрать правильный инструмент для конкретной задачи;
• Ему не нужно показывать пальцем ни на кого. «Я сделал свою часть, а эти бэкендеры свой API не допилили, это они все виноваты, что у нас проект полетел» — такого не бывает;
• Он может очень быстро выучить новые технологии, потому что он много что пробовал, знает, что важно, а где просто синтаксис, который нужно выучить.

К сожалению, в больших компаниях и на более крупных рынках это редкий индивид. Как пример: в нашей маленькой Эстонии гораздо меньше узкоспециализированных людей. Когда мало людей, очень сложно себе это позволить. Когда у вас большой город, большой рынок, то вы можете позволить себе быть неэффективными. «Большой» чаще всего значит «неэффективный». И это значит, что каждое определенное звено в этой неэффективной организации — это еще менее важный человек. Вы хотите быть неважным в своей организации? Пилите вы свою маленькую функцию, и ладно, пофиг, что там вокруг происходит. Это приводит к обвинениям. Вы начинаете обвинять всех кругом в том, что у нас проект опять не входит ни в дедлайны, ни в бюджет.

Extreme programming

Давайте посмотрим на то, что, можно сказать, является для меня Библией разработчиков. Это экстремальное программирование, одна из оригинальных эджайлных практик.

Экстремальное программирование зиждется на очень важном понятии collective code ownership, по-русски — «колхозное программирование». Это значит, что весь код общий. Нет такого, что тут мой код, а тут не мой код, эту функцию поменяла Катя, поэтому я ее не трогаю, пусть Катя сама фиксит свои баги. Нет. В экстремальном программировании все по-другому. Я иду в любое место и исправляю все, что нужно.

Если я фуллстек-разработчик, я либо участвовал в построении всей системы с нуля, либо я выучил все аспекты системы. Это мне нужно, чтобы я мог в любом месте что-то наладить, починить, чтобы мог понять, где реальная проблема, и не фиксил ее там, где не надо. Я ничего не оставляю другим: если я делаю новую фичу, я обязан сделать так, чтобы она полностью работала, от самого UI до базы данных, чего угодно. Я полностью контролирую ситуацию. Если всю мою команду переедет грузовик, я все равно справлюсь. Это то чувство, которое должно быть у фуллстек-разработчика. Естественно, с такой крутой силой приходит ответственность, но это классно, это интересно, это делает нашу жизнь и работу более прикольной.

Многие говорят, что быть фуллстек-разработчиком ужасно сложно: «я не могу знать так много всего, в мою маленькую голову это просто не влезет». На самом деле, определение фуллстек-разработчика может быть таким: вы знаете все стеки вашего собственного проекта. В вашем собственном проекте вы можете работать на всех уровнях. Это не значит, что вы знаете все технологии в другом проекте, но если вы туда попадете, то вы их все выучите без проблем, потому что у вас уже много опыта. Это значит, что вы — как полиглот в языках. Вы знаете, что важно, знаете эссенцию программирования, и можете ее применить везде.

Например, многие люди на PL/SQL говорят, что не умеют писать юнит-тесты. Если вы знаете, как это делается, вы можете написать простенький фреймворк для себя на любом языке, показать его и С-шникам, и PL/SQL-щикам — вот, смотрите, вот они, юнит-тесты, вот так делается разработка через тестирование, даже на вашем языке, где вы говорите, что это невозможно.

Вы все равно выучите самые нужные части вашего проекта достаточно глубоко, и будете получать опыт в своем проекте. Потому что вы никогда не надеетесь, что кто-то за вас решит проблему.

Что важно знать фуллстеку

Для вас важные вещи — это, например, структурирование кода, как его хорошо спроектировать. Безопасность, как правильно логировать, чтобы потом хорошо проводить аудирование вашего приложения, как его автоматически тестировать, как решать проблемы просто, а не сложно. Каждый дурак может написать сложный код, а вот попробуйте написать простой. Это то, что вам реально нужно выучить. Потом вы берете какой-то новый язык программирования, играетесь с ним пару дней, и после можете так же круто перформить, как вы делали это на Java, например.

Плюс вам нужны развертывание, девопс: вы должны автоматизировать запуск вашего приложения, чтобы оно не падало. Потому что если оно упадет, то злой админ позвонит вам в середине ночи, и вам будет неприятно. А если вы где-нибудь в баре, уже пьяный, и что делать? У меня такое было.

Вы скажете — почему я? Почему я должен быть вот таким вот? Потому что технология и специализация приходят и уходят. За свой опыт я видел уже много всего разного и интересного, и это все неважно. Всегда можно применять свой опыт на новых технологиях.

Потом сейчас много говорят про AI — автоматизация придет и начнет писать код за нас. Мы, программисты, верим, что все другие профессии заменят роботы, а мы останемся этих роботов программировать. Это не так. На самом деле, у нас есть дофига работы, которая легко автоматизируется. И AI тоже будут это делать. Они будут писать функции за нас, они будут компоновать эти функции, и к этому нужно быть готовыми. Поэтому сейчас мы должны быть как можно более гибкими и продолжать учить какие-то новые вещи, которые приходят.

У мультидисциплинарных команд, как это говорится, лучше химия: они лучше общаются, лучше друг друга понимают, не тыкают пальцами и не обвиняют всех в своих проблемах. Кроме того, фуллстек-разработчики для организации, как правило, более полезны, поэтому они получают больше денег. Stack Overflow Survey показал, что в среднем у фуллстек-разработчика зарплата может быть вплоть до 50% больше, чем у узкоспециализированных разработчиков. Многие из них, так как все знают и умеют, идут дальше в стартапы, начинают свои бизнесы — это самый сок нашей профессии.

Это всё приходит с пониманием общей картины. Вы видите всю картину своего проекта: где проблема, где ее исправить, вместо того, чтобы запатчить одну мелкую штучку в своей специализации и сделать очередной костыль, потому что вам лень ждать, что там другая команда исправит на своей стороне. Вам проще не оверинжинирить, потому что оверинжиниринг часто связан с узкой специализацией. Вы будете глубже понимать, как все работает, станете более эффективными и будете делать меньше бесполезной работы и меньше глупых ошибок.

Кроме того, ваш проект в принципе обречен, если у вас нет ни одного члена команды, который был бы фуллстек. Вы, конечно же, скажете, что фуллстек вашей команды — это архитектор. Он все знает, он опытный, он крутой, он старый, и все офигенно. Но на самом деле, по своему опыту, такие архитекторы, которые специализируются или переспециализируются на архитектуре и перестают писать код, очень скоро перестают быть релевантными. Они уже больше не могут мыслить правильно и становятся полностью бесполезными людьми в команде.

Побочные эффекты фуллстека

Как фуллстек разработчик, вы будете более прагматичны. Вы не будете прыгать на каждый новый фреймворк во фронтенде, который появляется каждый месяц. Может быть, вы его попробуете в свободное время, но опять же поймете, что вот эту фигню я уже видел в 90-ые, но чуть-чуть в другом виде.

Вы будете выбирать для себя то, что скорее всего не пропадет в следующий год. Например, я недавно пытался делать онлайн-чекин в нескольких известных авиалиниях, и там поменяли всю систему. Там какие-то крутые чуваки вот в таких клетчатых рубашках переписали всё на single-page application, и они реально не умеют даже ошибки правильно обрабатывать. И поэтому, чтобы сделать онлайн-чекин в Lufthansa, нужно заходить в developer tools и смотреть, где у них там что завалилось, что я не так ввел.

Как фуллстек, вы знаете цену реализации отдельных вещей в разных частях проекта. У вас есть понимание, где вам это аукнется дороже. Вы беспокоитесь о том, чтобы вы или другие ваши коллеги долгосрочно могли это поддерживать.

Наконец, вы не берете слишком инвазивные фреймворки, которые пытаются полностью контролировать вас. Когда этот фреймворк кто-то перестанет мейнтейнить, вам придется отвечать за то, что ваше приложение работает. Даже если вы покупаете какие-то крутые инструменты: в мире проприетарного софта раньше было популярно купить какой-нибудь BEA WebLogic, ESB, крутые системы. Но потом, когда они разваливаются на продакшене, у вас нет времени звонить им в саппорт в Индию и ждать, пока они придумают, как вам это решить. Вы должны сами решить эту проблему, декомпилировать их ужасный код и понять, где он заваливается, что придумать, как его обойти. Поэтому вам лучше не использовать такие вещи, которые контролируют вас. Лучше всегда писать такой код, который будет контролировать все остальные компоненты.

Давайте подумаем: кто из вас знает, как написать полностью с нуля свой текущий проект? А если мы еще включим сюда сторителлинг, то есть сбор требований? Вы смогли бы целиком всё это сами сделать? Если вообще всю команду переедет грузовик? Как вы думаете, если вы перепишете свой проект сейчас с нуля, он будет лучше? Зависит от того, кто это будет делать, насколько вы уверены в себе. В английском есть такое понятие как «can do attitude» — это нужно в себе развивать.

Саппорт-роли: игра в испорченный телефон

Всем известно, что мы, как программисты, прошли немного дальше, чем другие люди. Поэтому другие люди говорят, что с нами сложно общаться. На самом деле, я недавно читал классную статью, где говорили о том, что проблема заключается в том, что программист ценит точность. Ему очень важно говорить точные факты, потому что работа программиста очень сильно зависит от точности. Мы должны точно имплементировать какие-то вещи, а не «а ну вот может так, а может по-другому». А обычно люди говорят именно так, поэтому возникает недопонимание.

Но у нас в командах, кроме разработчиков, есть тестировщики, аналитики, проджект-менеджеры, продакт-менеджеры, как их модно сейчас называть. Например, до создания Codeborne я работал в компании Swedbank. В 2010 году это был, наверно, самый инновационный банк в мире, и даже там из 700 сотрудников IT-отдела только 50 были разработчики. Возникает вопрос — что делают остальные? А вроде бы все что-то делают.

Это называются поддерживающие роли. Они существуют именно потому, что программисты не умеют делать свою работу как положено. Мы не умеем общаться, не хотим общаться, не хотим тестировать свой код, мы выкидываем это все куда-то и кто-то там пусть разбирается с этим. Мы даже иногда не хотим собирать свой код нормально, мы просто его наколбасили, а кто-то пусть его пытается собрать, нормально, да?

Поэтому появляются такие люди, и они нас превращают в code monkeys. Эти позиции позволяют нам, программистам, не развивать свои навыки общения. Естественно, от этого снова падает эффективность. Мы показываем друг на друга пальцами, обвиняем, играем в испорченный телефон. Детская игра, сами помните: пошептали, пошептали и всё исказилось нафиг.

В Codeborne я очень много замечал такую проблему: если мы общаемся с посредником, он всегда будет отстаивать точку зрения, которую ему когда-то сказали. С ним невозможно провести какие-то переговоры, чтобы что-то изменить. У разработчика часто есть гораздо более удачная идея, как решить какую-то проблему, но вы упретесь в этого мессенджера, который никогда не передаст вашу идею дальше к реальному заказчику. И это очень плохо. Поэтому в проектах мы всегда ищем правильного человека, чтобы с ним говорить. Если вы говорите с неправильным человеком, то у вас уже почти завалился проект.

Кроме того, неужели вы действительно думаете, что тестировщики до сих пор обязаны за вами убирать ваши баги? На самом деле, тестировщики, если они есть у вас в команде, должны быть уже финальной линией защиты. Если они что-то нашли, то это плохо, поэтому вы должны стараться отвечать за свое качество.

Многие из вас, наверное, видели эту картинку. Это офигенный пример того, насколько все роли в IT не умеют говорить друг с другом и понимать друг друга. Заказчик тоже никогда не знает, чего он хочет. Как мы видим, в начале он хотел трехступенчатую качельку, а на самом деле ему нужна была подвешенная шина. А что сделали разработчики, лучше вообще не смотреть. Это, к сожалению, типичная ситуация в IT.

Несмотря на это, мы все равно зарабатываем хорошие деньги, нам все равно платят, хотя мы делаем ерунду, делаем долго-дорого и так далее. Наши бедные клиенты берут то, что им дают, со всеми багами и неправильной реализацией. И мне очень жаль смотреть на команды или на бизнесы, которые не могут сделать time to market хотя бы в пару дней, чтобы выкинуть свой код в продакшен. Код, который реально имеет ценность для бизнеса: заработает деньги или даст что-то понять. Нет, они ждут месяцами, пока им что-то наколбасят, полуразваленное выкатят на продакшен, а потом еще и назад откатят.

Манифесты Agile, Scrum и Software Craftsmanship

Чтобы решить все эти проблемы, в 2001 году в Колорадо на горнолыжном резорте собрались умные люди и сказали: «давайте напишем, как правильно надо делать». Они написали Agile Manifesto. В нём были очень важные и классные идеи, которые люди в наше время уже не понимают, поэтому сейчас мы пришли к упадку agile.

Сейчас очень многие организации думают, что они делают agile, и пытаются его продавить сверху. Пришли консультанты, как обычно, продали скрам менеджерам, менеджеры сказали: «да, офигенно, это должно работать, давай продавим это на наших разработчиков». Разработчики берут, смотрят, говорят: «что это, как с этим действовать, я так не привык». Естественно, это не работает.

Сейчас весь скрам превратился в полный buzzword. Например, extreme programming пропагандирует техническое совершенство — но где это совершенство?.. А скрам теперь просто buzzword, оно больше ничего не стоит. И даже Кен Швабер, изначальный создатель скрама, ушел из Scrum Alliance, потому что это все превратилось в армию консультантов: они прошли двухдневный курс и говорят, что знают, как наладить процессы в организации. Это стало религией, которую никто не знает, как практиковать.

Но мы можем делать лучше. Через какое-то время появился новый манифест. Манифест получился еще круче, он назывался «Manifesto for Software Craftsmanship».

Например, Agile-манифест говорит, что самое важное — это работающий софт. То есть, если вы написали кучу документации, анализов и так далее, но у вас ничего не работает, то это все бесполезно потраченное время. И это правда. Но! Крафтсмены говорят, что софт должен не только работать, но еще и быть очень хорошо сделанным. Если он у вас заработал, но разваливается, то это не то, что вы хотите создавать.

Вы должны не только реагировать на изменения вместо слепого следования изначальному плану, вы должны постоянно добавлять value своему продукту, клиенту. Вы должны, как мы сейчас, встречаться на конференциях, обсуждать, как делать лучше. Важно работать с комьюнити напрямую и продуктивно, как partnership.

Craftsmen, craftsmen, craftsmen!

Помните такого чувака, который на сцене кричал «developers, developers, developers»? Я бы вместо этого покричал «craftsmen, craftsmen, craftsmen» (и «craftswomen»)!

Что должен уметь крафтсмен?

Настоящий мастер нашего искусства программирования должен:

• Уметь общаться с клиентом напрямую. Это то, что в нашей команде обязательно: у нас все общаются напрямую, никаких посредников.
• Понимать, какую проблему надо решить (а не то, что вам объясняет клиент). Потому что клиент никогда не может объяснить свою проблему. Мой опыт показывает, что клиент всегда приходит и объясняет вам то решение своей проблемы, которое он себе в голове уже придумал, и чтобы понять, какую проблему он решает, с ним нужно достаточно долго говорить, чтобы понять, где реально суть.
• Предлагать решения (скорее всего, другие): как лучше решать эту проблему, какой софт писать. Иногда вообще не писать софт, это тоже вариант, проблемы бывают разные.
• Уметь разбивать проблему на маленькие кусочки, записывать их как пользовательские истории. Это все тоже идет из Agile, из экстремального программирования, это тоже никто не отменял.
• Придумать, как это должно пройти через UI. У вас, конечно, могут быть какие-то дизайнеры в помощь, но все равно вы должны понимать, где логика.
• Писать работающий код, естественно.
• Писать автоматические тесты для своего кода, чтобы ваше следующее изменение не поломало что-то из предыдущего. Тестировщики никогда не найдут ваши супер-спрятанные фичи, которые вы поломали в очередном билде, это найдут ваши конечные пользователи, и они будут очень обижены на вас.
• Уметь запустить свой софт. Просто написанный софт в git бесполезен без того, чтобы он легко и понятно запускался.
• Естественно, развивать свою систему дальше, то есть она должна расти и жить. Любая IT система существует и растет гораздо дольше, чем вы будете над ней работать, и вы должны уметь с помощью рефакторинга вести ее дизайн и архитектуру в будущее. А не так, что у нас все настолько плохо, нам нужен один месяц на рефакторинг. Слышали когда-нибудь такое от разработчиков?

И знаете, в чем проблема? Традиционный, старомодный software developer занимается только одним пунктом из этого списка — написанием работающего кода. Посмотрите, насколько нужно делать это всё, чтобы делать нашу работу реально хорошо. И это нужно постепенно пытаться учиться.

Это то, что мы делаем в Codeborne, это реально очень круто работает. Мы можем командой из 2-4 человек сделать проекты, про которые люди думают: «нам, наверно, нужно будет 50 человек на год», а мы делаем это за несколько месяцев. Это более креативно и весело, когда вы на самом деле видите эту большую картину, когда вы общаетесь с людьми. Если вы являетесь крафтcменом, на вас больше не смотрят как на какого-то нерда или ботаника, с которым невозможно общаться, вы становитесь более полноценным человеком. Это полезная для вас фича в жизни.

Как решить проблему не кодом? Пример из жизни

Один пример того, как проблемы могут решаться вообще не кодом. В Эстонии как-то несколько лет назад запустили систему электронных рецептов. Даже в нашей крутой Эстонии бывают косяки: ее разработали, запустили, а потом в час пик, когда в пять часов после работы все идут в аптеки покупать себе лекарства, система падала. Ужас, что делать?

Министр позвонил нам, говорит «Спасайте, ребята». Мы посмотрели, что они там натворили. Там был адский оверинжиниринг: каждая команда делала свою часть, какие-то сервисы друг с другом общаются, все такое. Мы предложили: давайте вот эту парочку сервисов уберем из цепи и сделаем вот тут напрямую.

Перед этим они говорили, что нужно покупать еще железо: мол, мы купили такое крутое, а нужно покупать еще более крутые серваки, чтобы это все выдержало. Когда мы убрали эти ненужные компоненты, система начала работать на текущем железе с минимальной нагрузкой. Так что очень часто не надо писать новый код, чтобы все исправить. Очень часто удалять код тоже круто.

Стартапы и крафстмены

Посмотрим на стартапы. Чтобы стартап вообще существовал, необходимо full-stack craftsmanship: стартап просто не может себе позволить по-другому. И, естественно, этому тоже нужно учиться. Нужно иногда брать себе «мышление стартапа», хотя бы в своей команде.

На самом деле, как ни странно или плохо это звучит, у «голодных людей» без денег гораздо круче производительность, они умеют все оптимизировать. Но, к сожалению, в наше время в мире слишком много свободных денег. Инвесторы вливают в стартапы кучу бабла, и теперь стартапы тоже часто купаются в деньгах, тратят не свои деньги и теряют эффективность. Они тоже создают эти microservice teams, начинают что-то долго-долго колбасить, думают «ну ладно, через пару лет, может, что-нибудь запустим».

Это тоже тренд, который настораживает, несмотря на то, что стартап — это все еще такая зона, где нормальное правильное программирование все еще могло бы существовать.

Underengineering

Есть такая классная фраза, которую приписывают Эйнштейну. Естественно, Эйнштейн умный чувак, поэтому ему можно приписывать разные умные фразы. На самом деле, по-моему, он этого не говорил, но фраза такая: делайте все настолько просто, как можно, но не проще, чем можно. В этом очень важный пойнт, особенно для стартапов.

Представляете вот такой дом? Противоположность оверинжинирингу — это андеринжиниринг, то, что иногда приходит из мира стартапов, у которых мало денег. И они обычно делают все по-быстрому тяп-ляп, потому что у них мало времени, им нужно как можно быстрее что-то запустить.
На самом деле, как говорил дядя Боб, у вас нет времени писать плохой код, потому что он вас замедлит позже, и у вас будет еще меньше времени дальше, если вы сейчас напишете плохой код по-быстрому. Нужно писать сразу хороший код с тестами, и тогда ваш стартап тоже будет куда более успешным.

Андеринжиниринг значит, что вы не соблюдаете основные важные базовые практики. Например, я видел, что если в проекте нет continuous integration, это почти всегда всегда ведет к поломанному проекту, здесь нет исключений. Мы всегда можем сказать, что у нас крутые разработчики, они все сразу исправляют. Но нет, очень легко все запороть, и потом все другие члены вашей команды будут мучиться и решать все одну и ту же проблему, потому что у вас проект не собирается, например.

Недавно видел один стартап, который чуть-чуть пишет юнит-тесты. Но мы их пока в Jenkins не добавили, говорят, Jenkins еще пока что наши тесты не запускает. Я спросил, сколько у них сейчас зеленых тестов. Конечно, все зеленые, говорят. Ну, давайте запустим. Думаете, много там было зеленых тестов? Парочка, наверно, была.

Даже в строительстве всегда есть прораб, который проверяет всё. Вот у нас в программировании прорабом мог бы быть хотя бы continuous integration. Поэтому обязательно запускайте его, обязательно следите, чтобы у вас было все в порядке.

Практики экстремального программирования

Экстремальное программирование зиждется на вот этих базовых практиках. Как вы видите на этой картинке, они все друг с другом соединены.

Многие люди думают: давайте возьмем парочку отсюда, а остальное может быть когда-нибудь добавим, но скорее всего никогда. Если вы не используете большинство из них, то может произойти так, что и те, которые вы выбрали, будут не очень хорошо работать.

Обязательно нужно, чтобы у вас был и общий coding standard, и continuous integration, и collective code ownership, и тестирование, и короткие релизы, и постоянный рефакторинг. Когда вы берете новую фичу или стори и имплементируете, вы всегда должны сделать перед этим небольшой рефакторинг, чтобы ваш код стал лучше, и ваша фича хорошо туда легла. Если вы этого не делаете, то потом будете у проджект менеджера спрашивать месяц на рефакторинг. И что он вам скажет? Скажет «у нас сейчас нет на это времени».

Многие думают, что экстремальное программирование — это что-то вот такое. Это плохое название. На самом деле это дисциплина, это практики, которые нужно применять в любой команде. И agile, и экстремальное программирование всегда приводится в команду снизу вверх, а не сверху вниз. Команда разработчиков должна понять, что вот так они будут гораздо лучше перформить, они должны пытаться начинать это делать между собой, и только тогда менеджмент сверху увидит, мол, смотрите, эта команда делает всё в три раза круче, быстрее и качественнее, чем другие команды. Так было когда-то с нами в Swedbank, до того, как мы создали свою компанию.

Codeborne Routine

Например, когда мы в Codeborne делаем проект, то это выглядит так.

1. До начала проекта мы ищем правильные контакты на стороне клиентов.
   Всегда есть заказчик, и мы должны найти кого-то, кто реально умеет принимать бизнес-решения, и кого-то, кто может принимать технические решения. Еще лучше — это когда технического человека на стороне заказчика нет. Это значит, что мы можем все сделать правильно, и никто нам не будет мешать.
2. Потом мы делаем с ними kick-off митинг, на котором мы делаем сторителлинг.
   Если у клиента есть 300 страниц какой-то спецификации, которые они три годы писали, то мы ее обычно не читаем, потому что она скорее всего уже устарела на тот момент, как мы собрались все вместе. Мы говорим: давайте попытаемся разбить и понять, что для нас самое важное, что вы хотите получить за первую-вторую неделю. Через две недели — что вы хотите, чтобы у вас уже работало.
   Конечно, они обычно говорят «мы хотим все», а мы отвечаем — давайте еще раз, что вы хотите получить через две недели. И так можно привести к тому, что они реально раскроются, придумают, и смогут разложить что-то на маленькие кусочки, на приоритеты. Мы им, естественно, в это помогаем.
3. Потом наши итерации длятся по одной неделе.
   Это не слишком коротко, это как раз хорошо. Мы каждый день делаем стендап митинг, если у нас удаленные клиенты, то через видео. Потом девелоперы работают над пользовательскими историями, которые мы вместе написали в начале недели. Естественно, continuous integration сервер это все билдит и тестирует после каждого изменения. Потом это все автоматически идет на демо-сервер, так что заказчик может в любой момент открыть демо-сервер и посмотреть самый свежий вариант нашего работающего софта. Софт работает постоянно, каждую минуту. Нет такого, что он работает только раз в неделю, когда мы постараемся и соберем его с танцем с бубном.
4. В конце у нас итерационное планирование.
   Мы встречаемся, показываем еще раз, проходим по тому, что мы наколбасили. Появляются новые идеи, новые появляются истории. После этого опять приоритизация, новый сторителлинг, и вот это все продолжается до момента, пока, клиент не скажет, что теперь офигенно, выкатываем реальным пользователям.

И чем раньше это делаешь, тем лучше, потому что весь agile — он про то, что вы должны получать обратную связь. Вы должны получать фидбек постоянно: каждую неделю от заказчика, даже чаще. Чем чаще вы это выпускаете на реальных пользователей, тем быстрее вы получаете от них фидбек, что вы сделали не так, что вы можете сделать лучше. Вы опять меняете свой план, опять делаете то, что нужно.

Парное программирование

Естественно, все это работает у нас благодаря парному программированию. Парное программирование очень важно, особенно для того, чтобы быть фуллстек. Все равно всегда, как ни крути, найдется кто-то, кто знает какую-то тему лучше, кто больше с этим работал. Например, если я сяду в пару с кем-то, кто знает какую-то тему лучше меня, я очень быстро и эффективно научусь от него каким-то фишкам.

Вся команда обменивается опытом гораздо быстрее. Скиллы в командах движутся очень быстро, команда быстро доходит до одного уровня. Если в команду приходит новый член, он может начать перформить с первого дня. Вы никогда не остаетесь в одиночку со своей проблемой, вы никогда не сидите, не возитесь, нет такого, что вы не понимаете, что происходит. У вас есть всегда вторая голова, которой можно как минимум пожаловаться или с которой можно поговорить о своих проблемах.

Вообще для меня программирование — это уже давно постоянная коммуникация. Я никогда не коммуницирую с компьютером, я коммуницирую со своим напарником. Мы говорим нон-стоп, у нас рот не закрывается, и чуть-чуть кода тоже рождается.

Как правило, у нас два монитора, один комп, две клавиатуры, две мышки. За одним компом одну и ту же картинку видят два человека, любой может начать печатать в любой момент, и роли «драйвер/навигатор» могут постоянно меняться. Кто ведет, кто показывает. Как говорят по-русски, одна голова хорошо, а две лучше. Разная специализация помогает достигать лучшего результата, еще она помогает переносить и учить.

Откуда вообще пришло экстремальное программирование, само название — многие хорошие вещи, которые есть в программировании, вы доводите до экстремальности. Как, например, код-ревью. Вы делаете постоянный нон-стоп код-ревью в паре. Поэтому ваше качество гораздо лучше.

Человек создан так, что у каждого есть его собственные ценности, которые он обычно не переступает, но только если кто-то смотрит. А если никто не смотрит, то свои ценности переступить очень легко, потому что он знает: я сейчас это по-быстренькому сделаю, а потом исправлю. Когда кто-то сидит рядом, это уже не так всё работает.

Это гораздо более прикольно. На работе реально весело: не так, что ты приходишь в депрессняк, ну вот, опять мне нужно дебажить эту фигню, которую я уже три дня дебажу.

Заключение

Говорят, что хороший разработчик может быть в пять раз более продуктивным, чем средний. Я бы сказал, что крафтсмен может быть еще в пять раз эффективнее хорошего разработчика, потому что он будет знать, что НЕ надо делать. Он будет сам общаться, будет лучше это видеть. Мы не только пишем код, мы на самом деле решаем проблемы. Этот код — это побочный эффект решения проблем. И я надеюсь, что вы тоже хотите быть такими.

Еще один интересный пример, кто из вас был в Стокгольме? Там есть офигенный корабль XVII века Vasa. Шведский король сказал: «давайте построим самый крутой корабль в мире с двумя палубами с пушками». Ему инженер сказал, мол, так не работает, задуманный вариант потонет. Но король сказал «Нет, делай так, иначе секир башка».

Ну, сделали корабль. Он проплыл 1300 метров и сразу же затонул недалеко от Стокгольма. За счет этого он хорошо сохранился в иле, его в 90-е достали и сделали музей. Но это классический пример того, когда инженер не сделал хорошую работу. Он послушал навязчивого заказчика-короля и получилось как всегда.

Под конец я хочу привести еще одну цитату. Эта цитата, по-моему, действительно Антуана де Сента Экзюпери: «Совершенство достигается не тогда, когда вам больше нечего добавить, а когда вам больше нечего убрать». Это когда у вас самый крутой софт. И таким образом, мы можем творить офигенные вещи. Спасибо!

Чтобы стать мастером своего дела, важно понимать и разбираться во многих вещах — и в разработке, и в тестировании с автоматизацией. Мы анонсировали 8 конференций осеннего сезона — и для фуллстека это просто кладезь полезной информации. Купить абонемент сразу на все можно на сайте.