2020-04-02
Q&A Как начать ревьюить код тимлида?
Работаю в компании, где код ревью делают только лиды всем, кто младше по опыту/званию. Я в работе очень педантичен, но допускаю ошибки, бывает. Очень часто замечаю, как тимлид делает тупые ошибки, bad practice на языке программирования, который мы используем, не делает всё оптимально, когда оптимальное решение даже проще, чем его. Иногда чувство, что какой-то джун пишет.
Как аккуратненько поднять тему для начальства и тимлида, чтобы его код(да и вообще код лидов) ревьювили? Думаю, что от этого все выиграют
Интересный вопрос. Начнём с контекста.
С возрастом/опытом приходит понимание, зачем эти практики нужны, кого и от чего они защищают, почему возникли, и как они похожи на ту штуку, которую все делали 15 лет назад. Так же приходит осознание того, что делать оптимально -- не главное. Зачем тебе очень сложный и быстрый алгоритм, если твой стартап завтра развалится, ведь у вас денег хватает лишь до июня. А вот если быстро наговнякать и выкатить фичу в продакшн, то может и заработаете что-то, да до зимы дотянете.
Но иногда это просто лень, а ты действительно молодец. Так что смысл в твоём предложении есть.
Как продавать такое начальству и команде? У вас это похоже на какой-то инструмент для доминирования "я старше, покажи-ка, что ты там налячил".
А должно это всё рассматриваться не только как инструмент контроля, но и как способ доносить знания о проекте, коде. Способ делиться опытом.
"Старшие" они же не только дольше тебя на стуле просидели, они ещё и могут обладать контекстом притяния решений (почему делаем так? какие глобальные цели?), они могут обладать опытом (мы так делали в 98м, и потом рубль обвалился), могут знать домен (да, есть хитрый закон, регулирующий область и в нём сказано, что в данном случае отчет должен выглядеть именно так), и конечно же они могут знать неочевидные штуки про проект (если эта штука будет быстро работать, то у той штуки кеши не прогреются и всё развалится).
Если удастся донести до команды эти факторы, то всем должно стать ясно, что во время ревью не обязательно ошибки искать, а можно (нужно!) ещё и учиться. Вопросы задавать, хитрые приёмчики узнавть, вот это всё. То есть хорошо бы показать, что "старшим" не страшно показывать код (вдруг они боятся, что их джуны засмеют?), а напротив, это отличный способ продемонстрировать "как надо". В таких командах новички быстрее узнают об инструментах и локальных велосипедах, которые используются в проекте.
Если это выглядит, как слишком радикальная мера, то можно попробовать договориться о двух ревью: пусть любой Pull-Request перед мерджем требует два аппрува. Один от более старшего, другой от любого инженера. Так и у самых младших будет вырабатываться навык проведения ревью и чтения чужого кода (я правильно понимаю, что у вас они вообще не могут ревьюить ничего?). И опять же будет происходить горизонтальный обмен знаниями, как и в предыдушем варианте.
А вот говорить о том, что ты хочешь проводить ревью из-за того, что тимлид говнокодит... думаю, что не стоит использовать этот аргумент.