Оver-engineering - "зачем так сложно?" - Мортира Карл

[mazzy]

Исходная ветка в разделе про аксапту: Оver-engineering - "зачем так сложно?"

Самые странные боевые машины - Мортира Карл
https://www.youtube.com/watch?v=l9FjF3fXm0E

Предлагаю всем желающим поговорить об Оver-engineering вообще
переместиться в курилку.

[ax_mct]

Отсюда https://habrahabr.ru/post/99889/

Цитата:

Если вы собираетесь написать сто строк кода, чтобы решить задачу, которую можно было бы решить и десятью строками, остановитесь и спросите себя: какого чёрта?

Когда я чувствую искушение чрезмерно обобщить или пере-проектировать кусочек кода, это часто вызвано страхом. Страхом, что кто-то найдёт по-настоящему хорошую причину, почему я не должен был выбрать простое решение.

Я беспокоюсь, что придется переписать его?
Я беспокоюсь, что кто-то раскритикует его или, что я буду выглядеть глупо?
Я беспокоюсь, что это недостаточно профессионально?

А возьмите да напишите простое, конкретное, короткое решение и добавьте к нему короткий комментарий вроде этого: Заменить шаблоном Visitor, если этот код начнёт разрастаться.

P.S. Это чистый копи-паст. Поместил все в QUOTE после ответа Mazzy. Так как запутал.

[mazzy]

Цитата:

Сообщение от ax_mct

А возьмите да напишите простое, конкретное, короткое решение и добавьте к нему короткий комментарий

Господи, вы опять к отношениям и к плохим людям сводите.

Цитата:

Сообщение от mazzy

нет, конечно. какие нафиг "отношения"?
разницу вносят очень технические и прагматичные моменты.

в вашем конкретном абзаце разница проявляется в комментарие.
Комментарий кому?

окружению, которое выполняет unitTest'ы, функциональные тесты?
причем делает это в разное время и по разным событиям?

вообще вы предполагаете тестировать "простое, конкретное, короткое" решение?
в ручном или автоматическом режиме?
с какими данными?

а есть еще и нагрузочные тесты.
есть еще тесты, которые проверяют совместимость на уровне программных интерфейсов.

простой код должен быть только у самого кода, который входит в поставку
или простой должен быть весь код включая тесты?

есть еще и другие критерии, помимо тестирования.
среди этих критериев будут и ошибочные, будут и неучтенные.

Возвращаясь к Мортире - не учли вес и ошиблись в эффективности.
Но теперь эти критерии учитываются - танки проверяются на возможность транспортировки.

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

разные критерии => разная простота.
разная простота => недопонимание групп разработчиков.
недопонимание разработчиков => зачем так сложно?

вроде тривиальная логическая цепочка.
Но упорно к недостаткам у людей сводите.

Цитата:

Сообщение от Maxim Gorbunov

"Программисты должны быть смелыми, чтобы не пугаться, когда все перепуталось так, что никто не разберет..." (c) Тарас

[ax_mct]

Цитата:

Сообщение от mazzy

...
в вашем конкретном абзаце разница проявляется в комментарие.
Комментарий кому?

окружению, которое выполняет unitTest'ы, функциональные тесты?
причем делает это в разное время и по разным событиям?

вообще вы предполагаете тестировать "простое, конкретное, короткое" решение?
в ручном или автоматическом режиме?
с какими данными?

а есть еще и нагрузочные тесты.
есть еще тесты, которые проверяют совместимость на уровне программных интерфейсов.

простой код должен быть только у самого кода, который входит в поставку
или простой должен быть весь код включая тесты?

В наших кастомизациях в AX сложность чаще всего появляется чтобы стыдно не было перед другими программистами. Ну или чтобы выглядеть профи.

Поэтому нормально писать такие комментарии в коде. Смешно но в последнее время я часто такие пишу. Типа того "не совсем правильно, но вы мне спасибо скажете когда будете дебажить" к примеру в случае сложных join.

Насчет тестирования здесь не существенно - пара достаточных статических функций или реализация MVC в стакане с водой. В AX в моей реальности - все ручками.

Простой код должен быть везде.

[Sancho]

любая, даже самая сложная проблема, всегда имеет простое, лежащее на поверхности, неправильное решение. (с)

[ax_mct]

Цитата:

Сообщение от Sancho

любая, даже самая сложная проблема, всегда имеет простое, лежащее на поверхности, неправильное решение. (с)

Правильность/неправильность - это от лукавого беса.
Код или выполняет свои функции - или нет.

Решать надо задачи бизнеса, а не кодирования.
Потребность покрывать автоматическими тестами - это решение задачи кодирования.

