ERP как залежи говнокода

[mazzy]

Цитата:

Лет десять назад в ходу был анекдот про МИГ-29, которые купили индусы. Купили в разобранном виде. Собирают, получается паровоз. Звонят нашим, так, мол, и так, не можем понять. А наши им — написано же в инструкции «после сборки доработать напильником». Этот анекдот гораздо больше подходит ERP-системам, чем МИГам.

Почему клиенты «живут» с этими проблемами вечно? Авторы исследования утверждают, что причиной тому — незнание настроек, их сложность. Если бы… Представьте себя на месте клиента. Вы точно знаете, что у вас серьезные проблемы с безопасностью. Решить их можно, но для этого следует изучить недра системы. Неужели вы не разберетесь с ними? Но дело не в них. Дело в том, что технологии, воплощенные в ERP-системах, устарели уже на десятилетия.

Почти все разработчики ERP идут одним путем. Выпускается нечто, на что вешается ярлык — «ERP-система». Это нечто и продается клиентам. В реальности это даже не полуфабрикат, а хуже, без «напильника» оно, как правило, работать не способно. А клиентам работать надо, вот они и вынуждены «пилить» и «строгать» эти полуфабрикаты, заставляя их работать. На практике это означает, что в продукты вносятся кардинальные изменения схемы данных и исходных текстов. В результате у каждого клиента работает совершенно индивидуальная версия ПО, в общем случае имеющая мало общего к такому же ПО у других клиентов — хотя называется одинаково. И централизованная поддержка становится совершенно невозможной, потому что производитель абсолютно не контролирует ситуацию у клиентов и не знает, какие именно изменения произведены. Все эти патчи и версии оказываются бесполезными для большинства его клиентов, их установка просто невозможна, ведь у клиентов, по сути, работают совершенно другие продукты. Вот истинная причина проблем с безопасностью. (Да и не только с безопасностью.)

...

Производители очень часто пишут о тиражируемости своих решений. Но, напомню, тиражируемый продукт — это тот, у которого на территории заказчика не меняются ни-че-го. Ни исходные тексты, ни схема данных, ни регламенты обслуживания. Вот Word и Excel — это тиражируемые продукты. Много таких среди ERP-систем?

оригинал http://erp-shik.livejournal.com/12784.html
статья полностью http://pcmag.ru/columns/detail.php?ID=43993
на хабре http://habrahabr.ru/blogs/erp_systems/115015/

=================
обсуждение системы автора на аксфоруме
AVASystems. Еще один игрок.
автор на аксфоруме http://axforum.info/forums/member.php?u=3565

на sql.ru
http://www.sql.ru/forum/actualthread.aspx?tid=802801
http://www.sql.ru/forum/actualthread.aspx?tid=766479

[mazzy]

очень, очень старое на тему тиражируемого и индивидуального, открытых и закрытых программ:
http://subscribe.ru/archive/economic.../04144800.html
http://subscribe.ru/archive/economic.../06144715.html
http://subscribe.ru/archive/economic.../11150014.html
http://subscribe.ru/archive/economic.../19124654.html
http://subscribe.ru/archive/economic.../25154729.html
http://subscribe.ru/archive/economic.../02191903.html
http://subscribe.ru/archive/economic.../04171659.html
http://subscribe.ru/archive/economic.../09181947.html
http://subscribe.ru/archive/economic.../17140308.html
http://subscribe.ru/archive/economic.../24161513.html
http://subscribe.ru/archive/economic.../02191558.html

и так далее
http://subscribe.ru/catalog/economics.book.automation

тема на аксфоруме, где я уже приводил ссылки на эту рассылку Сиголова
Миф о модифицируемости Аксапта, или техническая эстетика.

[Сисой]

Mazzy, ты сабыл вставить самую бравурную часть статьи г-на Попова:

Цитата:

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

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

