ERP как залежи говнокода - Курилка

**mazzy** · 10.03.2011, 08:10

Цитата:

Лет десять назад в ходу был анекдот про МИГ-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** · 10.03.2011, 08:31

Сисой · 10.03.2011, 11:57

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

Цитата:

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

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

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

FE · 10.03.2011, 13:30

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

**Vadik** · 10.03.2011, 17:24

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

greench · 10.03.2011, 18:23

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

kornix · 11.03.2011, 09:37

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

ice · 11.03.2011, 09:57

Цитата:

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

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

код не может не работать, ведь он протестирован

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

kornix · 11.03.2011, 11:09

Цитата:

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

код не может не работать, ведь он протестирован

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

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

pm-erp · 11.03.2011, 11:12

Цитата:

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

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

+1

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

Bobkov · 12.03.2011, 17:41

Цитата:

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

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

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

Мартынов Дмитрий · 12.03.2011, 22:43

Цитата:

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

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

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

gl00mie · 12.03.2011, 23:47

Цитата:

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

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

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

Мартынов Дмитрий · 13.03.2011, 10:26

Цитата:

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

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

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

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

kuntashov · 13.03.2011, 11:16

Цитата:

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

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

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

Мартынов Дмитрий · 13.03.2011, 11:47

Цитата:

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

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

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

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

kornix · 13.03.2011, 11:59

Цитата:

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

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

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

Цитата:

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

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

kuntashov · 13.03.2011, 16:32

Цитата:

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

Да.

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

aidsua · 02.04.2011, 19:21

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

Цитата:

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

;-)

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Русский вопрос - разборки по понятиям на рынке ERP (Предпроект)	Мартынов Дмитрий	Курилка	28	16.02.2011 11:56
Отменить ERP-проект означает остановить бизнес	Poleax	Курилка	7	30.12.2010 19:28
ERP-системы — мэйнстрим или тупиковая ветвь?	slava09	Курилка	30	26.09.2010 18:00
О причинах неудачных внедрений ERP	Poleax	Курилка	4	11.09.2010 16:29
ERP Questionnaire	Bojan Jovicic	Курилка	0	12.07.2007 09:40