Технически одит на MVP: какво проверяваме през първите 48 часа

Повечето одити на MVP произвеждат документ. Полезният произвежда решения: какво гори, какво може да чака и колко струва поправката.

Техническият одит на MVP отговаря на един въпрос: може ли тази кодова база да понесе следващите дванадесет месеца от бизнеса, а ако не — какво точно трябва да се промени? Всичко останало — предпочитания за инструменти, спорове за стил, избор на framework — е шум.

Ето чеклиста, който минаваме през първите 48 часа. Подреден е умишлено по цена на грешката: горното може да убие компания, долното струва скорост.

1. Цялост на парите и данните (най-висока цена на отказ)

Ако продуктът движи пари или съхранява регулирани данни, това е първо. Грешките тук не са инциденти — те са задължения. Търсим:

• Дали салдата се извеждат от журнал само за добавяне, или се пазят като променливо число, което кодът може да презапише
• Идемпотентност по всеки платежен път и уебхук — може ли повторена заявка да задължи или кредитира два пъти?
• Използвайте точни десетични или цели минимални единици с валутни правила.
• Транзакционни граници: може ли частичен отказ да остави парите дублирани или никъде
• Равнение: съществува ли процес, който би засякъл разминаване, или ще научите от клиент?

2. Сигурност и контрол на достъпа

• Оторизация, проверявана на сървъра при всяка заявка, или предполагана, защото интерфейсът крие бутона
• Тайни в environment променливи и мениджър на тайни, не в историята на хранилището
• PII и картови данни: какво се съхранява, къде и дали изобщо трябва
• Реално достижими уязвимости в зависимостите, а не просто червено число в отчет
• Multi-tenant изолация: може ли подправена заявка да прочете данни на друг клиент?

3. Архитектура и граници на мащабиране

Не търсим елегантност. Търсим конкретната стена, в която системата ще се удари, и колко далеч е тя.

• Единичните точки на отказ — базата данни, опашката, услугата, до която всички се обръщат
• Заявки, коректни при 1 000 реда и фатални при 1 000 000 (N+1, липсващи индекси, необхванати сканирания)
• Дали може да се разгръща без прекъсване и дали някой изобщо е опитвал
• Свързаност, която пречи да пуснете функция, без да пипнете пет модула
• Дали архитектурата отговаря на размера на екипа — микроуслуги при четирима инженери са проблем за мащабиране, а не решение

4. Доставка и експлоатация

Кодовите бази не се влошават сами; процесът определя колко бързо. Какво измерваме:

5. Технически дълг: приоритизиран, а не изброен

Всяка кодова база има дълг. Списъкът му е безполезен. Значение има разпределението в три кофи:

1. Блокиращ — спира пътната карта или излага на риск пари/данни. Поправя се сега.
2. Натрупващ се — забавя всяка бъдеща промяна. Планира се съзнателно.
3. Козметичен — дразни вкуса, не струва нищо. Оставя се на мира.

Целта на одита не е да намери всичко, което не е наред. Целта е да намери онези няколко неща, достатъчно лоши, че да имат значение, и да бъде точен колко струват.

Какво трябва да получите накрая

• Приоритизиран списък с констатации със степен на важност и бизнес влияние — не каталог
• За всяка констатация: поправката, реалистична оценка на усилието и какво се случва, ако не направите нищо
• Последователна пътна карта: това тримесечие, следващото, по-нататък
• Доказателства — заявката, крайната точка, конкретния ред — за да може екипът ви да провери, а не да вярва

Превърнете първия преглед в проверими задачи

Ограниченият преглед показва покритие, а не липса на всички дефекти. Всяка констатация трябва да може да се провери независимо.

1. Свържете засегнатия път, доказателствата и условията за възпроизвеждане.
2. Разделете наблюдавани дефекти, възможни рискове и недостъпни области.
3. Определете отговорник и регресионен тест за всяка поправка.

• възстановяване на MVP →
• как да поправим MVP →