Я считаю, что непонимание рядовым программером разницы между огромным фреймворком с кучей абстракций так как он должен быть абсолютно резиновым на все случаи жизни и его поделкой или даже "продуктом" приводит к тому, что пишут софт с ста слоями, ссут скопипастить мелочи и потом тонут в этом всем резинообразии, создавая абсолютно не поддерживаемое "легаси", которое потом переписывают.
@lina не хочу обидеть, но кажется ты не поняла, что я написал.
@3draven не хочешь, не обижай! ;)
@lina ок :)
@3draven Пример из жизни: у нас на предприятии использовали хорошее продуктовое решения для управления персоналом + заказами + закупками + бухгалтерией.
решение рабочее, на котором работали лет 20, постоянно донастраивая и дотачивая под нужды предприятия, со специальными шаблонами под новые ситуации, изменения законодательных норм и вот всего этого. А когда продукт оказался готов, заказчик решил, что пора сократить количество разарботчиков, досокращали до 1, а потом и вовсе остался один "айтишник" который всё что мог сделать - это настроить новые шаблоны, или подправить старые. И да, это действительно легаси - самое натуральное - на delfi на win32 api и выглядело оно также и сервер ему нужен был не новее 2000-го.
Потом пришло новое руководство и решило, "дорого! и морально устарело, переходим на 1С, и людей легче - нанимать, к продуктам 1С они привычнее, чем к ЭТОМУ"...
Года 3 с такой-то матерью "переходили", наверное уже перешли...
@3draven я о том, что заказчик (+ архитектор) должны думать о технических решениях своего продукта - им это по рангу положено. а разработчик должен эти решения реализовывать в тех рамках, которые ему поставлены. Если вместо короткого и лаконичного кода (но самописного велосипеда) надо вкрячить в продукт несколько мастодонтов - фреймворков, от функционала которых используется процентов 5, ну ок, такая задача... возможно, кому-то хотелось "по-быстрому" и "пока без продолжения"