Нонче впиливаю в очередную версию SObjectizer-а новую фичу. И наибольшую головную боль доставляют фичи, которые уже были добавлены ранее.
Уже говорил ранее неоднократно, но повторю еще: когда работаешь долго над одним и тем же проектом, то на собственной шкуре и на собственном коде убеждаешься в истинности утверждения про благие намерения и дорогу в ад. Сперва, когда кодовая база небольшая, добавлять новые фичи легко и просто. Понадобилось что-нибудь? Нет проблем. Потом еще что-то? Да с полпинка...
А вот по прошествии лет пяти-семи за все излишества молодости приходит время расплачиваться. Потому что новые фичи добавлять нужно, но это нужно делать уже с оглядкой на то, что уже есть. Ничего не поломать -- это само собой. А вот еще и подружить, чтобы возможности одной фичи согласовывались с другой... Вот это может стать настоящим квестом.
Пара-тройка примеров из SO-5.
Вот когда-то давно, из соображений эффективности, было сделано разделение на сообщение и сигналы. Действительно, сигналы не переносят данных. В принципе не переносят. Так зачем для сигнала создавать пустой объект, подсчитывать ссылки на него? Давайте экономить ресурсы. Ok. С тех пор как только заходит речь о манипуляции заявками и вызове обработчика с передачей в него экземпляра сообщения, так сразу же приходится разбираться сообщение ли у нас или сигнал.
Когда-то все сообщения должны были наследоваться от message_t. Для автора фремворка это очевидно, для пользователей не очевидно и требует лишних телодвижений. Давайте сделаем возможным отсылку объекта произвольного типа. Ok. Сделали через неявное оборачивание в объект-наследник message_t. С тех пор, как только нужно получить доступ к содержимому сообщения, приходится разбираться, имеем ли мы обычного наследника message_t или же у нас обертка вокруг пользовательского типа. Ну и да, может у нас вообще сигнал, а не сообщение.
Когда-то не было защиты агентов от перегрузки вообще. Конечно, каждый мог сделать для себя собственный механизм защиты. Но хотелось чего-то готового из коробки. Ok. Появились лимиты. Теперь, при необходимости расширить или изменить механизм доставки сообщений приходится заботится о том, чтобы изменения не поломали работу этих самых лимитов.
В общем, разработка и сопровождение библиотек -- это очень специфический вид деятельности. Чем дольше библиотека живет, тем дороже ее развитие обходится.
В заголовок вынесена фраза вот из этого анекдота, который, в принципе, очень в тему, но, как говаривал наш преподаватель по матану, "с точностью до наоборот":
Трамвай… Бабка наклоняется ко мне — Вот ты такая красивая, милая, такая замечательная. … Небось, даёшь-то не всем ?: Я — Да что вы, бабушка! Как можно? Конечно, не всем! Старушка со вздохом: — О каждом пожалеешь О КАЖДОМ!