Сложность это плохо

Влияние сложности

“Простота — это душа надёжности”, — Эдсгер Дейкстра

“Если мы посчитаем количество строк кода, то стоит рассматривать их не как “произведённые строки”, а как “строки потраченные”, — Эдсгер Дейкстра.

“Код легче писать, чем читать”, —  Джоэл Спольски.

“Любой дурак может написать код понятный для компьютера. Хорошие же программисты пишут код, который смогут понять люди”,  —  Мартин Фаулер

“Любая работоспособная сложная система является итогом эволюции более
простой работоспособной системы… Сложная система, разработанная «с нуля»,
никогда не работает так, как надо и никакие «заплатки» не заставят ее работать
правильно. Проектирование следует начинать с простой работоспособной
системы.”  — Буч Г.

"Инженер - такой человек, который с легкостью превратит простую проблему в сложную, а потом решит её через задницу"  — народное.

Сложность ведет к превышению плановых трудозатрат, времени, переработкам и выгоранию. В начале проекта сложности не видно. Разработчики склонны выкинуть все старое и переписать заново, что может пойти не так? Согласно данным, приведенным в книге Роберта Мартина "Чистая архитектура" с ростом сложности резко растет стоимости доработки каждой новой фичи.

Психологические трудности

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

Типы сложности

Внутренняя сложность задачи (inherent complexity) и непреднамеренно привнесённая сложность (accidental complexity).

Типичная ловушка, с которой мы сталкиваемся в процессе проектирования ПО, проявляется в фокусировании на том, насколько "простым" является для нас чтение и понимание конкретного фрагмента кода. Однако фокусирование на простоте чревато множеством затруднений, поскольку сложность не может быть удалена: она может быть только перемещена. Если вы её перемещаете из своего кода, куда она тогда денется?

Отведите ей подобающее место и изолируйте ее.

Если сложность реализации значительно больше чем сложность описания это тревожный звоночек.

Ментальные ограничения

"Я не буду думать об этом сегодня, я подумаю об этом завтра" — Скарлетт о Хара.

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

Когда программа создается специалист может удержать сразу несколько предметных областей и пишет все подряд (программирование снизу вверх - "просто взять и написать").

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

Методы измерения и контроля сложности

Декомпозиция и отладка по частям, уменьшение числа связей:

• Разбиение системы на более мелкие, независимые модули, тогда сложность, т.е. количество связей будет равна сумме сложностей компонентов, а не факториалу их числа в случае связей "все зависит от всего"

• Отладка и тестирование каждого модуля по отдельности.

Композиция проверенных деталей проверенным способом:

• Использование простых, проверенных способов объединения модулей, например, чистые функции.

Абстракция:

• Ментальная инкапсуляция, скрытие деталей реализации и представление только необходимой информации.

Инкапсуляция:

• Защита от "прорыва сложности" за пределы одного модуля в другие

• Ограничение доступа к внутренним деталям реализации модулей ради безопасности.

Эволюционное наращивание сложности:

• Постепенное добавление новой функциональности с уточнением требований

• Уточнение границ модулей и ужесточение правил (границ)

Баланс между быстро и правильно

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

Вот пара примеров, когда погоня за "правильным кодом приводит к ужасным последствиям"

• Чистый код и ужасная производительность

• Hello world enterprise edition

Что на практике?

А на практике были случаи когда я писал код в 10(!) раз более краткий и понятный чем у соседа по цеху.

И вот как я вижу чужой переусложненный код

В видео объясняется, как различные сервисы, такие как бинго, papaya, mbs, ulna, raccoon, wingman, rgs, barbie doll, ringo two, bls и "галактус", работают вместе для предоставления информации о пользователях.

...

"Галактус" - это всезнающий агрегатор, который собирает информацию от других сервисов и предоставляет ее ведомым.

Не делайте так!