Сложность это плохо
Добавить из
https://en.m.wikipedia.org/wiki/Law_of_conservation_of_complexity
https://en.m.wikipedia.org/wiki/Programming_complexity
Сложность влияет на поддерживаемость (ремонтопригодность) и возможность развития (стоимость выявления причин и внесена изменений)
Влияние сложности
“Простота — это душа надёжности”, — Эдсгер Дейкстра
“Если мы посчитаем количество строк кода, то стоит рассматривать их не как “произведённые строки”, а как “строки потраченные”, — Эдсгер Дейкстра.
“Код легче писать, чем читать”, — Джоэл Спольски.
“Любой дурак может написать код понятный для компьютера. Хорошие же программисты пишут код, который смогут понять люди”, — Мартин Фаулер
“Любая работоспособная сложная система является итогом эволюции более
простой работоспособной системы… Сложная система, разработанная «с нуля»,
никогда не работает так, как надо и никакие «заплатки» не заставят ее работать
правильно. Проектирование следует начинать с простой работоспособной
системы.” — Буч Г.
"Инженер - такой человек, который с легкостью превратит простую проблему в сложную, а потом решит её через задницу" — народное.
Сложность ведет к превышению плановых трудозатрат, времени, переработкам и выгоранию. В начале проекта сложности не видно. Разработчики склонны выкинуть все старое и переписать заново, что может пойти не так? Согласно данным, приведенным в книге Роберта Мартина "Чистая архитектура" с ростом сложности резко растет стоимости доработки каждой новой фичи.
Психологические трудности
Обосновать высокие трудозатраты (что может пойти не так?) трудно и себе то, а другим и подавно. Разработчик может дать обещания сделать задачу в излишне оптимистичные сроки. Дальше обязательно возникают непредвиденные трудности и переработки. "Ну ты что же, не профессионал? Задача то простая!" - опасный психологический феномен, даже если не давит заказчик или руководитель. Давит твое эго.
Типы сложности
Внутренняя сложность задачи (inherent complexity) и непреднамеренно привнесённая сложность (accidental complexity).
Типичная ловушка, с которой мы сталкиваемся в процессе проектирования ПО, проявляется в фокусировании на том, насколько "простым" является для нас чтение и понимание конкретного фрагмента кода. Однако фокусирование на простоте чревато множеством затруднений, поскольку сложность не может быть удалена: она может быть только перемещена. Если вы её перемещаете из своего кода, куда она тогда денется?
Отведите ей подобающее место и изолируйте ее.
Если сложность реализации значительно больше чем сложность описания это тревожный звоночек.
Ментальные ограничения
"Я не буду думать об этом сегодня, я подумаю об этом завтра" — Скарлетт о Хара.
При продумывании программы думайте сконцентрируйтесь на нужном. Поскольку все в голове не помещается ненужные сейчас детали должны вытесняться из сознания.
Когда программа создается специалист может удержать сразу несколько предметных областей и пишет все подряд (программирование снизу вверх - "просто взять и написать").
Когда программа читается, то неподготовленный (а так обычно и бывает) читатель может удержать в голове одновременно лишь одну предметную область. Здесь требуется программирование сверху вниз - "хватит лить воду, ты мне мясо давай!"). Код читается втрое чаще чем пишется, поэтому после написания простого кода и проверки вариантов реализации код нужно причесать, провести рефакторинг. Когда система выходит из состояния стартапа нужно провести рефакторинг снова.
Методы измерения и контроля сложности
Декомпозиция и отладка по частям, уменьшение числа связей:
Разбиение системы на более мелкие, независимые модули, тогда сложность, т.е. количество связей будет равна сумме сложностей компонентов, а не факториалу их числа в случае связей "все зависит от всего"
Отладка и тестирование каждого модуля по отдельности.
Композиция проверенных деталей проверенным способом:
Использование простых, проверенных способов объединения модулей, например, чистые функции.
Абстракция:
Ментальная инкапсуляция, скрытие деталей реализации и представление только необходимой информации.
Инкапсуляция:
Защита от "прорыва сложности" за пределы одного модуля в другие
Ограничение доступа к внутренним деталям реализации модулей ради безопасности.
Эволюционное наращивание сложности:
Постепенное добавление новой функциональности с уточнением требований
Уточнение границ модулей и ужесточение правил (границ)
Баланс между быстро и правильно
Нужно просто писать код так же естественно как описывать проблему собеседнику - до тех пор пока ментальная сложность создания и чтения не превысит порога когда имеет смысл рефакторинг кода. Рефакторинг должен быть простой и естественный как дыхание.
Вот пара примеров, когда погоня за "правильным кодом приводит к ужасным последствиям"
Что на практике?
А на практике были случаи когда я писал код в 10(!) раз более краткий и понятный чем у соседа по цеху.
И вот как я вижу чужой переусложненный код
В видео объясняется, как различные сервисы, такие как бинго, papaya, mbs, ulna, raccoon, wingman, rgs, barbie doll, ringo two, bls и "галактус", работают вместе для предоставления информации о пользователях.
...
"Галактус" - это всезнающий агрегатор, который собирает информацию от других сервисов и предоставляет ее ведомым.
Не делайте так!
