Mit bízz gépre egy weboldal ellenőrzéséből?
Egy kézzel írt oldalon nincs keretrendszer, ami szólna, ha elromlik valami. Ezt a hiányt egy ellenőrző szkript tölti be — és minden szakasza mögött egy valódi hiba áll.
Egy keretrendszer sok mindent elkap magától. Ha egy oldal hivatkozása elgépelt, a build megáll; ha egy komponens hiányzik, a fordító szól. Aki kézzel írja a HTML-t, ezt a hálót elveszíti. Cserébe megkapja azt, hogy pontosan tudja, mi van a lapon — de senki nem szól, ha egy hivatkozás sehová sem visz, vagy ha a strukturált adat elvált attól, ami a képernyőn látszik.
A megoldás nem az, hogy figyelmesebb leszek. Az, hogy megírom egyszer, amit figyelnem kellene, és onnantól minden változtatás után lefuttatom.
- 01 szerkesztés
- 02 ellenőrzés
- 03 közzététel
ha bármi hibás, nincs közzététel
Amit egy validátor nem tud megnézni
A formai ellenőrzésre van kész eszköz. Egy HTML-validátor megmondja, ha egy elem lezáratlan; egy linkellenőrző megmondja, ha egy hivatkozás 404-et ad. Ezek fontosak, és a szkript első szakaszai pontosan ezt csinálják: megnézik, hogy minden lapon ott van-e a leírás és a kanonikus cím, hogy a nyelvi párok kölcsönösen hivatkoznak-e egymásra, hogy a sitemap tartalmazza-e az összes lapot, és hogy a strukturált adat érvényes JSON-e.
A nehezebb rész az, amit egyetlen általános eszköz sem tud, mert nem ismeri a lapot. Ezen az oldalon például az adatkezelési tájékoztató azt állítja, hogy a lap nem küld kérést külső kiszolgálóra. Ez jogi állítás egy dokumentumban. Ha holnap valaki beilleszt egy betűtípust egy CDN-ről, a tájékoztató attól a pillanattól kezdve valótlan — és semmilyen validátor nem fog szólni, mert szintaktikailag minden rendben van.
Ezért van külön szakasz, ami minden lapon végignézi az összes
src és href értéket, és elbukik, ha bármelyik
idegen kiszolgálóra mutat. Nem a kód védelme ez, hanem a szövegé.
Az ellenőrzés, ami a saját szabályaimat őrzi
Az igazán hasznos szakaszok azok, amelyek olyan döntést tartanak be, amit én hoztam, és amit magamtól előbb-utóbb megszegnék.
Az egyik ilyen az elavuló időkifejezés. Ha egy
esettanulmányban az áll, hogy több mint egy éve üzemeltetem, az a mondat
a megírás napján igaz, fél év múlva viszont pontatlan, két év múlva
nevetséges — és senki nem fogja frissíteni. A magyarban a rag árulkodik:
az „egy éve” a jelenhez köt, az „egy évig” lezár egy
múltbeli szakaszt. Az utóbbi sosem avul el. A szkript egy mintalistával
keresi az előbbieket.
A másik a darabszám. Egy gyűjtőoldal címe soha nem
állíthatja, hány elem van rajta: a „tizenegy esettanulmány” a tizenkettedik
pillanatában hazuggá válik. Ugyanez az ellenőrzés azt is nézi, hogy a
strukturált adatban szereplő numberOfItems egyezik-e a valódi
listahosszal — ez az a fajta eltérés, amit szemmel soha nem venne észre az
ember, mert két külön helyen van.
A harmadik ilyen szakasz az ügyfélnév-szivárgás. Az
esettanulmányokban a megbízók neve pontosan egy helyen szerepel, és ott
is jelöléssel — az ellenőrzés elbukik, ha a név bárhol máshol felbukkan:
címben, leírásban, hivatkozás szövegében, strukturált adatban. Erről
külön írás szól: miért nem a
noindex a megoldás.
Amit egy hiba tanított
Egyik szakasz sem előre kitalált. Mindegyik akkor került bele, amikor valami már elromlott.
A betűtípus-lefedettség például onnan jött, hogy egy magyar szöveg hosszú ő betűje a választott betűfájlban nem létezett, és a böngésző csendben egy másik betűre váltott — csak abban az egy szóban. Ezt képernyőn nézve az ember észreveszi, ha épp arra a szóra néz. A szkript azóta minden lap minden karakterét összeveti a betűfájlok karakterkészletével.
A diagram-osztályok szakasza onnan, hogy az SVG-ábrákon elgépeltem egy osztálynevet. A rajz megjelent, csak épp stílus nélkül: nem hiányzott, csak rossz volt. Az ellenőrzés összeveti az ábrákban használt osztályneveket a stíluslapban létezőkkel.
A kitöltendő helyek szakasza pedig a legegyszerűbb és a
leghasznosabb: megkeresi a lapokon a TODO, a
LOREM és a saját jelöléseim maradványait. Egy félkész
szövegrész sokkal könnyebben marad bent, mint hinnénk.
Amit nem ellenőriz
A szkript nem mondja meg, hogy a szöveg jó-e. Nem tudja, hogy egy mondat fellengzős, hogy egy bekezdés fölösleges, vagy hogy egy magyarázat nem érthető. Nem méri a sebességet, és nem nézi meg, hogy a lap hogyan fest. Ezek nem automatizálhatók, és nem is baj: attól, hogy valamit nem lehet gépre bízni, még nem lesz kevésbé fontos — csak nekem kell elvégeznem.
Egy dologra viszont érdemes figyelni. Az első változatom túl tág volt: az elavuló időkifejezésekre írt minta ráriasztott olyan mondatokra is, amelyek rendben voltak. Két hét alatt megszoktam, hogy azt a sort átugrom — és onnantól az ellenőrzés nem védett semmitől. A zajos ellenőrzés rosszabb, mint a hiányzó, mert bizalmat kelt anélkül, hogy fedezetet adna rá.
Kérdések a témáról
Miért nem elég egy linter vagy egy HTML-validátor?
Mert azok a szintaxist nézik, nem az állításokat. Egy validátor nem tudja, hogy az adatkezelési tájékoztató azt írja: az oldal nem küld külső kérést. Az ellenőrzés érdemi része nem formai, hanem tartalmi: azt vizsgálja, igaz-e még, amit a lap magáról állít.
Honnan tudom, milyen ellenőrzésre van szükségem?
Onnan, hogy már elromlott. Minden szakasz mögött egy valódi hiba áll, ami átcsúszott. Az előre kitalált ellenőrzés általában olyasmit néz, ami sosem romlik el, és zajt termel; egy elkapott hibából született ellenőrzés viszont pontosan azt őrzi, ami tud törni.
Mennyi ideig tart egy ilyen szkript megírása?
Nem egyben készül. Az első változat néhány óra, utána minden szakasz külön alkalommal kerül bele, amikor egy hiba megtalálja magát. Ez a lassúság előny: így csak olyan ellenőrzés kerül bele, amire bizonyítottan szükség van.
Mi történik, ha az ellenőrzés hamisan riaszt?
Ki kell javítani vagy ki kell venni, méghozzá azonnal. Egy ellenőrzés, ami rendszeresen jelez olyasmit, ami rendben van, néhány hét alatt megtanítja az embert arra, hogy ne olvassa el a kimenetét — onnantól a valódi hibát sem fogja észrevenni.