Ну есть кот, немытый грязный, и как то он там ловил мышей. Успешно ловил.
До тех пор пока производителям мышеловок показалось что он это делает неправильно.
Теперь кот сидит и вылизывает яйца.

[mazzy]

Царь-танк Лебеденко, также известный как Нетопырь, был классическим примером занесения идеи в голову непосредственно лицу, принимающему решение

Самые странные боевые машины - Царь-танк
https://www.youtube.com/watch?v=jSuueFEfjZs

===================
в то время как ... военные хотели от Кристи ..., он совершенно внезапно разработал по меньшей мере странную машину
Самые странные боевые машины - Летающие танки
https://www.youtube.com/watch?v=nanEf6W7jjM

[macklakov]

Цитата:

Сообщение от mazzy

в то время как ... военные хотели от Кристи ..., он совершенно внезапно разработал по меньшей мере странную машину
Самые странные боевые машины - Летающие танки
https://www.youtube.com/watch?v=nanEf6W7jjM

Логичный, для своего времени, концепт. Тогда воздушный дессант оссуществлялся с помощью планеров ночью. По банальной причине, их было не видно и не слышно, а радары были редкостью. Да и потом, тогдашние самолеты были на уровне "кукурузника", они просто не в состоянии были что-то более-менее серьезное поднять.
Не выгорела технология не потому что бредовая, а по той простой причине, что титана не хватало. Современная дессантная БМП достаточно легкая чтобы таким образом доставлять можно было. А тогда даже самый легкий танк был слишком тяжелым.

[mazzy]

смотрю про экспериментальные машины и думаю:

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

но что заставляет людей экспериментировать и кардинально переделывать шестую-седьмую версию успешно работающей системы?
причем это касается, и аксапты, и навижина, и, насколько я понимаю, MS CRM.

новые люди, которые не знают как работает предыдущая система?
вроде нет. мы отлично видим, во всех dynamics продуктах есть старички.

подключение нового инструментария? пусть так.
но почему этот инструментарий не распространяется на всю экосистему?

=================
и еще. пусть эксперименты.
а каков механизм избавления от этих экспериментов?

в инженерном деле это остановка производства неудачной серии.
вплоть до разгона конструкторского бюро и перепрофилирования производственных мощностей.

в программировании это рефакторинг legacy-систем. есть много холиваров на эту тему.
но МС код вообще не рефакторит.

=================
лично мне в голову приходят такие аналоги хорошо развитых систем, где произошел Оver-engineering:
= те же танки (World of Tanks) с механизмом стана для арты
= это Дота с совершенно безумными последними изменениями
= World of Warcraft и его переориентация с социальной среды на одиночное прохождение

какие еще примеры экспериментов и Оver-engineering в программных продуктах можно привести?
есть ли примеры успешного преодоления последствий?
какие еще механизмы есть в программировании для борьбы со сложностью и устаревшим кодом? есть ли примеры-аналоги?

[ax_mct]

Цитата:

Сообщение от mazzy

но что заставляет людей экспериментировать и кардинально переделывать шестую-седьмую версию успешно работающей системы?

Бояном было еще 15 лет назад но остается актуальным. Более того именно сейчас интересно читать
http://k-press.ru/cs/2001/1/clr/clr.asp
Вариант 1. Конспирологический. Верхи. "Завоевание мира".

Цитата:

Итак, CLR – это рантайм-среда, призванная упростить и обезопасить работу с компонентами для любого совместимого с ней средства или языка. Замечательно, скажете вы, но зачем же было ломать все и вся? Не лучше ли было подправить спецификацию COM, уточнить требования, предъявляемые к языкам программирования, ведь, например, VB совсем чуть-чуть не удовлетворяет этим требованиям? Это была бы, хотя и бурная, но эволюция. А так снова революция с неизбежным разрушением всего старого и с еще более неизбежной "наклепкой" всего нового. Причем это новое – не маленькая фитюлька, а то самое ВСЁ. На этот вопрос можно ответить, если задаться вопросом: а что, собственно, надо Microsoft?...
...
При таком раскладе эволюция смерти подобна. Надо ломать при малейшем подозрении на несоответствие высоким идеалам, и строить заново. А уж если строить, то, конечно же, новый мир.
...

Вариант 2. Банальный. Неуемные технари. "Фатальный недостаток".

Цитата:

Но другая группа в Microsoft нашла в *** фатальный недостаток – его писали не они!
...
Но тут некая группа в Microsoft нашла фатальный недостаток в **** - её писали не они!

[ax_mct]

Цитата:

Сообщение от mazzy

но что заставляет людей экспериментировать и кардинально переделывать шестую-седьмую версию успешно работающей системы?
причем это касается, и аксапты, и навижина, и, насколько я понимаю, MS CRM.

новые люди, которые не знают как работает предыдущая система?
вроде нет. мы отлично видим, во всех dynamics продуктах есть старички.

подключение нового инструментария? пусть так.
но почему этот инструментарий не распространяется на всю экосистему?

=================
и еще. пусть эксперименты.
а каков механизм избавления от этих экспериментов?

в инженерном деле это остановка производства неудачной серии.
вплоть до разгона конструкторского бюро и перепрофилирования производственных мощностей.

в программировании это рефакторинг legacy-систем. есть много холиваров на эту тему.
но МС код вообще не рефакторит.
...
какие еще примеры экспериментов и Оver-engineering в программных продуктах можно привести?
есть ли примеры успешного преодоления последствий?
какие еще механизмы есть в программировании для борьбы со сложностью и устаревшим кодом? есть ли примеры-аналоги?

Как Groupon мигрировал от монолитного Rails приложения к новой Node.js инфраструктуре
https://habrahabr.ru/post/200906/

Цитата:

Недавно мы завершили годовой проект миграции веб-трафика компании Групон в США от монолитного Ruby on Rails приложения к новому стеку Node.js и получили существенные результаты.

[ax_mct]

Цитата:

Сообщение от mazzy

но что заставляет людей экспериментировать и кардинально переделывать шестую-седьмую версию успешно работающей системы?

именно что вопрос вопросов.

Как вариант
https://ru.wikipedia.org/wiki/%D0%A1...82%D0%BA%D0%B8

Цитата:

В программировании, также часто ссылаются на «NIH-синдром» как на тенденцию заново изобретать колесо[en] (повторно то, что уже имеется; изобретать велосипед) основываясь на убеждении, что домашняя разработка по своей природе более приспособленная, более безопасная, более контролируемая, быстрее разрабатывается и претерпевает меньше общих расходов (включая эксплуатационные расходы), чем использование существующих реализаций.

Именно такие же аргументы недавно звучали на форуме.

"Фатальный недостаток - это сделано не нами."

P.S.
Кстати решение создать "X++" вместо использования Java - тот самый программизм и тот самый "Фатальный недостаток" которые закономерно определили судьбу.

[Raven Melancholic]

Цитата:

Мне кажется тут первый список понятнее - ясно кто подчиняется общему умолчанию а кто нет.

У этих животных хвосты длинные:
- Лиса
- Бобер
- Кенгуру (кроме австралийских короткохвостых)
- Собака

- У лисы длинный хвост.
- У бобра недлинный хвост.
- Кенгуру имеет длинный хвост (кроме австралийских короткохвостых).
- Такой же хвост и у собаки.

Если вернуться к почему-то нелюбимым некоторым участникам форума принципам и паттернам, то можно посмотреть на тот же SOLID, а именно к тому, что стоит за буковкой I - Interface segregation
Если длина хвоста важна в некоторых случаях, но уже есть иерархия или только ради хвоста нет смысла её создавать, то почему бы не сказать, что длина хвоста это только интерфейс для конкретного использования?
Проектируем чехлы для хвостов - нам достаточно знать, что можем получить длину хвоста (среди других параметров).
Завтра проектируем систему отопления и нужно знать сколько времени требуется зверю, чтобы преодолеть входную дверь, нужно уже знать длину от кончика носа до кончика хвоста - нужен другой интерфейс тех же объектов.
Следование указанному принципу это программизм? Вроде бы нет - просто представление объекта с разных точек зрения, требуемых для конкретных задач.

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.

Как пользователю таблицы Менделеева - мне важна как водка работает.
Изготовление водки это
- приготовление исправленной воды
- смешивание ректификованного этилового спирта из пищевого сырья с исправленной водой,
- обработка водно-спиртового раствора активированным углём или модифицированным крахмалом,
- фильтрование,
- внесение ингредиентов,
Одни глаголы.
Общее между углем и крахмалом и единый процесс для них - мне не то что неинтересен, я скорее сочту это опасным. А если разработчику нужен час чтобы продублировать обработку крахмала от обработки углем, и две недели чтобы "правильно" это обьединить, то мне лучше час.

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

Жить мешает программистский зуд большинства программистов когда продукт прогрызают как термиты - дерево. Не ради продукта, а ради своего комфорта и своей религии. То что имеем в Аксаптой в большей части виноват этот зуд работников, а не злые капиталисты.

[Raven Melancholic]

Цитата:

Как пользователю таблицы Менделеева - мне важна как водка работает.

Опс.
Чтобы принимать или обходить какие-то правила, все таки, в первую очередь, нужно их знать. Тогда можно принимать решения что с этими правилами делать.
Таблица Менделеева и водка это вообще разные вещи. Более того, водка к Менделееву не имеет никакого отношения. Свою таблицу он создал работая как химик, а формулу, что 40 оборотов спирта это ориентир для некоторых действий, работая над таможенном и налоговым тарифом в качестве чиновника соответствующего ведомства. При этом не было задачи создать идеальный рецепт водки, задача была простая - как учесть то, что разные производители по разному эту водку бодяжили, а налог хотелось собирать на основе каких-то общих принципов.
Вообще, ax_mct, у меня почему-то сложилось такое впечатление, что Вы совсем не против каких-то правил, принципов, шаблонов. Когда кто-то предлагает, что эти все правила нужны для того, чтобы применять их разумно и нарушать когда это упрощает жизнь, то от Вас сразу идут сообщения что они вообще не нужны.
Такое впечатление, что большинство Ваших провокационных постов создано ради того, чтобы участники форума не зацикливались на чем-то, что "вроде бы и понятно и так", а пообсуждали что "так, что не так". Ну не верю я,Что когда Вы сдаете какой-то проект заказчику на ревью, тот пропустит метод в 2000 и более строк.

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

Опс.
Чтобы принимать или обходить какие-то правила, все таки, в первую очередь, нужно их знать. Тогда можно принимать решения что с этими правилами делать.
Таблица Менделеева и водка это вообще разные вещи. Более того, водка к Менделееву не имеет никакого отношения. Свою таблицу он создал работая как химик, а формулу, что 40 оборотов спирта это ориентир для некоторых действий, работая над таможенном и налоговым тарифом в качестве чиновника соответствующего ведомства. При этом не было задачи создать идеальный рецепт водки, задача была простая - как учесть то, что разные производители по разному эту водку бодяжили, а налог хотелось собирать на основе каких-то общих принципов.
Вообще, ax_mct, у меня почему-то сложилось такое впечатление, что Вы совсем не против каких-то правил, принципов, шаблонов. Когда кто-то предлагает, что эти все правила нужны для того, чтобы применять их разумно и нарушать когда это упрощает жизнь, то от Вас сразу идут сообщения что они вообще не нужны.
Такое впечатление, что большинство Ваших провокационных постов создано ради того, чтобы участники форума не зацикливались на чем-то, что "вроде бы и понятно и так", а пообсуждали что "так, что не так". Ну не верю я,Что когда Вы сдаете какой-то проект заказчику на ревью, тот пропустит метод в 2000 и более строк.

Для меня как пользователя таблицы Менделеева - это водка. Ну или виски. Так же как и для пользователя ПО - софт это его функциональность, скорость, надежность, цена. И отнюдь не ООП.

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

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

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

Либо сложное на простом, либо простое - на сложном.

[Raven Melancholic]

Цитата:

Сообщение от ax_mct

Для меня как пользователя таблицы Менделеева - это водка. Ну или виски.

Вот и пришли к какому-то классифицирующему принципу.
"для меня это ...", а вот для ученых из Дубны это точка отчета для поиска "пояса стабильности".
Так же "для меня 2000 строк кода в одном методе это нормально, заказчик получил ту функциональность, что хотел", а для тех, кому придется это развивать дальше (спецам клиента, другим внешним подрядчикам) это совсем не нормально.

[ax_mct]

P.S. [B]контрагент.Действие() vs действие(Контрагент) это принципиальный подход.
Vendor.AccountNum и Customer.AccountNum имеют общность.
В то время как purchaseFrom(Vendor) и purchaseFrom(Customer) не соответствует бизнес-процессам.
Более этого они существуют в разных функциональных модулях.

Общность должна быть по функциям, а не по признакам. Так как мы обслуживаем операции, а не библиотеку.

[Raven Melancholic]

Вообще-то сама тема "...почему так сложно...", по какой-то прихоти разбитая на две, уже показывает, что все не так просто.
В одной теме разрешено обсуждать "почему так сложно" только в отношении Аксы, в другой другие случаи.
А если есть пересечения? А как понять, что мое сообщение относится только к Аксе, а не вообще к сложности понимания мира и моих стремлений на это повлиять?

[Raven Melancholic]

Цитата:

Общность должна быть по функциям, а не по признакам.

На мой взгляд (не претендующий на истину), общность должна быть не по функциям, ни по признакам, а по поведению, которое включает и признаки и функции.