crower: (Crower)
[personal profile] crower
Пока разбирался с ситуацией обнаружил баг.
Помимо трансферного робота сделал альтернативную схему то ли бекапленья, то ли клонирования. Простенько и надёжно: при формировании ответа на наряд робот генерит файлик с копией записи. Файлик потом отправляем к новой базе где его можно загрузить.
До пересылки дело не дошло. Но сделал и забыл. :)
А когда стал разбираться с предыдущей проблемой обнаружил этот кусок алгоритма и удивился. Заглядываю в файл и в некоторых местах обнаруживаю, что один из параметров у меня потерян.
Озадачился.
Долго искал и не мог понять где засада. А отлаживать и так жутко неудобно. Там код такой и условия его работы своеобразные. Через отладку прогоняю — всё есть. В рабочем режиме вдруг замечаю, что параметр пропадает не всегда. Что за чёрт?
Наконец обнаруживаю.
Назначение параметров у меня происходит не только в основной фазе выполнения нарядов, но и в фазе получения, если наряд был прислан повторно и его не нужно выполнять, а можно выслать хранящуюся в БД информацию. И вот баг был именно в коде этой редко выполняемой части. Более того, до тех пор пока я не решил записи бекапить (где понадобились почти все параметры) это баг сидел и ни на что не влиял.

А поскольку хоббийная деформация, то сразу всплыла ассоциация, что этот код с багом сидел там как «мусорные гены». На самом деле ведь дофига кода в софте может быть в таком спящем режиме. Особенно всякие либы. Тем более в разных ООПах.
This account has disabled anonymous posting.
If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting

Profile

crower: (Default)
crower

February 2018

S M T W T F S
    123
45678910
11121314151617
181920212223 24
25262728   

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 19th, 2025 11:45 pm
Powered by Dreamwidth Studios