Хотел mazzy процитировать но запутался в наших с ним взаимных квотах
Это как раз типичная ERPшная ситуация. Вендору, по каким-то причинам, нужно изменить функционал. Возможно, изменение этого функционала приведет к несовместимости с доработками партнеров и клиентов. При этом, вендор, в общем случае, ничего не знает об этих партнерских и клиентских доработках и оценить масштабы бедствия просто не может.
Если не изобретать велосипед - то что надо было бы, по твоему мнению, делать в подобной ситуации ? Вариант ответа "Правильно программировать", "Думать головой когда программируешь" и т.п. не подходит. Во первых люди вообще склонны ошибатся, во вторых никакие методики не позволяют гарантированно программировать с учетом будущих событий
Невозможно разрабатывать программу так, чтобы она гарантирована легко адаптировалась под неизвестные в данный момент будущие изменения функциональности. То есть - конечно мне тоже время от времени попадаются куски кода, за которые их авторам хочется оторвать руки.
Но я понимаю, что вполне возможно, что в тот момент когда этот код писался - он не был таким уж кривым...
Ну и кстати - ситуация с библиотеками не очень подходит в качестве примера. Библиотеки - это некий внешний механизм, который я интегрирую в систему через опубликованные интерфейсы. При интеграции я не изменяю исходных текстов этих библиотек, я работаю с ними через интерфейсы. (Конечно бывает, что без изменения интерфейсов, владелец библиотеки как-то неявно меняет ее внутренности и моя программа перестает работать, но это нештатная ситуация).
При разработке в ERP мне постоянно, штатным образом, приходится модифицировать исходные тексты, владельцем которых я не являюсь.
Соответственно - на мой взгляд самый правильный вектор развития систем разработки в ERP, это какое-то развитие механизма слоев в сторону механизма патчей.