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

Данная статья является переводом. Emily Dresner. Ссылка на оригинал.

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

Этот вопрос возникает постоянно.

• Почему техлид (tech lead, сокращенно — TL) не должен управлять командой?
• Почему технический менеджер (engineering manager, сокр. EM) не должен проводить код-ревью?

Как и все в технике, ответ зависит от ситуации. Здесь я пытаюсь ответить на извечный вопрос: «Почему TL не должен руководить командой и почему EM с командой достаточного размера не должен проверять код?».

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

Предупреждение: впереди очень легкая математика.

Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста»

Интересно, перейти к каналу

Разница между ролями менеджера и техлида

Во-первых, давайте опишем роли. Технический менеджер и техлид— это две разные роли с разными наборами навыков. Кто-то может быть хорош в одной роли, но не в другой (и наоборот). Например, лучший программист в команде не всегда лучший организатор.

Однако для оптимальной работы команде нужны обе роли. Итак, давайте сравним и сопоставим роли.

Данное изображение и все остальные взяты отсюда. Разница в роли и ответственности между TL и EM

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

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

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

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

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

• Давайте посмотрим, почему размер >= 4 является точкой перегиба.
• Статья по теме
• ???? Как создать настоящую команду: ТОП-10 книг о тимбилдинге

O(n²) сложность связи

Во-вторых, давайте поговорим о коммуникациях. Менеджер строит хорошо работающую команду на прочных основах коммуникации.

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

Мы интуитивно думаем, что сложность взаимодействия в команде возрастает на O(n) по мере того, как мы добавляем людей в команду, но здесь Mythical Man Month на 100% соответствует действительности.

Сложность коммуникаций в команде возрастает (n * (n-1))/2) по мере того, как к команде присоединяются новые люди, или за O(n²) квадратичное время.

• Сначала вы единственный человек в своей команде, поэтому весь день разговариваете сами с собой. 0 путей сообщения, и не забывайте делать перерывы на здоровье.
• Вы добавляете 1-го человека А в свою команду. Теперь вы разговариваете с А, а А разговаривает с вами — 1 канал связи.
• Вы добавляете 1-го человека B в свою команду. Итак, теперь вы управляете тремя коммуникационными путями — вы — А, вы — Б и А — Б.
• Вы добавляете в команду еще 1-го человека C. Итак, теперь вы управляете шестью коммуникационными путями.
• И так далее.

Визуализация путей коммуникации в команде — каждый должен говорить со всеми!

Как только мы создадим команду из 5 человек (всего 6, вы + 5 инженеров) и добавим менеджера по продукту и специалиста по данным, менеджер команды должен поддерживать (8*7)/2 = 26 взаимосвязанных каналов связи, чтобы команда могла работать. Добавьте несколько команд партнеров и займитесь маркетингом, продажами и обслуживанием клиентов — управление командой внезапно становится повседневной работой.

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

• Четкое определение приоритетов.
• Введение командной работы.
• Согласование статуса и релизов с заинтересованными сторонами.
• Бесперебойное управление процессами команды.
• Обсуждение командных и индивидуальных целей, ожиданий и результатов для карьерного роста.
• Распутывание коммуникационных узлов в команде.
• и т. д.

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

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

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

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

«Взрыв сложности» не объясняет, почему менеджер не должен программировать, но объясняет, почему календарь менеджера превращается в «классический календарь менеджера» при определенном размере команды, а время становится ценным.

Давайте визуализируем это и посмотрим.

Кривая размера команды

В-третьих, мы говорим об общении с командой. Мы все здесь инженеры. Если мы можем что-то сделать, так это графики.

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

График зависимости размера команды от коммуникационных взаимосвязей

При 1–3 членах команды коммуникационными соединениями управляет группа. Группа еще маленькая.

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

Законы квадратуры начинают действовать после 4-х, когда нужно согласовать 6 путей.

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

4 — это магическое число, когда TLM должен сделать выбор между Техническим руководителем или Техническим менеджером, но не обоими сразу.

Рассмотрим команду из 5-ти человек. Что произойдет, если никто не выступит и не возьмет на себя коммуникационную роль в команде? Чаще всего команда скатывается в трэш и перестает двигаться вперед по своим приоритетам.

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

Эта роль — полноценная работа.

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

Отступление: О TLM-инжиниринге

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

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

