Рефакторинг и качество как культура. Внедрение и паттерныОрганизация программного кода
Организатор Go митапов и Reliability митапов в Санкт-Петербурге.
7 лет работал с нагруженными системами (>100k rps, >500Tb), занимался инфраструктурными задачами. Нанял и построил команду разработки МегаФон.ТВ. Руковожу разработкой.
Итак, у нас среднестатистический быстро выросший веб-проект. Со всеми атрибутами:
• Нескончаемый поток срочных задач.
• «Давайте сделаем по-быстрому» превращается в «оно же работает, побежали дальше».
• Неполные требования, очень частые изменения.
• Перманентно устаревающая документация.
• Запутанная логика приложения, в которой никто полностью не разбирается.
• Обязательная полная обратная совместимость API для самых разных клиентов.
С технической стороны:
• Асинхронная интеграция с массой внешних систем.
• Сотни сценариев, кнопок, поп-апов, ad-hoc-логики.
• Архитектурно продуманный код соседствует с «лапшой».
• Дорогие и недостаточно полезные тесты.
С этим как-то надо жить. Мы пробовали:
• Точечный рефакторинг, и выделенные задачи на него.
• Удобно организовать код при часто меняющихся требованиях.
• Множество подходов к тестам.
В итоге сформировались паттерны, как переделывать старый код так, чтобы не было мучительно больно. Как не тратить много времени на тесты и быть уверенными в качестве сервиса. Как не тратить много времени на качественный код. Как сделать это удобным для изменяющейся геораспределённой команды. Всё это образует инженерную культуру, в которой каждый компонент поддерживает соседний. Это рассказ о такой культуре и о паттернах, которые помогут вам сделать так же.