Írjon a támogatásnak

E-mailben válaszolunk, általában két napon belül.

A Google reCAPTCHA visszaélés elleni védelemként ellenőrzi ezt a beküldést; ennek során adatok jutnak el a Google-hoz. A szkript csak az űrlap megnyitásakor töltődik be.

← Összes bejegyzés

Miért áll a konfigurációs fájlunk többnyire megjegyzésekből

A szerver .htaccess fájlja 478 sor hosszú. Ebből 98 sor szabály, 309 pedig megjegyzés.

309 — megjegyzéssor 98 — szabály 11 sorban dátum, 12 sorban mérés összesen 478 sor

Minden tényleges munkát végző sorra három sor magyarázat jut. Ezt az arányt nem terveztük; ez lesz belőle, ha a szabályírás szabálya az, hogy az indoklásnak ott kell állnia a szabály mellett.

Miért kell egy átírási szabályhoz egy egész bekezdés

Egy szerverkonfigurációs szabály szokatlanul ellenáll annak, hogy később elolvassák. Szándékosan tömör, nincs neve, nem lehet lépésenként végigkövetni, és a hatása láthatatlan, hacsak nem éppen a megfelelő címet kéri le valaki. Hat hónap múlva a „miért van ez itt” kérdésre az egyetlen őszinte válasz általában egy találgatás.

Ami még rosszabb: a rossz találgatás olcsó, és biztonságosnak tűnik. Egy szabályt, amelyet senki sem ért, előbb-utóbb töröl valaki egy rendrakás során, és ami ellen védett, visszatér.

Ezért itt minden szabály mellett ott áll, mire való, és hol lehet ellenőrizni. A megjegyzéssorok közül tizenegyben dátum, tizenkettőben mért érték szerepel. Ez az a két dolog, amelynek alapján egy jövőbeli olvasó eldöntheti, érvényes-e még az indok.

Három szabály, amely nem élné túl a megjegyzése nélkül

Egy nyelvkód, amely szkriptkiterjesztésnek látszott. Egy szabály, amely a hátramaradt forrásfájlokat blokkolta, kiterjesztés alapján szűrt, és az egyik tiltott kiterjesztés ez volt: .pl — Perl. A dizájn-előnézetek neve 2900.pl.svg, ahol pl a lengyel nyelvet jelöli. Minden lengyel előnézet 403-as kóddal kezdett válaszolni, miközben az összes többi nyelv rendben volt. A megjegyzés most rögzíti, hogy pl szándékosan hiányzik a listából, azt is, hogy miért, és hogy melyik napon mit mértünk. Enélkül aki legközelebb rendet rak a listában, visszateszi.

Két kapcsoló, ahol egy is elégnek látszik. Az előre tömörített fájlokat kifelé menet nem szabad újra tömöríteni. A konfiguráció ezt állítja be: no-gzip, ami a szerver két tömörítője közül az egyiket leállítja. A másik újratömörítette a kész fájlt, miközben a fejléc még mindig gzipet jelzett, és a böngészők olvashatatlan tartalmat kaptak. A megjegyzés elmagyarázza, miért van ott no-gzip és no-brotli egyaránt, mert a második eltávolítása rendrakásnak látszik.

Egy fordított logikájú tiltó szabály. A biztonsági másolatokat blokkoló szabály nem sorolja fel a tiltott kiterjesztéseket. Azt vizsgálja, hogy a fájlnév tartalmaz-e olyan forráskiterjesztést, amely nem a végén áll — így azokat a neveket is elkapja, amelyeket még senki sem talált ki. A megjegyzés felsorolja azt az öt nevet, amelyet a kézenfekvő változat rosszul kezelt, az állapotkódjaikkal együtt. Ha csak a szabályt olvassa, fölöslegesen ravasznak tűnik; ha a megjegyzést is, az egyetlen működő megoldásnak.

Az általános tanulság

A kódot megismétlő megjegyzések értéktelenek, és ezt mindenki tudja. Ezek nem ilyenek. Azt rögzítik, amit a kód nem tud: mi ment félre, mit mértünk, melyik napon, és mi volt az elvetett alternatíva.

Hogy egy megjegyzést érdemes-e megírni, az elég egyszerűen eldönthető. Ha a fölötte álló sort törölné valaki, aki nem ismeri a történetet, elromlana-e valami csendben? Ha igen, a történetet le kell írni. Ha nem, semmit sem kell írni.

A három az egyhez nem cél. Ezt adta ez a teszt egy olyan fájlon, amelyben szinte minden sor azért létezik, mert valami konkrétan elromlott.

Hirdetés