Как проходят Code Review в Amazon и Facebook?

Code Review это неотъемлемая часть процесса разработки во многих компаниях, в том числе и в FAANG. Поделюсь личным опытом, на что обращают внимание при Code Review в двух из них и чем они отличаются.

Смотрите также мой пост про version control в FAANG: https://t.me/faangmaster/81

Amazon:
1) Наличие ошибок в коде. В большинстве FAANG компаний нет отдельных QA. Поэтому тестирование ложится на самих разработчиков. Они должны писать правильно работающий код и писать тесты. Code Review помогает посмотреть на этот код со стороны другими разработчиками и найти в нем ошибки.
2) Наличие тестов и покрытие тестами. Даже если у вас не найдут ошибки в коде, вам могут указать не нехватку тестов, не покрытии каких-то edge-case и т.д. И в процессе написания таких тестов вы сами сможете выявить ошибку если она там есть.
3) Форматирование и читаемость кода. У разных команд есть свой стиль форматирования кода и он может отличатся от других компаний и даже команд внутри Amazon. Обычно, команды договариваются заранее, что считать правильно отформатированным и читаемым кодом, а что нет. Наша команда это сделала на основе некоторых принципов описанных в Clean Code (не всех, но тех, которые мы посчитали логичными для себя). Автоформатеры кода также используются, но по моему опыту они не покрывают все случаи. Когда вы только начнете работать в вашей первой команде или смените команду, у вас будет гигантское число комментариев в Code Review из-за читаемости и форматирование кода. Помните, что код пишется и меняется очень редко, а читается в десятки раз чаще, поэтому его нужно писать читаемым.
4) Расширяемость и поддерживаемость кода. Можно ли легко расширить ваш код в будущем, если появятся новые требования без переписывания всего или значительной части вашего кода? Это условно может быть соблюдение SOLID, но не обязательно, т.к. ваш код не обязательно чисто ООП. Но тут главное не переусердствовать и не делать over-engineering. Очень часто изменения в коде делают итеративно, и не обязательно в первой его версии делать его расширяемым, особенно, если не видно необходимости в таком расширении.
5) Размер Code Change. В рамках одного Code Review рекомендуется делать маленькие изменения, которые легко детально посмотреть и понять. Если изменение огромное, то больше шансов, что его никто не будет детально смотреть и просто заапрувят неглядя. Поэтому качество таких Code Review будет страдать. Лучше ваше изменение разбить на много маленьких изменений в рамках одного стэка изменений.
6) Уточняющие вопросы. Code Review это также хороший способ понять, над чем и как работает тот или иной человек или команда. Если вы хотите в этом разобраться или быстрее заонбордится в команду, то делайте Code Review и задавайте вопросы, если что-то или все непонятно.
7) Каждое изменение не должно ничего ломать. Как я уже описывал тут (https://t.me/faangmaster/81) в FAANG используется trunk-based разработка. И поэтому каждое изменение идет сразу в trunk/master и сразу деплоится в prod. А т.к. обычно вы разбиваете работу над задачей на много маленьких Code Change, то каждое из них не должно ломать trunk и prod. Вы можете, например, в одном Code Change написать интерфейсы, во втором их реализацию, в третьем сделать вызовы вашей реализации.