Вбудувала кодувальник QR на 522 рядки

Ситуація. Документам потрібен був QR‑код із посиланням на онлайн‑версію. Це вміє будь‑яка доступна бібліотека, але взяти одну з них означало б додати третю залежність часу виконання до проєкту, який свідомо обмежився двома — рушієм шаблонів і рендерером PDF, — виходячи з того, що генератор документів має встановлюватися й через багато років.

Завдання. Треба було або погодитися на залежність, або реалізувати формат самостійно, причому довести, що реалізація правильна, а не просто видає щось чорне й квадратне.

Дія. Кодувальник займає 522 рядки й реалізує ті частини специфікації, які справді потрібні для цього завдання: кодування в байтовому режимі, виправлення помилок кодом Ріда — Соломона над полем Галуа з 256 елементів із твірним многочленом потрібного степеня, фіксоване розташування модулів із пошуковими, синхронізувальними й вирівнювальними візерунками, інформацію про формат і версію, а також усі вісім масок даних, кожну з яких оцінюють за чотирма штрафними правилами специфікації, щоб обрати маску з найменшим штрафом, а не завжди ту саму. Саме перевірка зробила це рішення обґрунтованим. Перевірка кодувальника за його ж логікою нічого не доводить, тому готову матрицю модулів зчитує назад декодувальник, написаний незалежно за описаним у специфікації порядком читання, а тест перевіряє, що декодований рядок збігається з вхідним. Так «воно дає правдоподібне зображення» перетворюється на «воно дає код, який декодується в правильну URL‑адресу», і це перевіряють під час кожного прогону, а не один раз на око, телефоном.

Результат. Кількість залежностей часу виконання лишилася на рівні двох, а кодувальник — єдиний вбудований (vendored) компонент у проєкті. Слід прямо сказати, що це не універсальна реалізація: вона підтримує ті режими й версії, які використовують документи, і нічого більше, а чесне обґрунтування рішення — бюджет залежностей, а не якісь заяви, що результат кращий за зрілу бібліотеку.