Эргономичный подход

Эргономичный подход

Об Эргономичном подходе

Эргономичный подход — способ быстро создавать эргономичные кодовые базы — кодовые базы, которые легко менять для поддержки новых требований.

Критерии, которым должна соответствовать хорошая кодовая база, давно известны: её поведение должно быть полностью покрыто быстрыми автоматическими тестами, а реализация должна обладать высокой функциональной связанностью (cohesion) и низкой сцепленностью (coupling).

Однако множество кодовых баз всё ещё не соответствуют этим критериям. Как следствие, критичные ошибки и горящие сроки являются «естественным» состоянием дел для многих команд.

Мне такое состояние дел не подходит, и для того, чтобы вместе со своими командами систематически и быстро создавать хорошие кодовые базы я разработал Эргономичный подход.

Эргономичный подход — это набор принципов, моделей, методик и шаблонов, которые помогают быстро проектировать и разрабатывать кодовые базы, полностью покрытые автоматическими тестами и с реализацией, обладающей высокой функциональной связанностью (cohesion) и низкой сцепленностью (coupling).

Суть Эргономичного подхода

По большому счёту Эргономичный подход можно свести к нескольким принципам в трёх областях:

  1. Тестирование:

    1. тесты должны работать через публичное АПИ;

    2. 100% поведения системы должно быть покрыто тестами;

    3. моки должны использоваться только для верификации взаимодействия с неуправляемыми зависимостями, либо для симуляции трудновоспроизводимого поведения управляемых зависимостей (в первую очередь системные ошибки);

    4. тесты должны быть быстрыми — < 10 секунд на полный цикл запуска одного теста, <300 секунд на запуск всех тестов сервиса;

  2. Моделирование предметной области:

    1. Предметная область должна быть разбита на небольшие слабосвязанные агрегаты;

    2. Агрегаты и связи между ними должны образовывать направленный ацикличный граф;

    3. Агрегаты должны быть представлены в коде неизменяемыми объектами, хранящиеся в изменяемых репозиториях.

  3. Проектирование поведения:

    1. Бизнес-логика и ввод-вывод должны быть разделены;

    2. Бизнес-логика должна быть написана в виде чистых функций без побочных эффектов;

На практике соблюдать эти принципы не так просто, как может показаться на первый взгляд.

Прямолинейный подход к написанию тестов без моков может привести к их очень медленной работе, а тестирование через публичное АПИ — кровавому и хрупкому месиву в коде сетапа фикстуры.

А разделение бизнес-логики и ввода-вывода в сложной операции системы или декомпозиция нетривиальной модели на агрегаты может оказаться сложной задачей даже для опытного разработчика.

Поэтому весь свой опыт разработки в соответствии с этими принципами я свожу в модели, методики и шаблоны, которые позволяют всей команде не наступать на одни и те же грабли и не изобретать одни и те же велосипеды по нескольку раз.

Промышленное применение Эргономичного подхода

С 2020 года я вместе с несколькими командами сделал в соответствии с Эргономичным подходом девять коммерческих проектов — от реинжиниринга ключевых подсистем и разработки небольших сервисов до реинжиниринга и дальнейшей разработки системы размером в два человек-года. Суммарно по Эргономичному подходу написано уже порядка ста тысяч строк коммерческого Kotlin- и Java-кода.

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

Про опыт и результаты применения Эргономичного подхода в некоторых из этих проектов я рассказываю в своих выступлениях и постах.

В докладе Структурный дизайн. Древний секрет простого и быстрого кода на Joker '24, его расшифровке, а также серии постов (1, 2, 3), я рассказываю о том, как, выполнив реинжиниринг проекта силами юниоров, я повысил скорость и качество работы команды в три раза.

В том же докладе и его расшифровке я также рассказываю о реинжиниринге модуля маршрутизации чат-центра Threads (сейчас — edna.chatcenter). В результате реинжиниринга производительность модуля выросла в 300 раз, а код реализации превратился из спагетти-кода в аккуратное дерево:

threads reengineering

В докладе Рациональный подход к декомпозиции систем на модули или микросервисы на JPoint '23 и посте с его расшифровкой я рассказываю о проекте Кэмп. Проекте, сделанном в срок двумя юниорами, и с отзывом руководителя проекта на их работу: «К бэку у меня вообще претензий нет. Он просто работает».

В посте Диаграмма эффектов: пример построения я рассказываю о проектировании небольшого сервиса для X5 Group, обеспечивающего актуализацию информации о десятках тысячах магазинов сети "Пятёрочка" по всей стране в Яндекс.Картах и 2Гис.

Наконец, в посте Тесты, которым можно доверять, я рассказываю об устройстве тестирования проекта по проверке бизнес-гипотезы. Этот проект позволил заказчику быстро и за фиксированную стоимость инвалидировать неудачную бизнес-идею и минимизировать потери.

Также у меня есть два проекта с открытыми исходным кодом, сделанных по Эргономичному подходу:

  • Trainer Adviser — некоммерческий, но настоящий и относительно большой (4К строк кода, 15 таблиц) с одним реальным пользователем;

  • Project Mariotte — минимальный демонстрационный проект.