День 2364. #ЗаметкиНаПолях
5 Ошибок, из-за Которых Код Становится Неподдерживаемым. Начало
Вот 5 самых распространённых ошибок в проектировании ПО, из-за которых работа с кодом становится кошмаром. Все эти ошибки со временем, по мере роста объёма кода, делают его неподдерживаемым.

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

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

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

Если вы когда-либо сталкивались с вопросом: «Как мы оказались в таком состоянии? Почему данные вообще выглядят именно так? Как это произошло?», и не имели об этом ни малейшего понятия, то причина в отсутствии владения данными. Возможно, кто-то вручную подключился к БД, или другой сервис или приложение интегрировалось и изменило состояние.

Решение — явно определить владельцев данных. Определите API, с которым взаимодействуют другие части системы — это контракт. Когда вы хотите изменить состояние части системы, вы вызываете её API, и она управляет изменением своего состояния. Т.е. за изменение состояния отвечает одно конкретное место.

Ещё лучше определить команды и запросы:
- Команды изменяют состояние.
- Запросы только получают данные, относящиеся к определённой части системы.
Каждое взаимодействие проходит через единое место, которое владеет командами и запросами.

2. Кодовая база неявная
Обычно кодовая база основана на CRUD-операциях над сущностями. Если взглянуть на вашу кодовую базу, можно ли точно сказать, что она делает и каковы её возможности? Обычно нет, поскольку рабочие процессы, управляемые конечными пользователями, не описаны явно.

Это легко представить на примере событий домена. Предположим, у вас есть груз, и одним из необходимых действий является получение груза водителем. Когда водитель это делает, вы часто назначаете коносамент (bill of lading - BOL). Если вы используете только CRUD, вы можете обновить отгрузку с помощью BOL. Тогда возникает событие «изменение отгрузки».

Но почему отгрузка изменилась? Вы не знаете. Кто-то ввёл BOL впервые? Или добавил его повторно? Или же это был самовывоз?

В этом заключается существенная разница между явным и неявным описанием. Вместо стандартного события «изменение отгрузки» нужно явное событие, например, «отгрузка подготовлена к самовывозу», которое включает идентификатор отгрузки, местоположение, дату, время и коносамент. Это гораздо понятнее и точно показывает, что произошло.

Когда ваш API — это просто «изменение отгрузки», вы не знаете, что на самом деле пытается сделать пользователь. Вам остаётся только пытаться понять, что означает изменение данных и что вы хотите сделать после этого. Но часто дело не только в том, что данные изменились, но и в том, почему они изменились.

Явное описание значительно упрощает навигацию по кодовой базе. И вот связь с первой ошибкой: если у вас есть явные команды, они отвечают за владение и обеспечение корректности состояния.

Окончание следует…

Источник: https://codeopinion.com/5-mistakes-that-make-your-code-unmaintainable/