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

[kornix]

Цитата:

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

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

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

Цитата:

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

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