Хабрахабр

Blameless environment: никто не должен писать качественный код

На РИТ++ Никита Соболев (sobolevn) выступил, как он сам назвал это, с проповедью на тему качества кода и процессов в компании. Особо впечатлительных просим налить себе ромашкового чаю, но отойти от экранов не предлагаем. Вы можете не соглашаться ни с одним из тезисов, настаивать, что трёп о сериалах — залог здоровой атмосферы в коллективе, и утверждать, что вам не нужны строгие рамки линтера и CI, чтобы писать хороший код. Но если вы хоть раз винили окружающих в неудачах на работе, вам стоит прочитать или посмотреть рассказ Никиты.

Работали ли вы когда-нибудь на плохой работе?

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

Когда я говорю, все плохо, я имею в виду, что у нас был:

  • плохой код — никто не думал о качестве кода, никто не мог даже сформулировать, что такое качество кода.
  • плохие процессы.
  • мы не могли нормально общаться,
  • мы не делали то, что хотел клиент.

Да, это была аутсорс-разработка, но не это делало её плохой. Люди сделали ее такой.

Люди виноваты в том, что я не получаю удовольствия от своей работы. «Люди делают плохой работу, это люди виноваты в том, что процессы плохие, код некачественный и клиенты вредные» — эта мысль терзала меня на протяжении многих лет.

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

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

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

Я хотел работать в хорошем месте. Я понял — нужна революция, нужно, чтобы все изменилось: то, как я работаю, как я себя ощущаю, чтобы поход на работу не становился для меня испытанием.

Проблема была только одна — это была моя компания.

Я тот человек, который начал эту революцию.

Я люблю программировать, готов заниматься им по 12 часов в день и называю его своим отдыхом и своей работой. Я понял, что нужно поменять все, чтобы снова получать удовольствие от любимого дела.

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

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

Но когда смотришь в хаос, не видно закономерностей — ничего, что бы указывало на то, как должно быть.

Создать порядок из хаоса — это акт творения, который дается тяжело.

Нужно начать с самого-самого начала, чтобы понять, когда все полетело в хаос. Нужно определить новый порядок и объяснить себе, что нужно делать. Это красивые слова: «Давайте все делать хорошо!». Но ты приходишь на работу и на самом деле не понимаешь, за что браться, чтобы все изменить, нет никаких идей.

Полученное образование и прочитанные книжки не помогают, потому что все, что ты делал до этого, ты почерпнул из этих книжек и из этого образования.

Постановка задачи

Тогда я задумался — а в чем же самая большая проблема? Где самая больная точка, которая не дает жить и работать? Я понял, что это постановка задачи. Для меня постановка задачи всегда была достаточно необязательным делом.

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

Но в какой-то момент я все-таки понял, что нужно делать это абсолютно по-другому, и выработал несколько принципов. Тогда я не осознавал, что действительно плохо ставлю задачи.

Не в плане описания, как «поправить баг на проде», но короткие по своей сути. Задачи должны быть короткие. Они понятны любому: новичку, среднему, опытному разработчику. Короткие, маленькие задачи удобно делать. Можно начать с этого. Каждый может понять такую задачу и сделать, например, за половину рабочего дня.

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

Но немногие задумываются, а в каком порядке, почему и зачем порядок именно такой. Про упорядоченность задач говорят очень мало: заносят их в Jira или Trello, а потом берут оттуда.

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

Когда задачи стали индивидуальными, короткими и упорядоченными, люди начали делать их так, как я хочу.

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

Я подумал, что если разработчики стали понимать наши задачи и делать их как надо, могут ли они понять, чего на самом деле хочет заказчик, и сделать так, как хочет заказчик? Мы часто подводили заказчика, делали не то, что принесло бы ему пользу.

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

В целом такой подход называется Domain-Driven Design и успешно применяется на протяжении многих лет. Это задача не новая. Я решил взять лучшее — способ общения, инструментарий, технологии, и постараться сделать так, что разработчики стали понимать, что нужно сделать, чтобы удовлетворить желания клиента.

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

С них все начинается, заказчик изъявляет свою волю нам, разработчикам, в виде требований. Требования. Начинается их осознание, расписывание в виде таблиц, списков, графиков и т.д. Клиент условно говорит: «Требую, чтобы страница логина работала». Это то, что ты делаешь на самом высоком уровне. Требования остаются с тобой как самая главная часть твоего проекта.

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

Требования — это ЧТО нужно сделать, а документация — КАК это делать. Документация и требования — это близнецы-братья, это двуединство.

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

Следующий логичный шаг — проверить, что это работает. Тесты. Мы стали тестировать наши требования, чтобы убедиться, что делаем действительно что нужно.

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

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

Для того чтобы заказчик и разработчик соединились, казалось бы, нужно залезть одному из них в голову и сделать так, чтобы они поняли друг друга. Код — ради чего все собственно и затевается. Здесь можно прочитать, как я это делаю на практике. Но чтобы залезть в голову, можно взять те же инструменты и соединить их так, чтобы разработчик начал понимать, что происходит.

