Harry Roberts, a BSkyB vezető felhasználói felületének fejlesztője szerint a fejlesztőknek a shame.css nevű fogalmat kell használniuk a gyorsjavítású „hack” CSS silózásához.
Roberts egy blogbejegyzésében kifejtette, hogy ez potenciálisan megakadályozhatja a fejlesztőket abban, hogy a CSS-en keresztül feltört hackeket találjanak, és ezáltal úgy gondolják, hogy az ilyen dolgok alapértelmezés szerint elfogadhatóak.
Ezenkívül a cikk megjegyezte, hogy egy ilyen megközelítés, ha megfelelően dokumentálva és az iterációs eszközökkel együtt jár, gyorsabb haladást jelenthet a tisztább CSS felé azokban a projektekben, ahol hackeléseket alkalmaztak (bármilyen okból is).
A .net beszélt Roberts-szel (HB) a CSS feltöréséről és a shame.css lehetséges előnyeiről, ha azokat helyesen használják.
.net: Gondolod, hogy az iparág néhány tagja hajlamos arra, hogy irreális a (remélhetőleg) rövid távú feltörések szükségessége a webhely működéséhez?
HR: Nagy idő. Ha olyan webhelyen vagy terméken dolgozik, amely évente több millió fontot keres, az esetleges hibákat, töréseket vagy furcsaságokat a lehető leghamarabb meg kell javítani. A terméktulajdonosod nem törődik azzal, hogy a CSS tökéletes-e - érdekli őket, hogy a webhely működőképes legyen, és bejelölje ezt a bevételt. Jó kód van fontos, és a feltörések messze nem ideálisak, de azt gondolni, hogy mindig megakadályozhatja a feltöréseket és a rövid távú / gyors javításokat, nem egyszerű.
.net: Tehát azt mondanád, hogy csak szükséges gonoszok az üzleten belül?
HR: Amikor az ügyfél a nyakán lélegzik - vagy ha egy szolgáltatás megsérül egy élő webhelyen - meg kell győződnie arról, hogy elégedett-e a megfelelő érdekeltekkel. Ha egy órát töltesz azzal, hogy megírod a tökéletes megoldást valamire, amit két perc alatt felületesen javíthatnál, azt mondanám, hogy a rossz embert tartod boldognak - azaz magadnak!
Saját munkám során azt tapasztaltam, hogy a feltörések „szükségessége” meglehetősen arányosan növekszik a projekt méretével, de az a jó, hogy később valószínűleg több projektidőt fordítanak a feltörések kijavítására.
.net: Hol jön be a shame.css. Ezzel a koncepcióval konkrétan mit tartasz CSS-hacknek?
HR: Valamit, amit jobban meg lehetett volna csinálni, több idő adta. Nehéz a kontextuson kívüli példákat elképzelni, de azt hiszem, gyakran tudni fogja, ha valami hack. Írtál valamit, amit szégyellnél elmagyarázni egy kollégának? Ez valószínűleg egy hack!
Ezért a shame.css arról szól, hogy készítsen fájlt azokról a dolgokról, amelyeket jobban megtehetett volna, és amelyeket jobban megtehet, amikor ideje újra átnéznie őket. Ez valóban egy önállóan írt tennivalók listája - olyan fájlok a feltörésekről, amelyeket az egyik oldalra helyezett, hogy átgondolja, amikor több ideje van.
.net: A cikkedben megemlíted a hackek dokumentálását, de nincs olyan érv, hogy a fejlesztőknek egyébként is inkább a CSS-t kellene dokumentálniuk, nem csak a hackekért?
HR: Igen! Ha van egy dolog, akkor minden fejlesztőnek többet kellene tennie, az megjegyzések írása. Megjegyzést kell fűznie ahhoz, ami pusztán a kódból nem nyilvánvaló. Dokumentálja a kódját, hogy ha hazafelé menet elüt egy busz, kollégája másnap átveheti.
.net: A shame.css integrálásával kapcsolatban mit javasol?
HR: Előprocesszor használata esetén @import a szégyen. [scss | kevesebb | stb] fájl ideális esetben a végén. (Ez mindig specifitáshoz és forrás-rendelési problémákhoz vezethet, ezért a futásteljesítmény változhat.)
Ha nem előfeldolgozót használ, de tisztességes felépítési folyamat van, akkor az összes CSS-t össze kell összefűzni és össze kell tömöríteni a telepítés előtt, így a shame.css ismét ennek végére csavarozhat.
Ha nem előfeldolgozót használ és nincs építési folyamatod, akkor egyet, valószínűleg javítanod kell, és kettő, a stíluslap végén található hack szakasz valószínűleg a legjobb megoldás. A Shame.css nem nyilvános megtekintésre szolgál, ezért soha ne legyen külön stíluslap, amelyet egy linkelem hív meg a jelölésben. Csak egy összefűzött és tömörített stíluslapot kell kiszolgálnia.
.net: Ha a shame.css mint fogalom valóban elindul, akkor szerinted hogyan változtathatja meg a tervezési folyamatot és általában a weboldalakat?
HR: A Shame.css csak annyira hasznos, mint az azt megvalósító fejlesztők. Minden jó és jó a hackek elszigetelésében és dokumentálásában, de ha soha nem javítja vagy újra felkeresi őket, akkor ugyanabban a hajóban van, mint korábban.
Számomra a szégyen.css a fejlődés szélesebb körű elmozdulását jelzi; nem kell csak a CSS-re korlátozódnia. A koncepció pusztán „megvalósítja, dokumentálja és pontot tesz a csapkodásokra”. Ezt a gondolkodást mindenre alkalmazhatja.
A shame.css-val kapcsolatos valódi munka a közvetlen csapat (fejlesztők) bevonása, majd az üzlet / PM / scrum master / BA / termék tulajdonosok (és így tovább) tudatosítása abban a tényben, hogy egy termék néha kevesebbet tartalmaz -az ideális kód, de hogy ez a kód az üzleti követelmények kielégítésére létezik.
Mondja meg nekik, hogy izolálja és dokumentálja a feltöréseket, és szánjon egy kis fejlesztési időt a rendrakásra. Könnyebb üzleti ügyet készíteni a kódbázis rendbetételére, ha számszerűsíteni tudja. Ha egyszerűen azt mondja a projektmenedzserének: "Van néhány dolgom, amit rendbe kell hoznom, mielőtt továbbléphetnék az X Feature-re", nem mindig vágja le! Vigyen egy listát a dolgokról a miniszterelnökének, és próbáljon meg egy fél nap sprint időt eltölteni a takarítással.
A shame.css mögött az az ötlet áll, hogy átláthatóbbá, számszerűsíthetőbbé és elszigeteltebbé tegye hackjeit. Rajtad múlik, mit csinálsz ezzel az információval!
