Amit magunknak írtunk — és ami közben elromlott

Röviden

A saját weboldalunk mögött saját eszközök állnak: egy generátor, ami az összes oldalt egy forrásból állítja elő, egy ellenőrzés, ami a kész HTML-en végigjárja a belső linkhálót, egy nyilvántartás, ami cikkenként követi a tartalom változását, és egy elemzőrendszer, ami naponta lekérdezi, mit mondanak rólunk az AI-válaszmotorok. Az utóbbi kódja hetekig elmentetlenül állt egy ideiglenes munkamappában, ahonnan egy takarítás nyomtalanul törölte volna.

01Nem az a tézis, hogy AI-jal fejlesztünk

Azt ma mindenki állítja, és önmagában nem jelent semmit. Az érdekes rész az, hogy mi lett belőle, mennyibe került, és hol nem működött.

Ez a cikk a saját eszközeinkről szól: mi az, amit magunknak írtunk, miért, és mi az ára. A példák ennek a weboldalnak a kódjából valók.

02Mit írtunk magunknak?

Egy oldalgenerátort. A dataviral.hu oldalait nem kézzel írjuk. Egy program állítja elő őket a forrásokból, keretrendszer és külső csomag nélkül, sima Node-ban. A fejléc, a menü, a lábléc, a strukturált adat és az oldaltérkép egy helyen van definiálva, nem oldalanként bemásolva.

Strukturáltadat-generátorokat. A Google és az AI-válaszmotorok géppel olvasható adatot várnak arról, hogy egy oldal mi is. Ezt oldaltípusonként generátor állítja elő, nem kézzel írt blokk. Ha ismeretlen típust kérünk, a build leáll.

Egy linkháló-ellenőrzőt. Ez a legenerált HTML-t nézi meg — nem az adatot —, és hibával leáll, ha egy cikk kevesebb mint 3 másikból érhető el, ha egy linkhez nincs indoklás, vagy ha egy kapcsolat nem kölcsönös.

Egy frissesség-nyilvántartást. A cikkek egyetlen adatfájlban élnek, tehát a fájl dátuma mindegyiknél ugyanaz. Ez egy külön nyilvántartás, ami cikkenként tárolja a tartalom ujjlenyomatát, hogy egy designváltás ne tegyen úgy, mintha a szöveg frissült volna.

Egy láthatóság-elemzőt. Ez a legújabb: napi rendszerességgel lekérdezi az AI-válaszmotorokat előre megírt kérdésekkel, és rögzíti, mit válaszolnak, kire hivatkoznak. Mellette a keresőforgalom márkanévre szűrt trendje és a látogató botok naplózása.

03Mikor éri meg ez, és mikor nem?

A generátor előnye nem az, hogy „modern”. Az, hogy egy javítás egyszerre érvényes mindenhol.

Konkrét eset ebből a repóból: a 20 kimeneti fájl különböző verziójú stíluslapot töltött be, mert az évek során külön-külön szerkesztették őket. Ez böngésző-gyorsítótár hibákat okoz, és a látogató egy része régi designt lát új tartalommal. A generátor bevezetése után ez egyetlen érték egy helyen. Kézzel 20 fájl 20 szerkesztése lett volna, és a huszadiknál elmarad egy — nem figyelmetlenségből, hanem mert húsz azonos szerkesztés végén mindig elmarad egy.

Ez adja a döntési szabályt is, ami ügyfélmunkánál ugyanúgy érvényes: az első alkalom ára valós fejlesztési munka, a másodiké közel nulla. Ha egy feladat egyszer fordul elő, a rendszerépítés veszteség. Ha havonta, akkor néhány hónap alatt megtérül. A kérdés soha nem az, hogy meg lehet-e csinálni, hanem hogy hányszor ismétlődik.

04Hol romlott el?

A gyors gyártásnak van egy mellékterméke, amiről ritkán esik szó: ugyanolyan gyorsan keletkezik a félbehagyott munka is.

A láthatóság-elemző kódja elkészült — a napi lekérdező, a riportok, a beállítófájlok, az ütemezés. Aztán hetekig ott állt egy ideiglenes munkamappában, elmentetlenül. Nem volt rajta a projekt egyetlen ágán sem. A mappa maga ki van zárva a verziókövetésből, tehát semmi nem védte: egy rutinszerű rendrakás nyomtalanul törölte volna, és a munka újra lett volna kezdhető a nulláról.

Nem különleges hiba. Pontosan abból következik, ami az eszközépítést gyorssá teszi: több szálon fut a munka, minden szálhoz külön ideiglenes mappa tartozik, és ami ott marad, az nincs szem előtt. A szokásos helyen minden rendezettnek látszott.

