Показать сообщение отдельно
Старый 24.06.2017, 17:29   #18  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Опс.
Чтобы принимать или обходить какие-то правила, все таки, в первую очередь, нужно их знать. Тогда можно принимать решения что с этими правилами делать.
Таблица Менделеева и водка это вообще разные вещи. Более того, водка к Менделееву не имеет никакого отношения. Свою таблицу он создал работая как химик, а формулу, что 40 оборотов спирта это ориентир для некоторых действий, работая над таможенном и налоговым тарифом в качестве чиновника соответствующего ведомства. При этом не было задачи создать идеальный рецепт водки, задача была простая - как учесть то, что разные производители по разному эту водку бодяжили, а налог хотелось собирать на основе каких-то общих принципов.
Вообще, ax_mct, у меня почему-то сложилось такое впечатление, что Вы совсем не против каких-то правил, принципов, шаблонов. Когда кто-то предлагает, что эти все правила нужны для того, чтобы применять их разумно и нарушать когда это упрощает жизнь, то от Вас сразу идут сообщения что они вообще не нужны.
Такое впечатление, что большинство Ваших провокационных постов создано ради того, чтобы участники форума не зацикливались на чем-то, что "вроде бы и понятно и так", а пообсуждали что "так, что не так". Ну не верю я,Что когда Вы сдаете какой-то проект заказчику на ревью, тот пропустит метод в 2000 и более строк.
Для меня как пользователя таблицы Менделеева - это водка. Ну или виски. Так же как и для пользователя ПО - софт это его функциональность, скорость, надежность, цена. И отнюдь не ООП.

Я совсем не против правил, принципов, шаблонов. Но против привнесения сложности в коде там где есть сложность бизнес-процессов. Что-то одно должно быть просто и тупо. Либо код, либо процессы.
Путь по которому пошел продукт это усложнение кода. Как результат - по сути процессы уже менять нельзя.

В случае простого и тупого кода, с дублированием и без нереальных абстракций, продолжали бы работать над сложными бизнес-процессами.

Код - я подразумеваю все техническую сторону. Сложные бизнес-процессы (а в ERP они всегда такие) надо кодировать как можно проще и ближе к реальности. Роль того что сложность кода зашкалила в том что по сути программирование прикрыли - одна из основных. А зашкалила она по большому счету потому что заигрались с ООП.

Либо сложное на простом, либо простое - на сложном.
За это сообщение автора поблагодарили: Sancho (2).