В результате TLM оказывается в тупике: он выполняет две роли одновременно (плохо), не имея возможности управлять масштабами (техническими или командными).

В конечном итоге, TLM придется выбрать одну роль для инвестирования 100% своего времени, иначе он окажется в застое.

Почему технический менеджер не должен проводить код-ревью

Наконец, сведя эти следы вместе, мы установили два факта:

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

При размере команды >= 4 технический менеджер должен сосредоточиться на своей основной роли — управлении коммуникациями внутри и вне команды, сосредоточении внимания на росте инженера (также на коммуникациях) и понимании приоритетов команды (опять же на коммуникациях). А при размере команды >= 4 технический руководитель должен сосредоточиться на архитектуре, технических решениях и технической работе команды. Разделяй и властвуй — вот как команда добивается успеха.

Выводы:

• Основная роль технического менеджера заключается в управлении коммуникациями внутри команды и за ее пределами, включая вопросы карьеры, производительности, планирования и настройки командных процессов. Эта коммуникационная работа требует значительных затрат времени.
• После достижения достаточного размера команды менеджер должен обменять техническую эрудицию на инвестиции в коммуникации, потому что коммуникационные взаимосвязи высоки.
• А при достаточном размере команды накладные расходы на коммуникацию могут быть настолько высокими, что менеджер должен выбирать и выбирать, иначе он будет перегружен одной этой работой из-за сложности.
• Технический менеджер, который выполняет код-ревью, не только пренебрегает своей основной ролью, но и контролирует техническое руководство на микроуровне. Эта деятельность является нарушением доверия.
• И это не только микроуправление, но и снисходительность к техническому руководителю.
• Это не означает, что технический руководитель не может участвовать в технических обсуждениях (особенно обзорах архитектуры), но технический руководитель управляет технологией.

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

17 выражений, которые понимают только айтишники — Лайфхакер

Означает всего лишь «поручить задание». Фраза произошла от английских слов to assign — назначать, поручать и task — задача. В ИТ‑сфере речь обычно идёт о распределении рабочих дел между сотрудниками в специальной программе‑менеджере.

• Пример употребления: Коллеги, на меня ничего не асайнить, уже вагон тасков в работе.

2. Дебажить код

Дебажить — это антоним к слову «бодяжить». Шутка! «Дебажить» значит проверять программный код на ошибки. Разработчик запускает режим отладки и ищет «баги», от английского bug — технический дефект. Кстати, ещё bug означает «жук» и «жучок» (для прослушивания). Соответственно, глагол to debug — избавиться от дефектов.

• Пример употребления: Если в том таске надо ещё и дебажить — на меня точно не асайнить!

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

Быстро улучшить свой английский можно в онлайн‑школе Skyeng. Там вы работаете один на один с преподавателем и разговариваете в два раза больше него — 60% урока.

Заниматься можно с телефона в любое время дня и ночи.

Записаться на бесплатный урок

3. Зарелизить/задеплоить

Термины происходят от английских слов to release — выпускать и to deploy — приводить в действие, разворачивать.

В ИТ‑сфере эти слова часто употребляются как синонимы и означают выпуск новой версии программы.

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

• Пример употребления: — Уже зарелизили новую программу? — Ещё нет, пока только задеплоили в тест и ждём ответа.

4. Зааджастить прогу

«Прога» говорят не только айтишники, но на всякий случай уточним, что это сокращение от слова «программа». «Зааджастить» возникло от глагола to adjust — приводить в порядок, регулировать. Айтишники говорят так, когда нужно немного поменять логику программы, слегка что‑то донастроить.

• Пример употребления: Клиент прислал новые требования, нужно зааджастить прогу.

5. Зафейлить/зафакапить

Fail и fuck up — это что‑то типа русского слова «косяк» разной степени интенсивности. Зафейлить — не справиться с чем‑то, совершить ошибку. Зафакапить — полностью провалить что‑то, например вообще не прислать выполненную задачу к сроку.

• Пример употребления: Мы уже профакапили все сроки, а в проге ещё куча багов!

6. Черрипикнуть хотфикс

Хотфикс — это прямая транслитерация слова hotfix. Hot — горячий или горящий по срокам, fix — исправление, починка.

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

Чтобы применить только новые изменения, не трогая остальных частей программы, есть операция cherry pick — что‑то типа выборочного переноса.

