Нас спрашивают

[metaclass]

...

>ээээ... а чо, результат программы должен быть вероятностно-правильным?
Конечно. Если программа для 90% целевой аудитории пользователей работает ожидаемо, а от оставшихся 10% требует каких-то дополнительных действий - это лучше, чем от 100% требовать дополнительных действий.


Это к вопросу о стандартах. Конечно, хорошо писать программы для идеального мира, где стандарты соблюдены, кодировки все UTF, пользователи все знают что нужно читать маны и гугл, а компьютеры не глючат и TCP соединения работают корректно.

Но на практике - практически гарантированно, что хоть что-нибудь но будет сделано неправильно, или не будет работать, как нужно. Поэтому софт должен допускать некоторые вариации входных данных, и или обрабатывать их корректно, или как минимум, ругаться понятными словами (а не виснуть, как audacious на cue-файлах).

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

Comments

[metaclass.livejournal.com]

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

[guamoka.livejournal.com]

Ненавижу такую херню еще по первой работе. Там тоже был мрак и гоморра. Парсинг выходных данных одной подсистемы- это был один сплошной ад-хок с каждым встреченным граничным случаем и вторыми производными. А данные всего-то были простым геометрическим описанием контуров:-)

[jarud-bra0n.livejournal.com]

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

[metaclass.livejournal.com]

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

А моя система (сводные отчеты) работает одновременно и с первым и со вторым экземляром, доступа на запись в них нету, менять данные в них нельзя. И большей ее части пофиг, какое там распределение сумм по кодам. Кроме одного модуля, который если делать как тут рекомендуют (рассчитывать на идеальные входные данные) - никогда в жизни бы не показал бухгалтерии нужных сумм. И "преобразовать входные данные к стандарту" можно только: а) по результатам работы этого модуля б) только на его входе, и больше нигде. Вот это и есть алгоритм подгонки результата - он считает сначала по тем данным которые есть(с минимумом ограничений), затем проходится по результату и смотрит "а нельзя ли тут подправить" по критериям типа "суммы и счета совпадают", создает список исправлений и повторяет свою работу второй раз. И вот только то. что второй раз не исправилось - показывается пользователям на предмет чтобы они исправляли первичные данные в старой системе.

[jarud-bra0n.livejournal.com]

зачем звонить? какое "одно-другое"? слой-преобразователь должен быть во всех версиях.
я не против того, чтобы "чуть-чуть" неправильные входные данные корректировать. я против того, чтобы если по стандарту дебет должен быть равен кредиту (или чему-то там), то ломать этот стандарт из-за прихоти единственного юзера ("хачу штоб у меня не сходился а ошибок не было!") - нельзя.