В пятницу наблюдал замечательное явление: душевные терзания. Все знают, что быдлокодить плохо и все однозначно осуждают быдлокод. Но на самом деле не всё так однозначно и быдллокодить бывает необходимо. Это ставит хорошего программиста перед дилеммой.
Обстановка: есть некий словарь в БД. Сторонний процесс постоянно вносит в этот словарь новые данные, наш демон эти данные перечитывает в свой кэш по команде от стороннего процесса. Но перечитывает не полностью, так как словарь слишком огромный, а только те записи, момент создания которых больше момента последнего обновления кэша. Почему он не определяет новые записи по id? Да хоть бы и по id, ничего от этого не изменится.
Суть проблемы: заказчик запускает другую программу, которая тоже добавляет новые данные в словарь и тоже отправляет команду на обновление кэша демону. И происходит жутко банальный рейс: наш скрипт вставил данные, но ещё не закоммитил, после этого их скрипт вставил, закоммитил и отправил команду на перечитку, после чего наш скрипт наконец закоммитил и тоже отправил команду. Данные, вставленные нашим скриптом не перечитываются, потому что момент создания (или id) слишком старый.
Проблема, в общем-то, и не проблема вовсе. Решается сотней способов, многие из которых очень красивые и элегантные. Но тут есть один момент, который превращает проблему в дилемму: заказчик не может просто так взять и обновиться (нужно демон фиксить), на это нужно пару месяцев потратить, а решение проблемы нужно сейчас. Кроме того, у заказчика стоит устаревшая и формально неподдерживаемая версия демона, в других версиях проблема давно решена.
В общем делать красивое решение для одного заказчика в неподдерживаемой версии, да ещё с таким долгим внедрением — слишком дорого. Самое приемлемое решение — сделать в базе триггер, который будет менять время создания записи на минуту в будущее. Но это некрасивый хак, который усложняет поддержку и отладку в случае других проблем, которые естественным образом могут возникнуть в любой момент.
И вот стоит рядом со мной программист с n-дцатилетним стажем, он знает, что быдлокод — это плохо, и, в отличие от многих анонимных аналитиков, на своей шкуре это испытал неоднократно, и пытается себя заставить пойти и написать одну строчку на SQL. И это ему тяжело. Но надо.
Вот такое бывает в жизни. Всех любителей убивать программистов за пару строчек быдлокода надо заставлять работать в серьёзных проектах, я считаю.
P.S. этот программист с n-дцатилетним стажем не автор этого демона, но сейчас является его разработчиком.
Обстановка: есть некий словарь в БД. Сторонний процесс постоянно вносит в этот словарь новые данные, наш демон эти данные перечитывает в свой кэш по команде от стороннего процесса. Но перечитывает не полностью, так как словарь слишком огромный, а только те записи, момент создания которых больше момента последнего обновления кэша. Почему он не определяет новые записи по id? Да хоть бы и по id, ничего от этого не изменится.
Суть проблемы: заказчик запускает другую программу, которая тоже добавляет новые данные в словарь и тоже отправляет команду на обновление кэша демону. И происходит жутко банальный рейс: наш скрипт вставил данные, но ещё не закоммитил, после этого их скрипт вставил, закоммитил и отправил команду на перечитку, после чего наш скрипт наконец закоммитил и тоже отправил команду. Данные, вставленные нашим скриптом не перечитываются, потому что момент создания (или id) слишком старый.
Проблема, в общем-то, и не проблема вовсе. Решается сотней способов, многие из которых очень красивые и элегантные. Но тут есть один момент, который превращает проблему в дилемму: заказчик не может просто так взять и обновиться (нужно демон фиксить), на это нужно пару месяцев потратить, а решение проблемы нужно сейчас. Кроме того, у заказчика стоит устаревшая и формально неподдерживаемая версия демона, в других версиях проблема давно решена.
В общем делать красивое решение для одного заказчика в неподдерживаемой версии, да ещё с таким долгим внедрением — слишком дорого. Самое приемлемое решение — сделать в базе триггер, который будет менять время создания записи на минуту в будущее. Но это некрасивый хак, который усложняет поддержку и отладку в случае других проблем, которые естественным образом могут возникнуть в любой момент.
И вот стоит рядом со мной программист с n-дцатилетним стажем, он знает, что быдлокод — это плохо, и, в отличие от многих анонимных аналитиков, на своей шкуре это испытал неоднократно, и пытается себя заставить пойти и написать одну строчку на SQL. И это ему тяжело. Но надо.
Вот такое бывает в жизни. Всех любителей убивать программистов за пару строчек быдлокода надо заставлять работать в серьёзных проектах, я считаю.
P.S. этот программист с n-дцатилетним стажем не автор этого демона, но сейчас является его разработчиком.
Комментариев нет:
Отправить комментарий