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

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

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

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

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

Интро: о Таллине и 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меном, на вас больше не смотрят как на какого-то нерда или ботаника, с которым невозможно общаться, вы становитесь более полноценным человеком.