На поверку эти технологии оборачиваются мелкими размерами заказчиков и относительно небольшим их количеством. По подобной технологии работала масса компаний в 90-е. Каждая из компаний находилась в состоянии равновесия. Небольшое (до 20-30) число заказчиков обеспечивало хлеб с маслом небольшому (3-10 человек) коллективу, который с готовностью реализовывал все вменяемые хотелки заказчиков и распространял свой тиражируемый продукт. Иными словами продукт получается тиражируемым, если все модификации и анализ требований выполняет сам производитель продукта, при этом стоимость, качество и сроки исполнения работ удовлетворяют клиентов.
Может, зря мы загубили всех этих обитателей стендов на выставках 90х? Получив взамен неповоротливых бронтозавров, свысока взирающих на клиентов?

[FE]

mazzy, "спасибо за сладостные мгновения"! Стараюсь следить за творчеством Попова, а тут очередной опус!

[Vadik]

Типичное профессиональное заболевание среди программистов - считать @@@@@кодом любой код кроме своего

[greench]

И свой через пару лет

[kornix]

А если свой код не работает - специально морщиться, закатывать глаза и забывать что он свой

[ice]

Цитата:

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

А если свой код не работает - специально морщиться, закатывать глаза и забывать что он свой

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

[kornix]

Цитата:

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

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

Самый яркий пример когда "правильный" код превращается в @@@@@код:
Вы работали с таблицей, в которой система заполняла поле для вашего алгоритма, ваш алгоритм успешно оттестирован и работает уже много лет. А потом объявляется разработчик, который не знал про то что вы завязаны на это поле (поле нестандартное, стандарт не так часто ломают), и изменяет код заполнения этого поля. Его задача тестируется - переносится на рабочую, а ваш алгоритм превращается в реальную ошибку.
Виноват в такой ситуации не ваш код, он был действительно работающим, тут вы правы. Но бывают и такие "преобразования Фурье"

[pm-erp]

Цитата:

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

Типичное профессиональное заболевание среди программистов - считать @@@@@кодом любой код кроме своего

+1

"Собака лает, караван (SAP, DAx, etc ) - идет" (с) народная мудрость

[Bobkov]

Цитата:

Сообщение от Сисой

Может, зря мы загубили всех этих обитателей стендов на выставках 90х? Получив взамен неповоротливых бронтозавров, свысока взирающих на клиентов?

Так это вы их загубили?? А я наивно думал, что они обанкротились из-за собственной низкой эффективности...

[Мартынов Дмитрий]

Цитата:

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

Вы работали с таблицей, в которой система заполняла поле для вашего алгоритма, ваш алгоритм успешно оттестирован и работает уже много лет. А потом объявляется разработчик, который не знал про то что вы завязаны на это поле (поле нестандартное, стандарт не так часто ломают), и изменяет код заполнения этого поля. Его задача тестируется - переносится на рабочую, а ваш алгоритм превращается в реальную ошибку.
Виноват в такой ситуации не ваш код, он был действительно работающим, тут вы правы. .....

И ведь не докажешь потом - спецификация описывает далеко не все нюансы...

[gl00mie]

Цитата:

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

потом объявляется разработчик, который не знал про то что вы завязаны на это поле (поле нестандартное, стандарт не так часто ломают), и изменяет код заполнения этого поля. Его задача тестируется - переносится на рабочую, а ваш алгоритм превращается в реальную ошибку.
Виноват в такой ситуации не ваш код, он был действительно работающим, тут вы правы. Но бывают и такие "преобразования Фурье"

По-моему, если якобы протестированный код при изменении входных данных перестает работать (и не просекает, что данные некорректны), то такой код просто недостаточно корректно реализован с точки зрения контрактного программирования. Более скользкие случаи - это расширение списка значений enum'ов, которые на самом деле могут стать подставой (как, к примеру, RContractPartnerType, где всю жизнь были лишь клиенты и поставщики, а потом вдруг нарисовался персонал), но строго говоря даже при работе с каким-нить ModuleCustVend надо в switch предусматривать default, где выбрасывать исключение - мол, не знаю, что сделать с новым значением.

[Мартынов Дмитрий]

Цитата:

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

