Защо целият ви бизнес може да се крие в кода, който смятате за „легаси"

Ето нещо, което би трябвало да накара всеки CTO и водещ developer да се почувства неловко: най-дълбокото разбиране за бизнеса ви може да съществува единствено в production кодa.

Наскоро излезе research paper от екипа на ServiceMatch, който разглежда провокативна идея. Те твърдят, че зрелите софтуерни системи не са просто инструменти, които въртят бизнеса ви — те са изпълними представи на всичко, което организацията ви е научила за този бизнес. Трудната част? Тази знание се е криело на видно място, заключено в repository-та, които доскоро бяха четени само от compilers и (от време на време) хора.

Митът за документацията

Всички сме били там. Нов engineer се присъединява към екипа и получава стена от Confluence страници, ADR записи и Wiki статии. „Това ще те запознае с нещата", казва някой с оптимистична сигурност.

Няма да стане.

Документацията улавя това, което някой е сметнал за важно да запише, в момент във времето, който може да е бил преди години. Тя пропуска edge cases-ите. Пропуска аргументите, водени на срещи, които са оформили решенията. Пропуска бизнес логиката, еволюирала през хиляди commits, всеки от тях борещ се с реален сценарий от практиката.

Според аргумента на Peter Naur от 1985 г. (да, същият Naur, който ни даде Backus-Naur формата), програмната документация никога не може да улови напълно „теорията" зад една система. Истинското разбиране живее в главите на хората. Когато тези хора си тръгнат, теорията си тръгва с тях.

Но ето къде става интересно.

AI променя проблема с читателите

Аргументът на Naur беше за два типа читатели: compilers (които изпълняват код без да го разбират) и хора (които го разбират бавно и скъпо). Невъзможността на документалното възраждане предполагаше, че не съществува друг вид читател.

Големите езикови модели са трети тип читател. И са изненадващо добри в реконструирането на имплицитните теории, вградени в кода.

Системата на ServiceMatch дава убедителни доказателства. Тяхната CMDB платформа кодира знание за enterprise конфигурационен мениджмънт, което би запълнило томове, ако беше написано като проза. Но ето Working — то вече е написано, просто не като проза. Е го в код.

Разгледайте тяхната identity resolution логика. Вместо есе на консултант за „как работи device identity", те имат конфигурационен файл с тегла: сериен номер (25), hostname (25), asset tag (25), IP адрес (20), MAC адрес (15). Плюс confidence thresholds и правила за разрешаване на конфликти. Всяко число представлява аргумент, който някой е спечелил. Всеки тип конфликт представлява реален incident, случил се някъде.

Това не е описание на политиката. Това Е политиката, която се изпълнява всяка нощ срещу реални enterprise среди.

Какво означава това за екипа ви

За разработчиците и техническите лидери, това проучване има практически последици:

Кодът ви е документация, която не сте поддържали — и това си има своите предимства. За разлика от остарели wiki страници, кодът, който се изпълнява в production, е постоянно валидиран. Ако документацията не е съгласна с кода, грешката е в документацията.

AI инструментите стават все по-добри в извличането на това знание. Движим се към свят, в който питане на AI за „как се справяме с конфликти за device identity" може да върне не просто документация, а действителните разсъждения, кодирани в теглата и thresholds-ите.

Истинското знание се крие в edge cases-ите. Main flows-овете обикновено са добре документирани. Това са special handling-ът, изключенията, corner cases-ите, решени през години, които съдържат дълбокото институционално знание.

Предупредителният знак

Има неудобна последица от всичко това: ако бизнес логиката ви е само в кода ви, а кодът ви има лошо test coverage, неясни имена или хаотична структура, вие седите на купчина знание, което е почти невъзможно да се извлече.

Екипът на ServiceMatch установи, че тяхното твърдение — че „repository-то е достатъчно" — се разпада по предвидим начин. Naur-овият tacit residue е реален. Някакво знание наистина съществува само в главите на хората.

Но по-силната находка е, че повече оцелява в кода, отколкото смятахме за възможно. Repository-то улавя далеч повече теория, отколкото документацията някога би могла — просто ни трябваше нов вид читател, за да я извлечем.

Какво да правите с това

Ако сте startup или растяща tech компания, ето рамка за мислене по темата:

1. Вярвайте на кода си повече от документите когато двете не са съгласни
2. Пишете код, който документира разсъжденията си — смислени имена на променливи, ясни функции, коментари, които обясняват ЗАЩО, не само КАКВО
3. Отнасяйте се към конфигурацията като към институционално знание — тези тегла и thresholds са решения, които си струва да бъдат запазени
4. Започнете да изследвате AI инструменти, които могат да интервюират codebase-а ви като източник на знание

Кодът, който пишете днес, е утрешното институционално знание. Направете го да се брои.