Они перестали внедрять что-то просто так, потому что видели требования и понимали их, понимали, что нужно сделать. Как только мы объединили (Код един!) разработчиков и заказчика при помощи таких хитроумных переплетений разных сущностей, мы добились очень важного: наши разработчики наконец-то стали делать то, что нужно бизнесу.

Чтобы убедиться в выполнении, у нас есть тесты, которые написаны в виде требований, и эти требования достаточно понятны, чтобы реализовать их понятным языком в коде, и писать хороший код по этим требованиям.

Общение

Я уже очень много раз упоминал «общение». Я люблю общаться со своими друзьями и семьей, но не на работе. На работе я вынужден общаться с людьми — я их не выбирал по этому признаку. Очень часто общение на работе не помогает.

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

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

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

Митинги крадут огромное количество времени и не приносят пользы.

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

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

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

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

Чтобы структурировать общение, достаточно сделать два шага:

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

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

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

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

У GitLab даже аватарки все примерно одинаковые — у одного буква K, у другого C, и я не знаю, кто эти люди. Структурированное общение делает разных людей одинаковыми. Мне все равно, какие они, главное — они общаются в рамках структуры.

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

Код

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

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

Но раз так, с этим можно что-то делать и научиться работать именно в этих условиях.

Это должен быть Страшный Суд — инструмент, который ответит на вопрос, хороший код или плохой. Для того, чтобы с этим работать, нужна строгость — CI и тесты, которые будут максимально строги к тому, что ты делаешь. Только взглянув на него, всевидящее око CI скажет, попадет ли твоя работа в master или так и останется где-то на stage.

Такой CI, естественно, должен быть неотвратим. Как только кто-то получает исключительное право коммитить в master, все попытки построить процессы разваливаются, потому что этот кто-то начинает делать всякую ерунду.

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

Как только фундамент готов, можно двигаться дальше.

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

Можно вернуться к обычной тактике и говорить: «Ты сделал ошибку, исправь ее. Что можно с этим сделать? Это плохой путь, который не ведет к развитию. Ты написал плохой код — иди научись писать код».

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

Blameless environment

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

Ты начинаешь думать головой и делать так, чтобы баги не повторялись. Когда начинаешь не просто фиксить баги и надеяться, что все не развалится на продакшене, но исправляешь их на системном уровне, начинаешь творить и созидать — создавать новые инструменты, вырабатывать новые подходы и архитектурные паттерны.

Ты начинаешь изобретать инструменты для разработчиков, внедрять их, продвигать и т.д. Постоянная работа над ошибками выводит разработчика на принципиально другой уровень.

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

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

И это работает, потому что такие инструменты помогают в работе. Подход сохраняется, мы ждем ответа машины, хорошо сделана программа или нет.

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

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

Каждый следующий шаг имеет смысл только тогда, когда есть фундамент предыдущего.

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

Давайте поговорим о дарах — какие дары есть в разработке.

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

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

Человек, который зарепортил баг, если он не тестировщик, слышит: «Что ты делаешь? Но почему-то в нашей данности баг — это плохо. Мы же фичи должны делать, а ты какие-то баги находишь». Ты срываешь сроки. Но на самом деле все наоборот. Предъявлять баг — значит говорить, что что-то не работает, что-то плохо.

Скрытый баг — это плохо, найденный баг — это хорошо.

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

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

Я не хочу, чтобы вы слушали эмоции, я хочу, чтобы вы думали головой. Я не хочу углубляться в оплату, потому что в этом вопросе со мной обычно несогласны, причем настолько сильно, что перестают слышать рациональные аргументы, а слышат только эмоции.

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

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

Эту систему можно исправить, и сделать это несложно. Вы можете взять все те инструменты, которыми пользуемся мы, поставить их себе и работать. Они все в open source, поэтому вы легко можете начать делать так же.

Имплементация

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

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

Фактически нам все равно: собираешься работать — хорошо, не собираешься — тоже ладно. Нет общения. У нас некому сказать, что ты сегодня не собираешься работать или собираешься работать. Даже системы информирования об этом нет.

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

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

Так можно сделать очень и очень многое, потому что код можно линтить, тестировать, отслеживать его изменения во времени и т.д. Всё код. Когда работаешь с разработчиками, пишешь требования как код, документацию как код, всё как код, понимаешь, что всё код. Код един!

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

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

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

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

Чтобы рассмотреть все аспекты разработки качественных продуктов мы запустили QualityConf, в этом году в рамках РИТ++, а в следующем — вынесем в отдельное мероприятие. С приходом Agile многие команды осознали, что за качество отвечают не только тестировщики. Видео прошедших выступлений смотрите здесь, а чтобы не пропустить информацию о конференциях, подпишитесь на рассылку.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть