AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.03.2011, 08:10   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
ERP как залежи говнокода
Цитата:
Лет десять назад в ходу был анекдот про МИГ-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
__________________
полезное на axForum, github, vk, coub.
Старый 10.03.2011, 08:31   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
очень, очень старое на тему тиражируемого и индивидуального, открытых и закрытых программ:
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

тема на аксфоруме, где я уже приводил ссылки на эту рассылку Сиголова
Миф о модифицируемости Аксапта, или техническая эстетика.
__________________
полезное на axForum, github, vk, coub.
Старый 10.03.2011, 11:57   #3  
Сисой is offline
Сисой
Участник
Аватар для Сисой
Злыдни
1C
 
938 / 339 (13) ++++++
Регистрация: 05.02.2003
Адрес: Москва
Mazzy, ты сабыл вставить самую бравурную часть статьи г-на Попова:
Цитата:
Защитники отсталых технологий могут стандартно заявить, мол, «все компании разные, у всех разные бизнес-процессы», поэтому избежать серьезного изменения кодов и схем данных не удастся.

Отвечаю. Я бы не счел себя вправе написать эту колонку, если бы не реализовал тиражируемые технологии у себя в компании.
На поверку эти технологии оборачиваются мелкими размерами заказчиков и относительно небольшим их количеством. По подобной технологии работала масса компаний в 90-е. Каждая из компаний находилась в состоянии равновесия. Небольшое (до 20-30) число заказчиков обеспечивало хлеб с маслом небольшому (3-10 человек) коллективу, который с готовностью реализовывал все вменяемые хотелки заказчиков и распространял свой тиражируемый продукт. Иными словами продукт получается тиражируемым, если все модификации и анализ требований выполняет сам производитель продукта, при этом стоимость, качество и сроки исполнения работ удовлетворяют клиентов.
Может, зря мы загубили всех этих обитателей стендов на выставках 90х? Получив взамен неповоротливых бронтозавров, свысока взирающих на клиентов?
За это сообщение автора поблагодарили: pm-erp (1).
Старый 10.03.2011, 13:30   #4  
FE is offline
FE
Участник
 
224 / 58 (2) ++++
Регистрация: 28.07.2005
Адрес: Петербург
mazzy, "спасибо за сладостные мгновения"! Стараюсь следить за творчеством Попова, а тут очередной опус!
Старый 10.03.2011, 17:24   #5  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Типичное профессиональное заболевание среди программистов - считать @@@@@кодом любой код кроме своего
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: mazzy (2), kornix (1).
Старый 10.03.2011, 18:23   #6  
greench is offline
greench
Участник
Oracle
 
425 / 74 (3) ++++
Регистрация: 12.07.2007
Адрес: Киев
И свой через пару лет
За это сообщение автора поблагодарили: mazzy (2), AlGol (2), player (1).
Старый 11.03.2011, 09:37   #7  
kornix is offline
kornix
MCP
MCBMSS
Злыдни
Ex AND Project
 
414 / 146 (5) +++++
Регистрация: 24.02.2009
Адрес: Санкт-Петербург
А если свой код не работает - специально морщиться, закатывать глаза и забывать что он свой
Старый 11.03.2011, 09:57   #8  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,731 / 406 (17) +++++++
Регистрация: 23.03.2006
Цитата:
Сообщение от kornix Посмотреть сообщение
А если свой код не работает - специально морщиться, закатывать глаза и забывать что он свой
код не может не работать, ведь он протестирован, а вот входные параметры могут поменяться, и стать такими на которые алгоритм не расчитан, т.е. налицо неверное использование
Старый 11.03.2011, 11:09   #9  
kornix is offline
kornix
MCP
MCBMSS
Злыдни
Ex AND Project
 
414 / 146 (5) +++++
Регистрация: 24.02.2009
Адрес: Санкт-Петербург
Цитата:
Сообщение от ice Посмотреть сообщение
код не может не работать, ведь он протестирован, а вот входные параметры могут поменяться, и стать такими на которые алгоритм не расчитан, т.е. налицо неверное использование
Самый яркий пример когда "правильный" код превращается в @@@@@код:
Вы работали с таблицей, в которой система заполняла поле для вашего алгоритма, ваш алгоритм успешно оттестирован и работает уже много лет. А потом объявляется разработчик, который не знал про то что вы завязаны на это поле (поле нестандартное, стандарт не так часто ломают), и изменяет код заполнения этого поля. Его задача тестируется - переносится на рабочую, а ваш алгоритм превращается в реальную ошибку.
Виноват в такой ситуации не ваш код, он был действительно работающим, тут вы правы. Но бывают и такие "преобразования Фурье"

Последний раз редактировалось kornix; 11.03.2011 в 11:11.
Старый 11.03.2011, 11:12   #10  
pm-erp is offline
pm-erp
Участник
 
200 / 22 (1) +++
Регистрация: 28.10.2009
Адрес: Москва
Цитата:
Сообщение от Vadik Посмотреть сообщение
Типичное профессиональное заболевание среди программистов - считать @@@@@кодом любой код кроме своего
+1

"Собака лает, караван (SAP, DAx, etc ) - идет" (с) народная мудрость
Старый 12.03.2011, 17:41   #11  
Bobkov is offline
Bobkov
Участник
Аватар для Bobkov
 
238 / 299 (10) ++++++
Регистрация: 30.10.2002
Адрес: München
Цитата:
Сообщение от Сисой Посмотреть сообщение
Может, зря мы загубили всех этих обитателей стендов на выставках 90х? Получив взамен неповоротливых бронтозавров, свысока взирающих на клиентов?
Так это вы их загубили?? А я наивно думал, что они обанкротились из-за собственной низкой эффективности...
Старый 12.03.2011, 22:43   #12  
Мартынов Дмитрий is offline
Мартынов Дмитрий
Участник
 
236 / 66 (3) ++++
Регистрация: 02.02.2004
Адрес: г. Москва
Цитата:
Сообщение от kornix Посмотреть сообщение
Вы работали с таблицей, в которой система заполняла поле для вашего алгоритма, ваш алгоритм успешно оттестирован и работает уже много лет. А потом объявляется разработчик, который не знал про то что вы завязаны на это поле (поле нестандартное, стандарт не так часто ломают), и изменяет код заполнения этого поля. Его задача тестируется - переносится на рабочую, а ваш алгоритм превращается в реальную ошибку.
Виноват в такой ситуации не ваш код, он был действительно работающим, тут вы правы. .....
И ведь не докажешь потом - спецификация описывает далеко не все нюансы...

Последний раз редактировалось Мартынов Дмитрий; 12.03.2011 в 22:44. Причина: ино
Старый 12.03.2011, 23:47   #13  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от kornix Посмотреть сообщение
потом объявляется разработчик, который не знал про то что вы завязаны на это поле (поле нестандартное, стандарт не так часто ломают), и изменяет код заполнения этого поля. Его задача тестируется - переносится на рабочую, а ваш алгоритм превращается в реальную ошибку.
Виноват в такой ситуации не ваш код, он был действительно работающим, тут вы правы. Но бывают и такие "преобразования Фурье"
По-моему, если якобы протестированный код при изменении входных данных перестает работать (и не просекает, что данные некорректны), то такой код просто недостаточно корректно реализован с точки зрения контрактного программирования. Более скользкие случаи - это расширение списка значений enum'ов, которые на самом деле могут стать подставой (как, к примеру, RContractPartnerType, где всю жизнь были лишь клиенты и поставщики, а потом вдруг нарисовался персонал), но строго говоря даже при работе с каким-нить ModuleCustVend надо в switch предусматривать default, где выбрасывать исключение - мол, не знаю, что сделать с новым значением.
Старый 13.03.2011, 10:26   #14  
Мартынов Дмитрий is offline
Мартынов Дмитрий
Участник
 
236 / 66 (3) ++++
Регистрация: 02.02.2004
Адрес: г. Москва
! Об эффективных менеджерах
Цитата:
Сообщение от Bobkov Посмотреть сообщение
Так это вы их загубили?? А я наивно думал, что они обанкротились из-за собственной низкой эффективности...
Высокая эффективность: это вариант который обозначает, делать некачественно и за дорого... Это типичный парадокс супермаркета: обыватель видит, что цены в обычных лавках выше, чем в супермаркетах и строит причинно-следственную связь. Получается, что если обычные магазины закрыть, то останутся только хорошие....

Не исключено, что именно такое обывательское рассуждение подхваченное опытными маркетологами и загубило рынок 90х
Старый 13.03.2011, 11:16   #15  
kuntashov is offline
kuntashov
Участник
Аватар для kuntashov
1C
 
33 / 34 (2) +++
Регистрация: 07.12.2007
Цитата:
Сообщение от kornix Посмотреть сообщение
Виноват в такой ситуации не ваш код,
а его незащищенность от подобных изменений, а именно: отсутствие регрессионнных тестов, проверяющих функциональность данного кода.
__________________
С уважением,
Александр Кунташов
Старый 13.03.2011, 11:47   #16  
Мартынов Дмитрий is offline
Мартынов Дмитрий
Участник
 
236 / 66 (3) ++++
Регистрация: 02.02.2004
Адрес: г. Москва
Цитата:
Сообщение от kuntashov Посмотреть сообщение
а его незащищенность от подобных изменений, а именно: отсутствие регрессионнных тестов, проверяющих функциональность данного кода.
На реальном проекте, даже если тесты были их уже не найдут (давно они были). А если найдут то не разбирутся - разбираться нет времени, да и сложность сравнима со сложностью кода...

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

Последний раз редактировалось Мартынов Дмитрий; 13.03.2011 в 11:52. Причина: дополнил
За это сообщение автора поблагодарили: kornix (1).
Старый 13.03.2011, 11:59   #17  
kornix is offline
kornix
MCP
MCBMSS
Злыдни
Ex AND Project
 
414 / 146 (5) +++++
Регистрация: 24.02.2009
Адрес: Санкт-Петербург
Цитата:
Сообщение от gl00mie Посмотреть сообщение
По-моему, если якобы протестированный код при изменении входных данных перестает работать (и не просекает, что данные некорректны), то такой код просто недостаточно корректно реализован с точки зрения контрактного программирования. Более скользкие случаи - это расширение списка значений enum'ов, которые на самом деле могут стать подставой (как, к примеру, RContractPartnerType, где всю жизнь были лишь клиенты и поставщики, а потом вдруг нарисовался персонал), но строго говоря даже при работе с каким-нить ModuleCustVend надо в switch предусматривать default, где выбрасывать исключение - мол, не знаю, что сделать с новым значением.
2 gl00mie: Позволю себе не согласиться с вами. Вы правильно говорите про конструкцию switch с обязательным default и т.д., но я ведь в своем сообщении указал что речь идет не о стандартных объектах. Мой пример касается только сильно кастомизированных приложений, где уже имеется сотни и тысячи нестандартных классов, таблиц и т.п. И далеко не все сделано по BP. Причем нельзя сказать что все разработчики которые это написали "плохие", все дело в том что код может переплывать с версии на версию: 2.5 в 3-ку, потом в 4-ку. При всех стараниях оптимизировать куски - вряд ли получится переписать абсолютно все и сразу.

Цитата:
а его незащищенность от подобных изменений, а именно: отсутствие регрессионнных тестов, проверяющих функциональность данного кода.
2 kuntashov: Вы делаете регрессионное тестирование каждой модификации? А если приложение опять же сильно кастомизированное, вы сможете сделать тест на всю функциональность? Сколько времени у вас заняло бы тестирование модификации, если бы она попала по каким-то причинам в какой-нибудь родительский класс? Например RunBaseBatch или SalesFormLetter? Вы прогоняете тесты чтобы проверить как работают все потомки? Мне кажется на то и квалификация разработчика, чтобы самостоятельно по перекрестным ссылкам посмотреть что где и как используется, и принять правильное решение куда вклиниваться корректно. Чтобы после его модификации на 1 час не приходилось тестировать весь функционал. Конечно тестирование должно быть, это безусловно, но не регрессионное.
Старый 13.03.2011, 16:32   #18  
kuntashov is offline
kuntashov
Участник
Аватар для kuntashov
1C
 
33 / 34 (2) +++
Регистрация: 07.12.2007
Цитата:
К тому же тесты сейчас делают редко
Да.

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

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

Цитата:
2 kuntashov: Вы делаете регрессионное тестирование каждой модификации?
Нет, не каждой. Только в "особых" случаях и когда затраты на разработку теста оправдаются.
__________________
С уважением,
Александр Кунташов
Старый 02.04.2011, 19:21   #19  
aidsua is offline
aidsua
AX*****
Аватар для aidsua
 
106 / 40 (2) +++
Регистрация: 28.09.2005
Адрес: 2:463/Kyiv
http://infostart.ru/public/83238/
Цитата:
А теперь о другом. Работая с 1С и сравнивая его с другими системами..
..
Именно по этим параметрам 1С сильно выигрывает у многих систем.
;-)
__________________
О, как беден, как груб наш русский язык! [c] А.С.Пушкин
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Русский вопрос - разборки по понятиям на рынке 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

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 11:39.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.