Хотел написать небольшой пост – а в итоге получилась целая статья.

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

Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна

Заходите почитать, если понравилась ставьте лайкосики.

#devfm

Зачем вы проводите код-ревью?

Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.

И каждый PR дисциплинированно пропускают через код-ревью: назначаются ревьюеры, они что-то пишут, код как-то правится...

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

Ответы бывают разные.

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

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

Код-ревью нам нужно для шаринга знаний – такой ответ дают самые прогрессивные. Честно говоря, какое-то время это был мой любимый аргумент, и я очень им гордился. Но если задуматься: для шаринга знаний предполагается, что разработчик, у которого куча своих задач и контекстов, переключится на чужую задачу, впитает всё, что там написано, разберётся и получит ценные знания. Вопрос – сколько же времени нужно для этого? Как говорят классики: «сомнительно, но окэээээй». Если услышите такой аргумент, спросите у разработчиков, сколько времени они тратят на ревью, и подумайте, можно ли за это время действительно перенять знания. Ответы, которые получал я, говорят: скорее нет, нельзя.
Моё мнение – код-ревью создаёт иллюзию шаринга знаний, но по факту распространяет только очень поверхностный контекст. Если вы реально хотите шарить знания, есть куда более прямые и честные инструменты – дизайн-доки, обсуждения решений до реализации, грумминги задач.

И это я ещё не затронул другие проблемы и крайности: когда в PR появляется миллион комментариев, когда какой-то очень умный разработчик упирается рогом и говорит, что такой PR "только через мой труп", когда PR-ы висят днями, копят строчки, а потом полдня тратится на разруливание конфликтов. В общем – красота.
Так зачем это всё?

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

Первое – составить гайд, хотя бы выровняться по одной линейке: как в команде проводится ревью, что мы ревьюим, на что обращаем внимание, а что считаем минором, тайминги проведения, выбор ревьюера, правила оформления PR-ов.

Второе – автоматизировать всё, что можно автоматизировать: линтеры, форматеры и вот это всё. Чтобы на ревью об этом даже не думали.

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

Ревью действительно должно быть:
– когда вы залезли в чужой сервис или область знаний и сами просите эксперта посмотреть код
– когда вы мейнтейнер опенсорсного проекта
– когда вы менторите новичков или джунов и осознанно инвестируете время

Если вы прочитали и подумали: "Что это за бред?" – ну что же. Либо вы никогда критически не смотрели на этот процесс, либо вам действительно повезло с командой. Во втором случае искренне за вас рад – держитесь за неё. Так бывает далеко не у всех.

#devfm

Книга "Цель"

Недавно прочитал довольно известную книгу Цель Элияху Голдратта.

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

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

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

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

Читая книгу, я поймал себя на мысли, что идеи из неё перекликаются с подходами канбана.

И напомню: у нас скоро заканчивается конкурс на самую интересную цитату из практики.
Приходите, голосуйте, приносите свои. Как говорится, от нас пуля вылетела 🙂