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

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

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