Я считаю, что непонимание рядовым программером разницы между огромным фреймворком с кучей абстракций так как он должен быть абсолютно резиновым на все случаи жизни и его поделкой или даже "продуктом" приводит к тому, что пишут софт с ста слоями, ссут скопипастить мелочи и потом тонут в этом всем резинообразии, создавая абсолютно не поддерживаемое "легаси", которое потом переписывают.
@3draven почему "продукт" должен обладать свойством "поддерживаемость" в бизнес -схеме: "написали, продали, работает."?
Хотите новое?, ок! напишем новое - снова "уникальное" и за отдельную плату.
@lina у вас отличная бизнессссс-модель! Поздравляю.
@3draven я о том, что заказчик (+ архитектор) должны думать о технических решениях своего продукта - им это по рангу положено. а разработчик должен эти решения реализовывать в тех рамках, которые ему поставлены. Если вместо короткого и лаконичного кода (но самописного велосипеда) надо вкрячить в продукт несколько мастодонтов - фреймворков, от функционала которых используется процентов 5, ну ок, такая задача... возможно, кому-то хотелось "по-быстрому" и "пока без продолжения"
@3draven не хочешь, не обижай! ;)