Так это вы их загубили?? А я наивно думал, что они обанкротились из-за собственной низкой эффективности...

Высокая эффективность: это вариант который обозначает, делать некачественно и за дорого... Это типичный парадокс супермаркета: обыватель видит, что цены в обычных лавках выше, чем в супермаркетах и строит причинно-следственную связь. Получается, что если обычные магазины закрыть, то останутся только хорошие....

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

[kuntashov]

Цитата:

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

Виноват в такой ситуации не ваш код,

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

[Мартынов Дмитрий]

Цитата:

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

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

На реальном проекте, даже если тесты были их уже не найдут (давно они были). А если найдут то не разбирутся - разбираться нет времени, да и сложность сравнима со сложностью кода...

К тому же тесты сейчас делают редко - причина проста: код может прекрасно пройти все тесты, но при этом оказаться не пригоден к задаче... Опять к тому, что вопрос написания правильных тестов сравним по сложности с написанием ТЗ и кода... Кто будет писать тесты? Заказчик - он не умеет, затем он и нанял специалиста. А специалист сам себе напишет правильных тестов и сдаст проект, который не работает. Так что главный тест - это работа в реальных условиях, а следовательно описанные выше баги неизбежны...

[kornix]

Цитата:

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

По-моему, если якобы протестированный код при изменении входных данных перестает работать (и не просекает, что данные некорректны), то такой код просто недостаточно корректно реализован с точки зрения контрактного программирования. Более скользкие случаи - это расширение списка значений enum'ов, которые на самом деле могут стать подставой (как, к примеру, RContractPartnerType, где всю жизнь были лишь клиенты и поставщики, а потом вдруг нарисовался персонал), но строго говоря даже при работе с каким-нить ModuleCustVend надо в switch предусматривать default, где выбрасывать исключение - мол, не знаю, что сделать с новым значением.

2 gl00mie: Позволю себе не согласиться с вами. Вы правильно говорите про конструкцию switch с обязательным default и т.д., но я ведь в своем сообщении указал что речь идет не о стандартных объектах. Мой пример касается только сильно кастомизированных приложений, где уже имеется сотни и тысячи нестандартных классов, таблиц и т.п. И далеко не все сделано по BP. Причем нельзя сказать что все разработчики которые это написали "плохие", все дело в том что код может переплывать с версии на версию: 2.5 в 3-ку, потом в 4-ку. При всех стараниях оптимизировать куски - вряд ли получится переписать абсолютно все и сразу.

Цитата:

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

2 kuntashov: Вы делаете регрессионное тестирование каждой модификации? А если приложение опять же сильно кастомизированное, вы сможете сделать тест на всю функциональность? Сколько времени у вас заняло бы тестирование модификации, если бы она попала по каким-то причинам в какой-нибудь родительский класс? Например RunBaseBatch или SalesFormLetter? Вы прогоняете тесты чтобы проверить как работают все потомки? Мне кажется на то и квалификация разработчика, чтобы самостоятельно по перекрестным ссылкам посмотреть что где и как используется, и принять правильное решение куда вклиниваться корректно. Чтобы после его модификации на 1 час не приходилось тестировать весь функционал. Конечно тестирование должно быть, это безусловно, но не регрессионное.

[kuntashov]

Цитата:

К тому же тесты сейчас делают редко

Да.

Цитата:

причина проста: код может прекрасно пройти все тесты, но при этом оказаться не пригоден к задаче..

Возможно, но скорее не поэтому. Мы (я имею в виду нас, разработчиков) не пишем тесты для очередной модификации, потому что:

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

Цитата:

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

Да, по факту так и происходит.

Цитата:

2 kuntashov: Вы делаете регрессионное тестирование каждой модификации?

Нет, не каждой. Только в "особых" случаях и когда затраты на разработку теста оправдаются.

[aidsua]

http://infostart.ru/public/83238/

Цитата:

А теперь о другом. Работая с 1С и сравнивая его с другими системами..
..
Именно по этим параметрам 1С сильно выигрывает у многих систем.

;-)