• Пример употребления: Черрипикните уже этот хотфикс, иначе нас всех уволят!

Чтобы быстрее справляться с хотфиксами и черрипиками, учите английский. Тогда не придётся ломать голову над непонятными словами в коде и всё мучительно гуглить. Чтобы записывать новую лексику в личный словарик прямо с экрана, установите расширение для браузера Vimbox Translate. Оно синхронизируется с мобильным приложением Skyeng и помогает вам быстрее запоминать слова.

7. Тэдэшка

Это милое слово происходит от аббревиатуры TD, которая расшифровывается как technical documentation. Это документ, где описаны логика и функциональность программы. Неудивительно, что айтишники сократили название: было бы жутко неудобно каждый раз говорить «техническая документация».

• Пример употребления: Мы не виноваты, что клиенту не нравится. Этих требований не было в тэдэшке.

8. Отревьюить доку/код

Глагол to review значит «оставлять рецензию», а загадочная «дока» — это всего лишь документ. «Отревьюить доку» может значить оставить комментарии в общем документе или просто дать своё мнение по поводу него. Ещё айтишники часто говорят «отревьюить код». Это когда опытные программеры смотрят разработки новичков.

• Пример употребления: Я жутко нервничаю, завтра мой код будет ревьюить вся команда.

9. Дрова полетели

Речь идёт не о летающих досках, а о сломавшихся программах. «Дрова» — это drivers, или драйверы.

В корне слова английский глагол to drive, что, помимо известного всем «водить», означает ещё и «управлять». Так называют программное обеспечение, которое управляет другими устройствами.

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

• Пример употребления: У меня весь экран в битых пикселях, похоже, дрова видеокарты полетели.

10. Апликуха

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

• Пример употребления: После последнего релиза апликуха стала работать в два раза медленнее.

11. Забэкапить

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

• Пример употребления: Вноси изменения в прогу, только не забудь забэкапить прошлую версию.

12. Кракозябры

Нечитаемый набор символов. Например, когда при запуске программы на экран выводится какая‑то бессмыслица из математических знаков и случайных букв. Есть мнение, что на это слово повлияло английское crack — разлом, трещина. Другие говорят, что это смесь «крокодила» и «зебры».

• Пример употребления: Открываю твою программу, а там кракозябры. Проверь кодировку.

13. Имплементить

Произошло от английского to implement — внедрять, осуществлять. Так программисты говорят о реализации какого‑то функционала. По сути, это всего лишь синоним глагола «делать».

• Пример употребления: Сегодня не успею всё заимплементить, доделаю завтра.

14. Пушить

И снова английский глагол. To push означает не только «толкать», но и «заставлять, принуждать». Так говорят, когда на кого‑то давят, чтобы, например, ускорить работу.

• Пример употребления: — Программа уже готова? Время идёт!— Вот только не надо меня пушить!

Мы не хотим вас пушить, но попробуйте позаниматься в Skyeng, чтобы лучше ориентироваться в английском и понимать сленг. Онлайн‑школа даже имплементнула специальное предложение для читателей Лайфхакера. По промокоду PUSHME у вас будет целых четыре бесплатных урока при покупке любого курса Skyeng. Промокод действует до 15.10.2019.

Начать учиться бесплатно

15. Дропнуть базу

To drop — уронить или прекратить что‑то делать. Но в ИТ‑сленге речь обычно идёт об удалении. Если слышите выражение «дропнуть базу», знайте, что эти люди собираются удалить базу данных.

• Пример употребления: Давайте дропнем старую базу, что она зря место занимает.

16. Забукать

Никак не связано с запоем. Слово происходит от to book — бронировать. Айтишники букают комнаты для переговоров или авиабилеты. Кстати, программисты из немецких компаний говорят «забухать» (с ударением на «у»). Это от немецкого глагола buchen (бухен), который тоже значит «бронировать».

• Пример употребления: Забукайте переговорку на час, надо обсудить новую тэдэшку.

17. Батон/батончик

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

Дело в том, что на ИТ‑сленге батонами называют кнопки. Разумеется, от английского button — кнопка.

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

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

Мы тут зашифровали ещё парочку фраз из сленга программистов на обложке????. Угадывайте и пишите в х. Знаете другие айтишные словечки? Добавляйте их тоже!

soft-skillzz-book

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

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

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

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

