Естественная и искусственная сложность

Собственно, мысль не моя — вычитал ее в свое время в книже «97 Things Every Software Architect Should Know». Мысль из разряда «многое объясняет», особенно полезна для начинающих программистов.

Итак, естественная сложность проекта — сложность, обусловленная предметной областью. Я бы еще упростил определение — сложность, обусловленная интерфейсами. Допустим, если пользователю удобнее делать что-то именно так, а не иначе — стоит это сделать, даже если это добавит в проект «излишнюю» сложность.

Искусственная сложность проекта — сложность, обусловленная выбранными технологиями. Допустим, захотелось программисту «поиграться» с новомодными фреймворками, в итоге код перегружен тяжелым функционалом работы с мощной библиотекой. Из которой, по-хорошему, используется лишь 1% функционала.

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

По мере развития проекта, когда он обрастает «мясом» в столкновении с реальным миром, изначальная его красота куда-то уходит, теперь искусственная сложность по-настоящему ощущается. И чем дальше — тем больше. Особенно это касается сложных библиотек: то, что изначально казалось хорошей идеей в изначально простом проекте, часто вызывает реальные проблемы в конкретных задачах. Допустим, выбрал ты «красивый» протокол обмена, а на высоких нагрузках он реально тормозит. Или возникают баги, а причину их ты не понимаешь.

Я — сторонник простых «велосипедов»: если что-то можно решить «в лоб» максимально простым способом без дополнительных библиотек — стоит сделать именно так. Причем ни в коем случае не пытаться сделать «универсальные» решения: если нужно хранить, допустим, список последних просмотренных страниц, нужно сделать хранилище именно под страницы, а не городить абстрактное хранилище абстрактных объектов.

«Работа на будущее» НИКОГДА не окупается. Принцип «лучше за день научиться, зато потом за полчаса долететь» превращается в создание сферических коней в вакууме, которые никогда в итоге не выходят за рамки изначального проекта, то есть весь тот «универсальный» функционал только осложняет тебе жизнь.

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

Простое правило: если ты пишешь или используешь код, который непосредственно не решает твои сегодняшние задачи, ты работаешь впустую. Проверено не раз.

VN:F [1.9.20_1166]
0 голосов
2 комментариев
старее
новее большинство голосов
Межтекстовые Отзывы
Посмотреть все комментарии
Денис

Обычно игры с технологиями проходят с возрастом.