Почему нас бесит код-ревью и как с этим бороться?

Уже больше 10 лет я занимаюсь системной разработкой. Работал в GridGain над Apache Ignite, теперь продолжаю в СберТехе над ним же и еще несколькими проектами.

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

В докладе расскажу про мировоззрение и правила, помогающие моим текущим и прошлым проектам стабильно двигаться вперед, а именно: * как мы пришли околонулевому уровню инцидентов в проде, * какие практики пришлось для этого внедрить, какие отвергнуть, а какие выдумать с нуля, * про альтернативные подходы к ревью, которые помогают в сложных ситуациях, * про то, как связаны опенсорс и меритократия с ревью идеологически, * как понять, принять, простить и возлюбить ревьюера своего, * как перестать испытывать гнев к плохому коду, * на что нужно смотреть на ревью обязательно, а что и, главное, когда можно пропускать, * как умудряться из раза в раз смотреть на код незашоренным взглядом, * как совмещать ревью с разработкой и лидерством командой, * как вырастить или перевоспитать специалистов в команде через ревью, * про принципы саморевью и методы повышения шансов прохождения ревью с первого захода, * про принципы ревью незнакомых предметных областей или даже языков с гарантиями результата, * о том стоит ли верить подсказкам IDE и системам анализа кода, * важен ли кодскайл проекта, * какие паттерны оформления кода сделают его более читаемым и для ревьюера, и для всех в будущем, * и почему принципы ревью из системной разработки помогут вам в прикладной.