День 2365. #ЗаметкиНаПолях
5 Mistakes That Make Your Code Unmaintainable
Начало

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

То, что кажется простым, например, контроллер, вызывающий уровень доступа к данным, часто реализовано гораздо сложнее. Контроллер вызывает сервис, вызывающий другой сервис, использующий метод расширения, который вызывает ORM, обращающийся к БД. Такая косвенная связь часто невидима, но затрудняет отслеживание запросов. Ошибка заключается в неосознавании добавляемой косвенности и того, представляет ли она реальную ценность.

Если ваш вызывающий код тесно связан с абстракцией, созданной только для того, чтобы скрыть зависимость от сторонних компонентов, это может быть оправдано, если есть несколько реализаций или вы хотите упростить API. Но если абстракция используется только в одном месте и не служит никакой реальной цели, она бесполезна. Бесполезные абстракции затрудняют навигацию по коду и его поддержку. Иногда лучше управлять связностью напрямую, чем создавать ненужные уровни.

Главное — помнить о добавляемой косвенности и о том, действительно ли она добавляет ценность. Слабая связность полезна. Но бесполезная косвенность и абстракции, которые не несут никакой ценности, а создаются лишь для «чистоты кода», вредны.

4. Игра в «Что, если»
Продумывание всех возможных будущих сценариев и попытка написать код, учитывающий их заранее. Это часто нарушает принцип YAGNI (You Ain't Gonna It — «Вам это не понадобится»). Вы можете подумать: «А что, если кто-то попросит похожую, но немного другую функцию?» Но если никто её ещё не запросил, как узнать, ценна ли она?

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

Проблема с вопросом «что, если?» заключается в стоимости владения. Это не только первоначальные затраты на разработку, но и необходимость постоянного обслуживания и работы с кодом, который никто не использует, что добавляет сложности.

5. Неправильное управление рабочими процессами
Представьте себе простой рабочий процесс, например, размещение заказа. Вы проходите стадии оформления заказа, подтверждения, обработки оплаты и затем отправляете email с подтверждением. Кажется, просто.

Проблема, если рассматриваете это как один длинный процедурный процесс, а не как рабочий процесс с изолированными шагами. Что будет, если возникнет ошибка при списании средств с карты? Как ваш код справится с этой ситуацией? Нужно ли отменить заказ? Отправить email? Вывести ошибку пользователю?

Если ваш код слишком процедурный, у вас, вероятно, будет запутанный клубок условий и обработки исключений, который сложно отслеживать и поддерживать. Рабочие процессы следует рассматривать как небольшие блоки, которые выполняются изолированно и переходят от одного шага к другому. Такое управление значительно упрощает обработку ошибок, повторных попыток и ветвление.

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

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

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