Я завел этот, сорок второй в моей жизни, дневник, втуне надеясь, что здесь никогда не появится никаких текстов, хоть как-то связанных с моей работой. Но жизнь, как всегда, оказалась хитрее. Вчера я в очередной раз делал код ревью и мне пришла в голову мысль, что сама концепция — ежедневно дает метастазы в мое нормальное, внерабочее, существование. Поэтому я, пожалуй, напишу несколько слов про то, как надо — и как не надо — делать код ревью: в программировании, и в обычной жизни.
Начнем с определения (я просто скопировал его из первой ссылки выдачи поиска)
В индустрии разработки программ очень распространена практика код-ревью. Программист отправляет написанный код своим коллегам — они просматривают его и высказывают свои замечания.
Такой подход позволяет найти потенциальные проблемы, которые не заметил автор. […]
Ну хорошо, а причем тут жизнь? — прищурится на меня в свой монокль читатель с гуманитарным складом ума. А при том. Каждый раз, когда у нас спрашивают совет, а особенно, когда его не спрашивают, но мы, как хорошие друзья с эректильной эмпатией, все равно его даем — мы как бы проводим код ревью. Вываливаем груду своих идей о том, как обязан выглядеть идеальный код (ой, простите, поступок) — груду идей, основанных исключительно на нашем опыте, кругозоре и способности вникнуть в проблему.
Поэтому я просто расскажу, как провожу код ревью я, в терминах настоящего айти код-ревью, чтобы не оговариваться по нескольку раз на фразу и не превращать текст неуместными скобками в код на LISPе. А вы уж там экстраполируйте. Для удобства и краткости, я буду именовать код ревью англоязычным сокращением CR.
1. Цель CR — добиться приемлемого компромисса, а не наивысшего качества, соответствия моим стандартам, или идеальной производительности. Поэтому откровенные ошибки надо подчеркнуть красным и внятно, но без рассюсюкивания и реверансов, объяснить, почему так делать нельзя. Места, которые могут быть переписаны производительнее, изящнее, короче — имеет смысл обозначить и снабдить комментарием «а вот еще как можно: что думаешь?», но не настаивать на изменениях. Претензии к коду наподобие «некрасивый», «невнятный», «неаккуратный», «как говно» — нужно вантузом затолкать себе обратно в горло и никогда больше оттуда не доставать.
2. CR считается пройденным в тот момент, когда исправлены все ошибки. Не недочеты, помарки, кривые хвостики у букв «д» — только ошибки. С этого момента я продолжаю оставлять комментарии типа «а может, лучше так?» но статус CR переходит из «Rejected» в «Approved». Как только автору надоест со мной сражаться, он волен прекратить эту бодягу и закрыть задачу.
3. С джунами ситуация ровно точно такая же. Я никогда не настаиваю на внесении косметических изменений в код, даже если названия локальных переменных нечитаемы, или вложенность условных операторов превышает мыслимые пределы (мой мыслимый предел вложенности оных — 0, если кому-то интересно). Но, как человек, имеющий отношение к принятию решений о составе команды, я могу повлиять на трудоустроенность тех джунов, которые моими рекомендациями пренебрегают, и помечают задачи выполненными — сразу после исправления критических моментов.
4. Давая совет по улучшению, я всегда пишу кусок кода, от которого автор сможет оттолкнуться, чтобы переделать. Иногда это процентов сорок от предлагаемого изменения, иногда — когда код нетривиален — все сто. Я никогда не предлагаю переделать «как-нибудь», «покрасивее», «не так коряво». CR — это обучение моих коллег не в последнюю очередь.
5. Если я замечаю (по тону, реакции, характеру правок, скорости ответа), что автор стал тяготиться бесконечным пинг-понгом и уже ненавидит этот CR, я перестаю давать советы по улучшению, а те, что не могу не дать из-за страдающего чувства прекрасного — даю полными кусками, оттестированными, и готовыми к копи-пасте.
6. Свой код я всегда отдаю на CR двоим: джуну и синьёру. Первому это и приятно и полезно, а второй — может и ошибку найти (первый тоже может, на самом деле, причем чуть ли не чаще, из-за незамыленности взгляда).
7. Никогда, ни при каких обстоятельствах, я не вношу изменения в чужой код сам, вместо того, чтобы объяснить, как надо, и предоставить возможность внесения изменений автору. Советы — особенно специально попрошенные — это хорошо и полезно, но попробуйте посолить суп, который я сейчас варю, — и немедленно получите в табло.
8. После того, как CR готов к выпуску в свет, я всегда оставляю последний комментарий с набором смайликов, означающих «урра, зарработало!». Я научился этому у Жозе Валима, но смайлики выбрал другие.
9. Я не злоупотребляю смайликами, расшаркиваниями, сослагательными наклонениями и вежливыми велеречивыми адресами. Мы тут все на работе, нам за нее платят деньги, изволь потратить свое время на исправление ошибок, а не на очередной «would you be so could you please». Да, я работаю в «западной» компании, мой шеф — американец, в коллективе есть люди с четырех континентов и более, чем из десяти стран. И я не начинаю ответы на письма с многословных приветствий, а в мессенджере и вовсе не использую вспомогательные части речи. Да, так можно было.
И, наконец, 10. Всеми правдами и неправдами, я стараюсь сделать так, чтобы у автора кода осталось благоприятное впечатление от процесса, чтобы он узнал для себя что-то новое, чему-нибудь научился. Я шучу, рассказываю исторические анекдоты, провожу параллели с кодом на других языках. Стараюсь сделать этот процесс увлекательным, тогда и скучное муторное исправление ошибок — будет в радость.
Ну круто, слышу я возгласы с дальних парт, а жизнь-то тут причем? А вот. Каждый раз, когда вы вознамеритесь давать советы друзьям, приятелям, или просто случайным попутчикам в метро — вспомните о том, что, по сути, вы делаете лайф ревью. И результат — возможно будет претворен в жизнь. А процесс — запомнен вашим собеседником и почти наверняка повлияет на ваши отношения в дальшейшем.