Смотрите, я — Д'Артаньян, и знаю как писать код, а вы все — беспомощные нажиматели кнопок.

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

тут была ссылка на удалённый твит, зря я не сделал скриншот

Тут же полный набор:

• вспомнили про университет (учился? значит должен соответствовать!)
• начали унижать, предварительно задрав планку.
• отметили собственное величие (я учился и я знаю, что так нельзя)
• Такой классический приём психологического давления. Возможно, он используется неосознанно. Что ещё хуже, да?

Как проводить токсичные ревью?

Способов вредить коллегам, проводя ревью кода очень много.

• Критиковать оформление кода (должен делать линтерформаттер)
• Критиковать незначительные детали (указал на не самый качественный нейминг в тестах, при этом ноль замечаний о сложном алгоритме)
• Требовать обосновать то или иное решение, не предлагая альтернативу (почему ты написал так? не думал сделать по-другому? со шрифтами поиграем?)
• Требовать обосновать выбор решения, предлагая аналогичную альтернативу (я знаю, что есть абсолютно такая же библиотека, которая делает то же самое, почему ты выбрал не её?)
• Завязывать долгие холивары с бросанием ссылками (твоя задача проверить код, на соответствие задачам, а не переубедить коллегу в превосходстве рекативного программирования над итеративным)
• Просить поправить старый код, который слегка модифицирован в рамках решения задачи (этот код уже прошёл ревью, к задаче отношения не имеет. Нужно создать таску, а не заставлять девелопера отвлекаться)
• Переходить на личности

Узнаёшь себя в любом из пунктов выше? Поздравляю, коллеги тебя ненавидят!

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

Хорошего кода не бывает, бывает код, который решает задачу а бывает код который задачу не решает.

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

Чуть в стороне стоит пункт про исправление существующего кода.

Слушай, раз уж ты тут, перепиши этот код нормально, а?

Это ужасный подход. Ты только что попросил человека разобраться со старым кодом, который уже прошёл ревью, пусть и давно. Этот код был оттестирован и проверен в бою. Это безумно раздувает скоуп задачи. Разработка современной системы и так похожа на бритьё яка. Зачем усугублять?

Как реагировать на токсичные ревью?

Возможно, ты сам становился объектом атак такого «доминатора». Как с этим бороться?

Для начала нужно понять, что пулл-реквест — это не площадка для дебатов о философии программирования. Лучше проглотить свою гордость, и выполнить требования. Что толку упираться и тратить время и нервы на мудака? Попутно придётся объяснять начальству почему задача так долго висит в In-Progress.

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

Но необходимо замерять потери времени. Заставили поправить перенос строк? Отлично! Считаем, сколько времени ушло на переключение веток, фикс, CI цикл, ожидание следующего раунда ревью, мердж и раскатку по тестовому окружению.

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

Можно даже решение предложить — давайте настроим линтер?

Нужны ли ревью кода?

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

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

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

Код-ревью, как способ развалить команду

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

https://www.youtube.com/watch?v=gclusz3HtDA\u0026pp=ygWBAdCg0YPQutC4INC_0YDQvtGH0Ywg0L7RgiDQutC-0LTQsDog0L_QvtGH0LXQvNGDINGC0LXRhdC90LjRh9C10YHQutC40Lkg0LzQtdC90LXQtNC20LXRgCDQvdC1INC00L7Qu9C20LXQvSDRgNC10LLRjNGO0LjRgtGMINC60L7QtA%3D%3D

Наболело о том как делают код ревью.

Почему так и что с этим делать?

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

Где-то ревью превращались в удобный инструмент для общение и документации решений. В одной из команд пулл-реквест был своеобразным RFC. Девелопер создавал его ещё до того, как был написан какой-то код.

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

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

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

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

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

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

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

Ищем союзников

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

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

Подобная ситуация:

[Мне] некомфортно выслушивать эти критиканские высказывания, меня ['токсичный' коллега] слушать не будет, и я не знаю, кому «пожаловаться», чтобы он, как минимум, перестал выражаться критично и как будто ему все должны и должны делать так, как он велит. Но и терпеть этот, извините, эгоцентричный пиздец я тоже не хочу.

Означает лишь то, что скоро кто-то уйдёт из команды, унеся с собой экспертизу и знания. А остальным придётся задуматься над возросшей нагрузкой. И… как это часто бывает, они примут правильное решение, и уйдут в другую компанию.

