За все хорошее против всего плохого, хотя так не бывает

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

Причем это очень популярное заблуждение теоретиков от программирования. Почему-то считается, что надо одновременно бороться с дублирующим и зависимым (связанным) кодом. Типа с помощью декомпозиции (повторного использования кода путем вынесения его в отдельную процедуру или функцию) можно добиться изоляции (когда доработки ничего не ломают). Но как же так. Ведь даже в обычной жизни очевидно, что нельзя быть за все хорошее против всего плохого. Нельзя выступать за низкие налоги и одновременно за высокие социальные льготы, потому что такое просто невозможно.

В проекте с хорошей декомпозицией без дублей кода, с огромным количеством маленьких процедур, функций, методов, которые стремительно вызывают друг друга, изоляция невозможна, потому что все зависит от всего. Одно небольшое исправление может как эффект бабочки привести к самым неожиданным последствиям. А уж зависимость от сторонних разработок (библиотек) у большинства из нас вызывает яркие воспоминания об отказах после обновлений, описать которые можно только на эмоциональном русском языке. Наоборот, изолированный (несвязанный) код процедуры, функции, метода должен содержать в себе важные фрагменты, которые могут встретиться где-нибудь еще. Лишь бы изменение, добавление, обновление в одном месте системы не повлияло на другие отлаженные механизмы. Изоляция также может быть на уровне модулей с заимствованием (дублированием) служебных процедур и функций из других модулей и стандартных (сторонних) библиотек. Например, чтобы легко перенести модуль в другой (новый или наоборот устаревший) проект.

То есть, получается, что декомпозиция и изоляция - антагонисты и взаимодействие между ними - это шкала:

Декомпозиция <-------------------------> Изоляция

Ну или если вам не нравится такое представление, можно наоборот:

Изоляция <-------------------------> Декомпозиция

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

Так что же делать, где на рассматриваемой шкале поставить свою точку? Тут-то и сказывается опыт разработчика, который примет приемлемое решение исходя из задачи. Если нужно написать какую-нибудь утилиту для чего-нибудь очень специфического, в качестве Open Source или может речь идет о внутренней офисной системе с большими технологическими окнами (нерабочее время и целые выходные), то здесь вполне можно блеснуть передовыми технологиями и декомпозицией. А если у вас интеграция розничных продаж с банками, где возможны прямые финансовые потери вкупе с трудоемким неочевидным интеграционным тестированием и неотзывчивой техподдержкой, то ну его на фиг, пусть все методы будут максимально изолированными даже с дублирующим кодом. Чтобы при добавлении нового, не упало то что работало.

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

Вы все еще не согласны со мной? А если скажу, что ставшая популярной микросервисная архитектура (в противовес монолиту) - это отчаянная попытка добиться изоляции, с пониманием, что раз сервисы разные, значит и одинаковый код, просочившийся в каждый из них, больше не под запретом! Ну разве это не забавно...

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

←33 | заметка 34