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

[ice]

Цитата:

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

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

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

[kornix]

Цитата:

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

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

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

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

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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

[kornix]

Цитата:

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

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

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

Цитата:

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

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

[kuntashov]

Цитата:

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

Да.

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

[kuntashov]

Цитата:

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

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

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

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

Цитата:

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

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

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

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