Egy másik ilyen mappában egy félbehagyott repo-takarítás áll: több tucat tétel, jórészt törlésre jelölt fájlok. Ez sincs befejezve, és amíg nincs eldöntve, hogy kell-e még, addig egy takarítás itt is adatvesztéssel járhat.

A tanulság nem az, hogy lassabban kellett volna. Az, hogy a gyorsaság mellé kell egy szokás, ami rendszeresen összeszedi, hol áll félbehagyott munka. Ez most egy kézzel vezetett lista a projektben, ami tételesen felsorolja mindkét mappát. Nem elegáns megoldás, de látható.

05Mit jelent ez ügyfélmunkában?

Nem azt, hogy „nálunk AI-val megy a fejlesztés”. Két konkrétabb dolgot.

Az egyik a fenti döntési szabály. Amikor egy ügyfél azt kérdezi, érdemes-e valamit rendszerré tenni — riportot, adatgyűjtést, tartalomsablont —, a válasz az ismétlődés számán múlik, nem a technológián. Erre tudunk konkrét választ adni, mert a saját munkánkon végigcsináltuk.

A másik, hogy a rendszerépítésnek van egy ritkán említett hátránya: a rendszer működését is karban kell tartani, és a félbehagyott rendszer rosszabb, mint a kézi munka. A kézi munkáról tudni, hogy kézi. A félkész automatizmusról azt hiszed, hogy megy — és nem megy.

Amit ebből használunk: minden eszközhöz tartozik egy ellenőrzés, ami hibával leáll, ha az eszköz nem azt csinálja, amit kellene. Nem azért, mert ez elegáns, hanem mert egy csendben elromlott automatizmust nem lehet észrevenni.

→Mit érdemes megjegyezni?

A saját oldalgenerátor keretrendszer és külső csomag nélkül, sima Node-ban fut — egyetlen javítás mind a 26 oldalon egyszerre érvényes.
Az eszköz értéke az ismétlődésben van: az első alkalom ára nem kicsi, a másodiké közel nulla.
A napi láthatóság-elemzés kódja hetekig elmentetlenül állt egy ideiglenes mappában, amit egy takarítás nyomtalanul törölhetett volna.
Egy másik ideiglenes mappában egy félbehagyott repo-takarítás áll, benne törlésre jelölt fájlokkal.
Ügyfél felől nézve ez nem azt jelenti, hogy „AI-t használunk”, hanem azt, hogy melyik munkánál éri meg rendszert építeni, és melyiknél nem.

→GYIK

Gyakori kérdések

Miért ír saját eszközt egy marketinges csapat?

Nem elvi okból. Akkor éri meg, ha egy döntés ismétlődik: ha ugyanazt a szerkezetet, ellenőrzést vagy adatformát sokszor kell előállítani. Az első alkalom ára valós fejlesztési munka, a másodiké közel nulla. Egyszeri feladatnál ez nem térül meg.

Mit jelent a gyakorlatban, hogy egy generátor állítja elő az oldalakat?

Azt, hogy a fejléc, a menü, a lábléc és a strukturált adat nem oldalanként van beírva, hanem egy helyen van definiálva. Ha egy adószám vagy egy menüpont változik, egy helyen kell átírni, és a következő futásnál mind a 26 oldalon érvényes lesz. Kézzel ez 26 külön szerkesztés, és a huszonhatodiknál elmarad egy.

Mi a hátránya a gyors, AI-val segített fejlesztésnek?

Az, hogy a félbehagyott munka is gyorsan keletkezik. Nálunk két ideiglenes munkamappában állt le munka: az egyikben egy kész, de el nem mentett elemzőrendszer, a másikban egy félbehagyott takarítás. Egyik sem volt látható a szokásos helyen, tehát egy rutinszerű rendrakás mindkettőt eltüntette volna.

→Kapcsolódó gondolatok

Mit ellenőrzünk, mielőtt bármi kimegy? Ugyanannak a rendszernek a két oldala: az egyik azt írja le, mit tagad meg, a másik azt, hogyan épült és hol romlott el.
Az AI jó segédeszköz. Döntéshozónak már kevésbé. A saját eszközök építése az a munka, ahol a leggyorsabban kiderül, mit lehet gépre bízni és mit nem.
Mit veszít egy cég, ha nincs mögötte fejlesztő, aki az üzletet is érti? Az egyik belülről mutatja meg, mit jelent fejleszteni tudni; a másik azt, mi hiányzik annak, akinek ez nincs meg.

→Olvasd tovább