Оверинжиниринг
Оверинжениринг - это попытка решить проблему, которой нет. Это когда к отвертке прикручивается вилка, на случай если захочется перекусить во время сборки мебели.
Quote
Simplicity is prerequisite for reliability
-- Dijkstra
Очень частая проблема. Например, требуется написать простой веб сервис на 5 пользователей, а разработчик тащит реактивные библиотеки рассчитанные на 10к одновременных подключений. Не нужно обманываться, при этом программист не думает о будущем или пытается построить расширяемую систему - он занимаются оверинженирингом.
Возможно, когда-то в будущем и появятся новые требования или пользователей станет сильно больше, а может быть и нет. Но вот излишне усложненный код, с которым придется работать коллегам в ближайшие N лет написали уже сейчас.
Затраты на чтение и поддержку этого кода будут значительными, а плюсов от его расширяемости - может никто и не увидеть.
Часто встречаю две крайности - либо весь код одной портянкой, либо дымящаяся куча паттернов, абстракций и обобщенного программирования. И надо сказать, что первый вариант намного лучше второго.
Часто программист убеждает себя, что вот в этом месте уж точно нужна расширяемость, но на самом деле он просто хочет написать что-то «веселое».
Это нормальный этап взросления инженера. Чаще всего с опытом это проходит, особенно когда приходится разбираться в коде коллег, с похожими проблемами. Самый лучший код - скучный.
Именно умение писать простой, скучный, код и есть высшая точка профессионализма для программиста.
Но нужно понимать, что просто не значит легко, писать простой код чертовски сложно (simple is not easy).
Код с функциями на 500 строк - лучше, чем лапша из абстрактных классов. Синхронный код лучше асинхронного. Монолит лучше микросервисов.