Dezvoltatorii ar trebui să utilizeze un concept numit shame.css pentru a depozita orice „hack” CSS de rezolvare rapidă în proiecte, potrivit Harry Roberts, dezvoltator senior de interfață de utilizare la BSkyB.
Roberts a explicat într-o postare pe blog că acest lucru ar împiedica potențial dezvoltatorii să vadă hacks în toată CSS și astfel să creadă că astfel de lucruri sunt acceptabile în mod implicit.
În plus, articolul a menționat că o astfel de abordare, dacă este corect documentată și însoțită de mijloacele de iterație, ar putea permite o progresie mai rapidă către CSS mai curat în proiectele în care au fost utilizate hacks (din orice motiv).
.net a vorbit cu Roberts (HB) despre hacking-ul CSS și despre avantajele potențiale pe care shame.css le-ar putea aduce dacă sunt utilizate corect.
.net: Credeți că există o tendință din partea unor oameni din industrie de a fi nerealiste în legătură cu necesitatea (sperăm) hacks pe termen scurt pentru ca un site să funcționeze?
HR: Timp mare. Dacă lucrați pe un site sau produs care câștigă milioane de lire sterline pe an, orice erori, rupturi sau ciudățenii trebuie reparate cât mai curând posibil. Proprietarului produsului dvs. nu îi pasă dacă CSS-ul dvs. este perfect - îi pasă de faptul că site-ul este funcțional și funcțional și că depășește venitul respectiv. Cod bun este important, iar hacks-urile sunt departe de a fi ideale, dar să crezi că poți preveni întotdeauna hacks-urile și remedierile pe termen scurt / rapid este o navă.
.net: Deci ai spune că sunt doar un rău necesar în afaceri?
HR: Când un client îți respiră gâtul - sau o caracteristică este întreruptă pe un site live - trebuie să te asiguri că ești fericit cu părțile interesate potrivite. Dacă petreceți o oră scriind soluția perfectă pentru ceva ce ați fi putut rezolva superficial în două minute, aș spune că păstrați persoana greșită fericită - adică pe voi înșivă!
În propria mea lucrare, am constatat că „nevoia” de hacks crește destul de proporțional cu dimensiunea proiectului, dar lucrul bun este că, de asemenea, probabil că veți avea mai mult timp dedicat proiectului pentru remedierea acelor hacks.
.net: Care este locul în care intervine shame.css. Cu acest concept, ce considerați în mod specific un hack CSS?
HR: Ceva care s-ar fi putut face mai bine, cu mai mult timp. Este greu să ne gândim la exemple din context, dar cred că veți ști adesea când ceva este un hack. Ai scris ceva ce ți-ar fi rușine să-i explici unui coleg? Probabil că este un hack!
Prin urmare, shame.css este despre a crea un fișier cu lucruri pe care le-ai fi putut face mai bine și că le poți face mai bine atunci când ai timp să le revizi. Este o listă de sarcini care se auto-scrie, într-adevăr - un fișier de hack-uri pe care le puneți deoparte pentru a vă gândi când aveți mai mult timp.
.net: În articolul dvs., menționați documentarea hacks-ului, dar nu există un argument că dezvoltatorii ar trebui să documenteze CSS mai mult oricum, mai degrabă decât doar pentru hacks?
HR: Da! Dacă există un lucru pe care toți dezvoltatorii ar trebui să îl facă mai mult, este să scrie comentarii. Ar trebui să comentați orice nu este imediat evident doar din cod. Documentați-vă codul astfel încât, dacă sunteți lovit de un autobuz în drumul spre casă, colegul dvs. să poată prelua a doua zi.
.net: În ceea ce privește integrarea shame.css, ce sugerați?
HR: Dacă utilizați un preprocesator, @import rușine. [scss | mai puțin | etc] fișier chiar la sfârșit, în mod ideal. (Acest lucru poate duce întotdeauna la probleme de specificitate și de comandă a sursei, astfel încât kilometrajul dvs. poate varia.)
Dacă nu utilizați un preprocesor, dar aveți un proces de construcție decent, toate CSS-urile dvs. ar trebui să fie concatenate și minimizate înainte de implementare, astfel încât, din nou, shame.css să se poată fixa la sfârșitul acestuia.
Dacă nu utilizați un preprocesator și nu aveți un proces de compilare, apoi unul, probabil ar trebui să remediați acest lucru, iar două, o secțiune de hacks la sfârșitul foii de stil este probabil cel mai bun pariu. Shame.css nu este destinat vizualizării publice, așa că nu aveți niciodată o foaie de stil separată apelată de un element de legătură în marcajul dvs. Ar trebui să difuzați o singură foaie de stil concatenată și redusă.
.net: Dacă shame.css ca concept devine cu adevărat, cum credeți că ar putea schimba procesul de proiectare și site-urile în general?
HR: Shame.css este la fel de util ca dezvoltatorii care îl implementează. Este bine și izolând și documentând hacks, dar dacă nu le remediați sau nu le revizuiți niciodată, vă aflați în aceeași barcă ca înainte.
Pentru mine, shame.css semnalează o schimbare mai largă în dezvoltare; nu trebuie să se limiteze la CSS. Conceptul este doar „realizarea, documentarea și evidențierea hacks dvs.”. Puteți aplica această gândire la orice.
Lucrarea reală implicată în shame.css constă în atragerea echipei imediate (dezvoltatori) la bord și apoi conștientizarea companiilor / PM / scrum master / BAs / proprietarii de produse (și așa mai departe) de faptul că un produs va include uneori mai puțin -Decât codul ideal, dar că acest cod există pentru a îndeplini cerințele companiei.
Spuneți-le că izolați și documentați hacks și obțineți un timp de dezvoltare alocat pentru a ordona lucrurile. Este mai ușor să creați un caz de afaceri pentru ordonarea unei baze de cod, dacă puteți să o cuantificați. Spunându-i pur și simplu managerului de proiect: „Am câteva lucruri de aranjat înainte să pot trece la Feature X” nu o va întrerupe întotdeauna! Luați o listă de lucruri către primul dvs. ministru și încercați să obțineți o jumătate de zi de timp sprint pentru a petrece curățenia.
Ideea din spatele shame.css este pur și simplu să-ți facă hacks-urile mai transparente, cuantificabile și izolate. Depinde de tine ce faci cu aceste informații!
