A technikai átvilágítás nem kódminőségi verseny, és az erre készülő csapatok általában rossz helyre teszik az energiájukat. Aki céget vásárol, nem az absztrakcióidat osztályozza. A vevő azt próbálja kiszámolni, mennyibe fog kerülni ennek a rendszernek a birtoklása, és mekkora bajt okozhat azután, hogy a pénz gazdát cserél.

Ez az átkeretezés azért számít, mert megváltoztatja, mit érdemes először rendbe tenni. A csúnya kód, ami működik, amit a csapat ért, és amit biztonságosan lehet módosítani, csak kisebb megállapítás. Az elegáns kód, amit egyetlen ember ért, komoly megállapítás, és a második az, ami elmozdítja az árat.

A kérdés minden kérdés mögött: ha az alapító fejlesztő a zárás utáni héten felmond, ez a rendszer akkor is fut tovább, és akkor is változtatható marad? Szinte minden megállapítás, ami lenyomja az ajánlatot, erre ad konkrét választ. Egyetlen fejben összesűrűsödött tudás, dokumentálatlan telepítés, licencek, amelyeket soha senki nem ellenőrzött, hozzáférési kulcsok, amelyek csak egy ember emlékezetében léteznek.

Mit mér valójában a technikai átvilágítás

Négy kockázat, nagyjából abban a sorrendben, ahogyan az értékelésre hatnak.

Kulcsemberkockázat. Az, hogy a rendszer emberekhez kötődik-e ahelyett, hogy dokumentált folyamatokon állna. Ez következetesen a legkárosabb megállapítás, mert utólag ezt a legnehezebb orvosolni, és mert közvetlenül azt fenyegeti, amit meg akarnak venni.

A folytatás költsége. Mi kell ahhoz, hogy a rendszer működjön és fejlődjön tovább: infrastruktúrára fordított kiadás, licenckötelezettségek, a szükséges csapat mérete, és az, hogy a termékterv mekkora részét eszi meg a karbantartás új munka helyett.

Felelősség. A kereskedelmi felhasználással ütköző licencek, olyan módon kezelt személyes adatok, amelyek egy panaszt nem élnének túl, biztonsági kitettség, és minden olyan hatósági kötelezettség, amelynek a cég valójában nem tesz eleget.

A változtathatóság. Az, hogy az új funkciók kiszámítható ütemben szállíthatók-e, vagy minden módosítás magában hordozza a kockázatot, hogy valami tőle független dolog törik el.

A kódminőség csak ezen a negyedik ponton keresztül számít, és éppen ezért az átvilágító kevesebb időt tölt a kódod olvasásával, mint az alapítók várnák, és sokkal többet azzal, hogy megkérdezi, hogyan zajlik nálatok egy telepítés.

A megállapítások, amelyek lenyomják az árat

Egyetlen emberen kívül senki nem tud telepíteni. Az a kiadási folyamat, amely valakinek a fejében vagy a laptopján él, komoly működési kockázatnak számít, függetlenül attól, hogy ma milyen jól működik.

Nincs teszt a fontos útvonalakon. Nem a lefedettségi százalékról van szó, azt az átvilágítók jórészt figyelmen kívül hagyják, hanem arról, hogy a rendszer egyáltalán módosítható-e bármiféle magabiztossággal. Az a kódbázis, amelyben a bevételt hozó útvonal körül nincs teszt, lassabb terméktervet áraztat be. A szoftvertesztelési stratégiákról szóló útmutatónk végigveszi, mi az, ami tényleg megéri a helyét.

Licencfertőzés. A szabadalmaztatott, zárt termékbe került copyleft kód azon kevés megállapítás egyike, amely nem csupán újraárazza, hanem meg is állíthatja a tranzakciót, és általában percek alatt megtalálja egy szkennelő eszköz.

Személyes adat védhető alap nélkül. Világos jogalap nélkül gyűjtött, határidő nélkül megőrzött vagy olyan helyen tárolt adat, amelyet a cég fel sem tud sorolni. A GDPR technikai megfelelésének mechanizmusai pontosan ugyanazok, amelyeket az átvilágító ellenőriz.

Dokumentálatlan függés emberektől vagy szállítóktól. Egy kritikus integráció olyan beszállítóval, akivel nincs szerződés, vagy magánszámlán futó infrastruktúra: mindkettő kezeletlen kockázatnak látszik.

Hiányoznak a biztonsági alapok. Nem a behatolásvizsgálat eredményéről van szó, hanem arról, hogy a titkok bekerültek-e a verziókezelőbe, visszavonjátok-e a hozzáférést, amikor valaki távozik, és van-e most is olyan javítatlan rendszer, amely az internet felől elérhető.

Ami nem érdekli az átvilágítót

Ezt érdemes kimondani, mert a felkészülésre szánt idő kevés, és jellemzően rosszul költik el.

Nem érdekli őket, melyik keretrendszert választottad, amíg lehet rá embert felvenni. Nem érdekli őket az architekturális divat: egy monolit, amely szállít, nem megállapítás. Nem érdekli őket a kódstílus, az elnevezések vagy annak hiánya, hogy valaki az interneten ajánl egy mintát.