Если ты столкнулся с такой ситуацией, то логичнее всего было бы обозначить её своему менеджеру или тимлиду. Кто там у тебя есть? В идеале, конечно, сделать это на 1-1 митинге, если они проводятся в команде.

Зависит от уровня доверия и профессионализма твоего менеджера, но указать ему о проблеме — твоя обязанность. На модном сленге тимлидов это называется «послать сигнал». Вот пусть он этот сигнал ловит и работает над решением конфликта.

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

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

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

Наверное это одна из причин, по которым у нас снижается среднее количество выполненных сторипоинтов

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

Линтер

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

https://www.youtube.com/watch?v=gclusz3HtDA\u0026pp=YAHIAQE%3D

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

В итоге у вас постоянно будут возникать трения по поводу правил, которые не описаны в конфиге линтера. Бороться надо с причиной, увы.

Замена код-ревью

Плохие код-ревью не сильно помогают команде. Однако, вторая пара глаз — слишком ценный инструмент поиска ошибок. Может стоит дать шанс парному программированию? Вводить его можно не сразу, и не на 100%.

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

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

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

Разгрузка разработчиков

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

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

Как тут быть? Ищите свой путь. Лимитируйте количество work in progress тикетов. Следите за очередью на ревью. Замеряйте время ожидания и время на фиксы. Вводите правила: ревью затрагивает лишь тот код, который поменялся. Привыкайте к тому, что некоторые замечания по ревью могут быть выполнены в отдельной ветке и в отдельном PR.

Пытаемся понять коллегу

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

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

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

С другой стороны… может дело в тебе? Точнее в том, как ты воспринимаешь написанное. Одну и ту же фразу можно прочитать по-разному. Ранее я писал про то, что люди не умеют читать.

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

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

Выводы

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

Если ты ревьюер — думай о причинах и мотивах коллеги. Оценивай «стоимость» исправлений.

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

• Посты на эти и другие темы публикую в канале: https://t.me/your_soft_skillzz

Teamlead Roadmap: Code review

Code review – это проверка исходного кода на ошибки, проблемы архитектуры.

# Почему code review важен?

Помогает:

• Найти баги
• Выявить проблемы в архитектуре
• Сделать код единообразным

А также, что более важно в долгосрочной перспективе:

• Это работающий инструмент для обратной связи
• Участники code review будут учиться на своих и чужих ошибках
• Для оценки hard skills разработчика
• Code review поможет делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде
• Даёт приток новых идей для улучшений в процессах, подходах и автоматизации
• Децентрализация знаний

# Что будет, если не делать code review?

Будет плохо продукту:

• Баги на production. Тестирование не найдёт все баги
• Технический долг снежным комомлавиной накрывает проект. Время разработки новых фич увеличивается экспоненциально
• Подходы и архитектура будут несогласованны. Получится Франкенштейн.

Будет плохо lead-у:

• Плохо знает hard skills разработчиков по отдельности
• Не может оценить производительность

Будет плохо разработчикам:

• Без адекватной обратной связи будет ощущение работы «в стол». Демотивация, депрессия, поиск новой работы
• Не будет притока новых знаний о:
  • Проблемах, с которыми уже столкнулись другие. Учиться на чужих ошибках – это быстро и дёшево
  • Технологиях
  • Вариантах решения проблем
  • Самом проекте

# На кого можно делегировать code review?

В code review желательно участвовать всем разработчикам проекта.

# Примеры поведения

# Примеры плохого поведения

• Токсичное поведение
  • Переход на личности
  • Сарказм
  • Раздражение
• Плохо настроенные процессы
  • Неизвестно, кто должен делать code review
  • Неизвестны критерии прохождения. Процесс может продолжаться бесконечно
  • Список правок не разбит на группы по приоритетам
  • Разработчик долго ожидает code review
  • В merge request приходят огромные фичи
• Software используется недостаточно эффективно
  • Не настроены linter-ы и/или автоматические тесты
  • Разработчики пытаются запомнить список правок
• Разработчику непонятно, зачем нужно вносить правки
• Ревьювер не читал задачу в Jira

# Примеры хорошего поведения

• Адекватная обратная связь
  • Уточняющие вопросы вместо прямого указания на ошибки
  • Нейтральность или доброжелательность
