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

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