Nulla technikai adósságot sem várnak. Minden cégnek van, és a puszta létezése természetes. Az számít, hogy a csapat tudja-e, hol van, és el tudja-e mondani, mibe kerül. Az a csapat, amelyik világos listát tesz le a saját ismert problémáiról, hozzáértőnek látszik. Az, amelyik azt állítja, hogy nincsenek ilyenek, tájékozatlannak, és az átvilágítónak ilyenkor egyedül kell megtalálnia őket, ami tovább tart, és rosszabb jelentést eredményez.

Felkészülés úgy, hogy semmit nem írsz újra

Ami segít, annak nagy része napokban mérhető, nem hónapokban, és semmi nem nyúl hozzá az architektúrához.

Írd le, hogyan kell telepíteni. Egy üres géptől a működő rendszerig. Ez az egyetlen dokumentum a legkárosabb megállapítás-kategóriát kezeli, és egy délután alatt megírható.

Vedd számba a függőségeket és a licenceiket. Automatizált eszközök ezt gyorsan előállítják, és sokkal többet ér a válasz ismerete az átvilágító előtt, mint maga a tiszta eredmény.

Szedd ki a titkokat a verziókezelőből, és leltározd fel, kinek mihez van hozzáférése. Utána vond vissza a hozzáférést mindenkitől, aki már elment.

Dokumentáld, amiről tudod, hogy hibás. Rövid, őszinte nyilvántartás az ismert problémákról, hozzávetőleges javítási költséggel. Ennek önkéntes átadása azon kevés dolog egyike, amely megbízhatóan javítja egy vizsgálat hangvételét.

Gondoskodj róla, hogy az infrastruktúra a cégé legyen, ne egy magánszámláé, és hogy a domainek, a tanúsítványok és a kódtárak mind vállalati kézben legyenek.

Mi lesz a megállapítások sorsa

Ritkán ölnek meg egy üzletet. Feltételekké válnak.

A megállapítások jellemzően három kimenetel egyikébe futnak: árkiigazítás, amely a javítás költségét tükrözi, szavatossági vállalás vagy kártalanítási kikötés a szerződésben, illetve a zárás előtt teljesítendő feltétel. Csak a licencfertőzés és a súlyos, kezeletlen adatvédelmi kitettség állítja meg rendszeresen és véglegesen a tranzakciókat.

Vagyis a gyakorlati cél nem a tökéletes rendszer. Olyan rendszer, amelynek a problémái ismertek, körülhatároltak és leírhatók, mert a számszerűsített problémát beárazzák, a számszerűsítetlenről pedig azt feltételezik, hogy rosszabb a valóságosnál.

A Mecanik ilyen technikai vizsgálatokat a szoftverfejlesztési munkánk részeként végez, jellemzően a vevő oldaláról. A minta stabil: azok a rendszerek szerepelnek jól egy vizsgálaton, amelyek nem a kifinomultak, hanem amelyekben valaki leírta a dolgokat.

Kapcsolódó olvasnivaló: Szoftver escrow: kinek van rá tényleg szüksége , Fintech szoftverfejlesztés az Egyesült Királyságban: FCA, rails és költségek , Fix áras szerződés vagy elszámolásos munka? és Egyedi szoftverfejlesztés az Egyesült Királyságban: a teljes vevői útmutató .

Gyakran ismételt kérdések

Mi az a technikai átvilágítás? Annak felmérése, mennyibe fog kerülni egy szoftverrendszer birtoklása, és mekkora bajt okozhat egy felvásárlás vagy befektetés után. A kulcsemberkockázatot, a folytatás költségét, a jogi felelősséget és a rendszer további változtathatóságát vizsgálja, nem pedig a kódminőséget önmagáért osztályozza.

Mely megállapítások nyomják le leginkább az árat? A tudás néhány emberre koncentrálódása, különösen az olyan telepítési folyamat, amelyet csak egyetlen ember tud végrehajtani. Ezután: érdemi tesztlefedettség hiánya a bevételt hozó útvonalakon, licencfertőzés zárt termékbe került copyleft kódtól, védhető jogalap nélküli személyes adatok, valamint a verziókezelőbe bekerült titkok.

Érdekli az átvilágítót a technikai adósságom? Számítanak rá. Minden cégnek van, és a jelenléte önmagában nem megállapítás. Az számít, hogy a csapat tudja-e, hol van, és el tudja-e mondani, mennyibe kerül a javítása. Az ismert problémák világos nyilvántartása hozzáértésnek látszik; annak állítása, hogy nincsenek ilyenek, tájékozatlanságnak, és rontja a vizsgálat kimenetét.

Hogyan készüljek fel egy technikai átvilágításra? Írd le, hogyan indul el a rendszer egy üres gépről, vedd számba a függőségeket és a licenceiket, szedd ki a titkokat a verziókezelőből, nézd át, kinek van még hozzáférése, erősítsd meg, hogy az infrastruktúra és a domainek a cég és nem magánszemélyek tulajdonában vannak, és készíts őszinte nyilvántartást az ismert problémákról, hozzávetőleges javítási költséggel.

Meg tud állítani egy technikai megállapítás egy üzletet teljesen? Ritkán. A megállapítások nagy része árkiigazítás, szerződéses szavatossági vállalás vagy a zárás előtt teljesítendő feltétel lesz. A kivételek, amelyek tényleg megállítják a tranzakciót, a zárt termékbe került copyleft licenc okozta fertőzés és a súlyos, kezeletlen adatvédelmi kitettség.