• Процессы помогают ускорить и упростить code review
  • Разработчики понимают, что в их интересах делать code review
  • Все знают список требований для прохождения code review
  • Список правок удобным образом приоритизирован. Например, с помощью emoji ????, ????
  • Обратная связь – быстрая, в идеале – в течение дня
  • Merge requests атомарные
• Для ускорения используются библиотеки и программы
  • Используются linter-ы и автоматические тесты
  • Разработчики не пытаются запоминать список правок в уме
• Участники code review согласны и понимают причины почему нужно внести правки
• Ревьювер знает бизнес-логику решаемой задачи

# Способы прокачки

# Практика и способы прокачки

Code review выглядит просто. Проверяете merge request на ошибки и пишете о них, но есть нюанс. Важно понять и принять, что это долгосрочный процесс. Настоящие причины ошибок – пробелы в знаниях, сниженная мотивация. Lead должен включать soft skills, чтобы не стрелять в ногу себе и команде.

Полезно проводить «review» до написания кода, особенно для junior devs. Lead должен убедиться, что разработчик напишет задачу верным способом. Выяснять нужно с помощью уточняющих вопросов.

# Умение критиковать

Умение критиковать – это ключевой навык.

# Как смягчить критику вербально:

• Задавать уточняющие вопросы вместо прямого указания на ошибки
• Сперва похвалить, затем – критиковать
• Хвалите, если всё хорошо
• Feedback от разработчика о том как прошло review. Да, взять и спросить
• Не говорите «ТЫ сделал плохо»

Практиковаться можно «в уме» на merge request. Когда поняли что научились – давать настоящий feedback.

# Как смягчить критику невербально:

• Следите за эмоциональными состояниями: своим и разработчика

Практикуйтесь «в уме» на косячных merge request. Вы не должны злиться и раздражаться на «эти тупые ошибки ????». Для настоящих review начинайте с хороших merge requests и постепенно переходите к косячным.

Чтобы не злиться самому помогут:

• Понимание себя и истинных причин раздражения
• Понимание что цель не найти баги, а обучить разработчика не делать их снова; или помочь разработчику сменить позицию или компанию на более подходящую
• Психолог
• Успокоительное
• Просто будьте проще, от ваших багов навряд ли кто-то пострадает (с) Капитан Очевидность

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

• Практические книги по психологии
• Психологические тренинги

# Дополнительно

Без невербального общения (переписка в х github) разработчик может додумать ваши эмоции. Старайтесь быть ближе, как минимум – созвонитесь.

# Процесс review фичи

1. Выяснить, какую бизнес-логику писал разработчик
2. Рассмотреть ключевые элементы бизнес логики, архитектуру решения
3. Углубиться в детали

# Нужно выяснить какую бизнес-логику писал разработчик

Об этом могут рассказать разработчик, менеджер или таска в jira. Feedback выдаётся разработчику и/или менеджеру при проблемах с бизнес-логикой.

Чтобы прокачать этот скилл можно пройтись по задачам с описанием.

Чтобы получить косячные задачи, можно:

• Зайти в «achieved»
• Попросить придумать косячные задачи
• Или попросить придумать задачи косячного менеджера

Результат – понимание задачи или аргументы что не так с задачей. Возможно – список на исправление.

# Рассмотреть ключевые элементы бизнес логики, архитектуру решения

Об архитектуре решения и ключевых моментах расскажет разработчик. Feedback нужно выдать ему же.

Практиковаться можно на merge request вместе с разработчиком.

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

Результат – понимание и принятие или аргументы:

• Почему это нужно исправить
• Что будет, если не исправить
• Соглашение с разработчиком как исправить

# Углубиться в детали

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

Если это необходимо – пройдитесь по деталям реализации.

Результат – статус задачи «review закончено» или аргументированный список правок.

# Что ревьюить

В зависимости от целей ревью и времени на него:

• Наиболее критичные задачи
• Практики безопасности
• Архитектуру
• Задачи junior devs
• Все задачи
• Выбранное вами

Вы должны чётко осознавать, что именно и зачем вы ревьюите.

# Настройка и использование software

# Автоматическая проверка кода

Для ускорения процесса нужно настроить проверку кода на:

• Синтаксические ошибки
• Стилистические неточности
• Предполагаемые ошибки во время исполнения (использование необъявленной переменной и тд)
• Возможные уязвимости в коде и используемых библиотеках

Это поможет сократить время на поиск проблем вручную.