Об Эргономичном подходе
Эргономичный подход — способ быстро создавать эргономичные кодовые базы — кодовые базы, которые легко менять для поддержки новых требований.
Критерии, которым должна соответствовать хорошая кодовая база, давно известны: её поведение должно быть полностью покрыто быстрыми автоматическими тестами, а реализация должна обладать высокой функциональной связанностью (cohesion) и низкой сцепленностью (coupling).
Однако множество кодовых баз всё ещё не соответствуют этим критериям. Как следствие, критичные ошибки и горящие сроки являются «естественным» состоянием дел для многих команд.
Мне такое состояние дел не подходит, и для того, чтобы вместе со своими командами систематически и быстро создавать хорошие кодовые базы я разработал Эргономичный подход.
Эргономичный подход — это набор принципов, моделей, методик и шаблонов, которые помогают быстро проектировать и разрабатывать кодовые базы, полностью покрытые автоматическими тестами и с реализацией, обладающей высокой функциональной связанностью (cohesion) и низкой сцепленностью (coupling).
Суть Эргономичного подхода
По большому счёту Эргономичный подход можно свести к нескольким принципам в трёх областях:
Тестирование:
тесты должны работать через публичное АПИ;
100% поведения системы должно быть покрыто тестами;
моки должны использоваться только для верификации взаимодействия с неуправляемыми зависимостями, либо для симуляции трудновоспроизводимого поведения управляемых зависимостей (в первую очередь системные ошибки);
тесты должны быть быстрыми — < 10 секунд на полный цикл запуска одного теста, <300 секунд на запуск всех тестов сервиса;
Моделирование предметной области:
Предметная область должна быть разбита на небольшие слабосвязанные агрегаты;
Агрегаты и связи между ними должны образовывать направленный ацикличный граф;
Агрегаты должны быть представлены в коде неизменяемыми объектами, хранящиеся в изменяемых репозиториях.
Проектирование поведения:
Бизнес-логика и ввод-вывод должны быть разделены;
Бизнес-логика должна быть написана в виде чистых функций без побочных эффектов;
На практике соблюдать эти принципы не так просто, как может показаться на первый взгляд.
Прямолинейный подход к написанию тестов без моков может привести к их очень медленной работе, а тестирование через публичное АПИ — кровавому и хрупкому месиву в коде сетапа фикстуры.
А разделение бизнес-логики и ввода-вывода в сложной операции системы или декомпозиция нетривиальной модели на агрегаты может оказаться сложной задачей даже для опытного разработчика.
Поэтому весь свой опыт разработки в соответствии с этими принципами я свожу в модели, методики и шаблоны, которые позволяют всей команде не наступать на одни и те же грабли и не изобретать одни и те же велосипеды по нескольку раз.
Промышленное применение Эргономичного подхода
С 2020 года я вместе с несколькими командами сделал в соответствии с Эргономичным подходом девять коммерческих проектов — от реинжиниринга ключевых подсистем и разработки небольших сервисов до реинжиниринга и дальнейшей разработки системы размером в два человек-года. Суммарно по Эргономичному подходу написано уже порядка ста тысяч строк коммерческого Kotlin- и Java-кода.
Все проекты были успешно переданы в промышленную эксплуатацию или заказчикам, а проекты по реинжинирингу дали объективное и существенное улучшение характеристик кодовой базы.
Про опыт и результаты применения Эргономичного подхода в некоторых из этих проектов я рассказываю в своих выступлениях и постах.
В докладе Структурный дизайн. Древний секрет простого и быстрого кода на Joker '24, его расшифровке, а также серии постов (1, 2, 3), я рассказываю о том, как, выполнив реинжиниринг проекта силами юниоров, я повысил скорость и качество работы команды в три раза.
В том же докладе и его расшифровке я также рассказываю о реинжиниринге модуля маршрутизации чат-центра Threads (сейчас — edna.chatcenter). В результате реинжиниринга производительность модуля выросла в 300 раз, а код реализации превратился из спагетти-кода в аккуратное дерево:
В докладе Рациональный подход к декомпозиции систем на модули или микросервисы на JPoint '23 и посте с его расшифровкой я рассказываю о проекте Кэмп. Проекте, сделанном в срок двумя юниорами, и с отзывом руководителя проекта на их работу: «К бэку у меня вообще претензий нет. Он просто работает».
В посте Диаграмма эффектов: пример построения я рассказываю о проектировании небольшого сервиса для X5 Group, обеспечивающего актуализацию информации о десятках тысячах магазинов сети "Пятёрочка" по всей стране в Яндекс.Картах и 2Гис.
Наконец, в посте Тесты, которым можно доверять, я рассказываю об устройстве тестирования проекта по проверке бизнес-гипотезы. Этот проект позволил заказчику быстро и за фиксированную стоимость инвалидировать неудачную бизнес-идею и минимизировать потери.
Также у меня есть два проекта с открытыми исходным кодом, сделанных по Эргономичному подходу:
Trainer Adviser — некоммерческий, но настоящий и относительно большой (4К строк кода, 15 таблиц) с одним реальным пользователем;
Project Mariotte — минимальный демонстрационный проект.