Бизнес-процессы компаний и так сложны сами по себе. Разработчики добавляют ещё больше сложности, порой необоснованную.
Очень часто сложность кода нарастает как снежный ком. И когда новый разработчик проекта разбирается с этим кодом и спрашивает у коллег почему это так и зачем так запутанно, то часто получает ответы типа: «Исторически так сложилось», «Этот коды написал человек, который уже не работает в этой компании» и тому подобное.
О сложности можно судить отвечая на вопросы
- Насколько сложно внести изменения?
- Насколько сложно протестировать?
Слишком большее количество движущихся частей
Избыточная конфигурация
- Системы становятся очень хрупкими
- Подвержены ошибкам
- Трудно разворачивать
- Трудно тестировать
- Трудно диагностировать проблемы
Избыточные зависимости
You don’t use Maven… it uses you!
Совсем без зависимостей не обойтись, однако нужно стремиться минимизировать их количество и добавлять, только то что действительно необходимо.
- Зависимости трудно поддерживать
- Зависимости быстро устаревают
- Зависимости становятся несовместимыми
Зависимости развиваются с разной скоростью. Чем больше зависимостей в проекте, тем дольше приходится ждать пока они поддержан последние изменения экосистемы языка.
Ненужные компоненты
Слишком много слоёв
Код, который расстраивает
- Код, который не работает
- Код, который работает… но не должен
Невидимые изменения
Методы классов делают, то чего нет в их названии, меняя состояния объектов, неожиданным образом. И чем больше такого невидимого кода, тем сложнее понимать и отслеживать логику программы. Что в конечном счёте негативно отражается на скорости и стоимости разработки.
Неконтролируемая изменяемость (mutability) объектов
Изменяемость объектов это нормально и даже иногда это хорошо. Но изменяемость должна быть под контролем и быть предсказуема.
Слишком новые технологии
Стремление использовать самые последние инструменты, технологии и фреймворки в проекте зачастую не оправдано и может нанести вред проекту.
Насколько трудно будет отказаться от этой технологии, библиотеки, фреймворка?
Отказаться от одной библиотеки и заменить её другой гораздо проще, чем от фрейворка.
Resume Driven Development — часто встречающийся подход разработке, при котором зависимости добавляются в проект для того чтобы упомянуть их в своём резюме.
Не создавайте, то что можно скачать.
Не качайте, то что вам по-настоящему не нужно.
Случайная сложность
Сложности кода бывают унаследованные от предметной области, от которых нельзя избавиться.
Сложности бывают непредумышленные, которые возникают в результате наших неверных решений.
Как только вы пытаетесь решить проблему с помощью пула потоков, вы сразу же приобретаете пул проблем.
Существует мнение, что не существует программистов, которые могут правильно работать с Concurrency.
Для правильной работы с Concurrency необходимо глубокое понимание модели памяти Java (Java Memory Model, JMM).
Ключевой навык проектирования, который необходимо развивать — это способность различать непредумышленную сложность от унаследованной сложности.
Императивный стиль программирования является одним из видов непредумышленной сложности.
Декларативный стиль программирования помогает сохранить фокус внимания на том ЧТО нужно сделать вместо КАК это сделать.
Переплетение (Entwinement)
Попытка срастить разные по своей природе системы порождает избыточную сложность.
Легкоподдерживаемый код это подарок, который мы дарим себе на будущее.