Технічний аудит Odoo-проєкту: що перевіряти і як читати висновок

Ситуація, яку я бачу найчастіше: систему впроваджував хтось інший, той підрядник більше не на звʼязку, і Odoo «начебто працює» — але кожна нова задача коштує дорожче за попередню, звіти не сходяться, а частина даних просто не доходить. Технічний аудит Odoo-проєкту відповідає на одне питання: розвивати чи переписувати і скільки це коштуватиме.

Коли потрібен технічний аудит Odoo

Не за розкладом, а за симптомами. Найчастіші:

• будь-яка дрібна зміна займає дні замість годин, і розробник не може пояснити чому;
• після оновлення або нового модуля ламається щось зовсім не повʼязане;
• дані в Odoo не збігаються з CRM, банком або касою — і ніхто не може сказати, скільки записів загубилося;
• система відчутно гальмує, хоча сервер «потужний»;
• ви змінюєте підрядника й хочете розуміти, що саме передаєте;
• проєкт робили швидко й дешево, зокрема активно з ШІ, і ніхто не знає, що там усередині.

Конектори на хуках: чому синхронізація «майже працює»

Це найдорожча знахідка, бо вона не падає з помилкою — вона мовчить.

Типова реалізація виглядає так: розробник вішає обробник на подію create або write і вважає, що тепер усі дані потрапляють у зовнішню систему. Насправді хук спрацьовує не на кожен спосіб зміни даних : пакетні операції та масові записи, імпорт із файлів, зміни через стандартні майстри, дії, викликані іншими модулями, крони, зміни через API, а іноді й сирий SQL, що лишився від давніх міграцій, — усе це проходить повз.

Наслідок: конектор не гарантує повноти даних . Розрив накопичується тихо, помічають його за квартал під час звірки, і дорога частина — не полагодити конектор, а відновити пропущений період.

Правильна архітектура тут інша: не «зловити подію», а гарантувати повноту — черга подій із власним станом, планова звірка залишків, контрольний підрахунок документів за період і можливість переграти будь-який інтервал без створення дублів. Перевірка цього — обовʼязковий пункт аудиту.

Код без архітектурного планування — і чому ШІ цього не помʼякшує

Окрема категорія свіжих проєктів: код, написаний швидко, активно з ШІ, але без архітектурного планування . Симптоми впізнавані:

• дубльований код — той самий фрагмент розкиданий по кількох модулях, тож виправлення в одному місці ніколи не доходить до інших;
• кілька різних методів, які роблять те саме — кожен написаний окремо під конкретну задачу, і тепер ніхто не знає, який із них «правильний»;
• мертвий код — поля, методи й цілі моделі, яких ніхто не викликає, але які все одно виконуються, ламаються й потребують міграції при оновленні;
• логіка, несумісна з тим, як працює Odoo — обхід ORM, ігнорування станів документів, саморобний розрахунок замість вбудованої механіки обліку та оцінки;
• логіка, несумісна із самим бізнес-процесом — код робить те, чого в реальності просто не буває, і тримається лише тому, що користувачі ще не натиснули не ту кнопку.

Варто поставити наголос там, де треба: ШІ — це інструмент. Потужний, але інструмент. Проблема не в інструменті, а в тому, що згенерований код прийняли без архітектурного рішення й без рецензії людини, яка знає Odoo. Програмувати з ШІ має програміст — тоді результат нормальний. Як перевірити це ще на етапі вибору підрядника — окремо: як обрати виконавця для впровадження Odoo.

Як виглядає процес, коли ШІ використовують без таких наслідків: як програмувати з ШІ і чому тести стали важливішими за швидкість.

Що саме перевіряється

Аудит ділиться на пʼять блоків — і найдорожчі знахідки майже ніколи не в коді, а в обліку.

1. Архітектура та якість коду

Структура модулів і залежності, дотримання механіки Odoo (ORM, успадкування, стани документів), дубльований і мертвий код, кастомізації поза модулями, покриття тестами, історія git. Окремо — Studio на Community і налаштування, які існують лише в базі й зникають, щойно ви переїжджаєте на інший сервер.

2. Інтеграції

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

3. Дані та облік

Саме цей блок зазвичай визначає вартість ремонту: коректність оцінки запасів і собівартості, сальдо на проміжних рахунках, незіставлені платежі, розбіжності між складом і обліком, дублі контрагентів і товарів, наслідки попередніх міграцій.

4. Продуктивність

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

5. Інфраструктура та процес

Хостинг і резервні копії (а головне — чи їх бодай раз відновлювали), розділення продакшену й staging, як відбувається деплой, права доступу, оновлення версій, залежність від однієї людини.

Що ви отримуєте на виході

Не «все погано, давайте перепишемо», а документ, з яким можна ухвалювати рішення:

• перелік знахідок із рівнем критичності — що зламано вже зараз, що зламається на наступному оновленні, а що просто негарне;
• для кожної знахідки — наслідок для бізнесу, а не лише технічний опис;
• оцінка у годинах на виправлення, розбита на етапи;
• рекомендація по кожному блоку: лишити, розвивати чи переписати;
• окремо — що треба зробити негайно : зазвичай це резервні копії, права доступу і втрата даних в інтеграціях.

Скільки триває і скільки коштує

Для типового проєкту малого чи середнього бізнесу — від кількох днів до тижня, залежно від кількості кастомних модулів та інтеграцій. Працюю погодинно (T&M) , з попередньо погодженим обсягом: спершу швидкий огляд, щоб оцінити роботу, потім детальний розбір.

Що мені потрібно від вас: доступ до бази (копії достатньо) і до репозиторію з кастомними модулями. Якщо репозиторію немає — це вже перша знахідка аудиту.

Аудит окупається найпростішим чином: він майже завжди дешевший за один місяць роботи команди в системі, якій вона не довіряє.

Що далі

Після аудиту є три можливі шляхи: ви віддаєте звіт своїй команді й вона виправляє; я беру на супровід окремі блоки; або ми робимо контрольований перехід до нормальної архітектури, не зупиняючи бізнес.

Повний перелік того, що я роблю в Odoo, — у розділі Послуги Odoo . Послуги та ціни — у розділі Магазин .

Часті питання

Чи можна провести аудит без доступу до бази?

Частково — лише по коду. Але найдорожчі знахідки зазвичай у даних, тож без бази картина лишається неповною.

Чи передасте звіт нашому власному розробнику?

Так. Документ ваш, і працювати за ним може будь-хто. Аудит не зобовʼязує замовляти виправлення в мене.

Чи потрібен аудит, якщо система працює нормально?

Перед великими змінами — оновленням версії, зміною підрядника, новою інтеграцією — так. Дешевше дізнатися про проблеми до, а не під час.

А якщо виявиться, що все треба переписувати?

Таке буває рідко. Частіше переписати треба один-два модулі, а решта лікується точковими виправленнями.