![](https://habrastorage.org/files/2f5/b43/cb6/2f5b43cb67f3473daf99617072742377.png)
Так же как для многих других вещей в нашей жизни, знание зачем мы что-то делаем позволяет делать это действительно хорошо и не поддаваться желанию делать это тогда, когда оно не нужно. Начнем с того, что перечислим чем code review не является:
- Это не полчаса в день приятного времяпровождения когда вы кричите на своих коллег и тыкаете пальцем в их ошибки. Если вам нравится делать code review чтобы находить чужие ошибки или отсутствие хороших практик в коде, то у меня для вас плохие новости — похоже, это не лучшее для вас занятие.
- Это не способ обучения ваших коллег. Если вы считаете, что команда должна придерживаться определенных практик при разработке, то необходимо отдельно выделить время и согласовать эти практики с разработчиками лично.
- Это не место для дискуссий. Комментарии в code review должны быть максимально короткими и по делу. Никаких попыток отстаивать свою точку зрения или защищать свою позицию.
При таком раскладе — зачем тогда нужно code review? Основываясь на моей практике, я могу выделить четыре причины:
- Это способ разделить ответственность. Когда мы делаем code review то мы, образно выражаясь, «помогает тянуть лямку». Мы отказываемся от нашего обычного «меня это не @#$%!@#, не мой код» в пользу «ну что ж, будем валить этого дракона вместе».
- Это замечательный способ учиться друг у друга. На первый взгляд, этот пункт противоречит второму пункту предыдущего списка, но поверьте мне на слово. За свою карьеру я узнал несравнимо больше нового от дружеских, неагрессивных обсуждений с коллегами, нежели ото всех этих агрессивных придирок к моему коду от людей, которые думают что знают все лучше всех (или по крайней мере лучше чем я). Более того — мне так и не удалось научиться извлекать пользу из таких комментариев, только острое чувство ненависти (к комментариям, не к людям). Вне зависимости от того, насколько вы лучше, другие люди заслуживают уважительного к себе отношения. Хотя бы потому, что вы сами когда-то были таким.
- Это способ находить баги и явные ошибки. По-хорошему, это — основная причина, чтобы делать code review. Просматривая чужой код, фокусируйтесь на поиске ошибок и багов, которые автор кода мог проглядеть — и предлагайте простые способы их исправить. Иногда вы даже будете встречать одну и ту же ошибку, повторенную несколько раз. Боритесь с искушением писать комментарии вроде «парень, зачем ты опять делаешь ЭТО?!?». Будьте профессиональны. И если вы считаете, что какие-то моменты в коде ваших коллег нужно обсудить — сделайте это лично, вежливо и без «наездов».
- Это способ улучшить качество кода. Как я уже писал, лучшие практики нужно обсуждать с коллегами лично. Но если вы нашли в коде какое-то место, которое, как вы считаете, может быть легко улучшено — будет хорошей идеей вежливо предложить это в рамках code review.
Подводя итог: всегда нужно помнить, что ваши коллеги такие же профессионалы, как вы, вне зависимости от объема личного опыта. Но, что гораздо важнее — они живые люди. А люди лучше и продуктивнее работают и более счастливы, когда их понимают и уважают. И code review может в этом помочь — если правильно его использовать.