BSkyBi vanema kasutajaliidese arendaja Harry Roberts ütles, et arendajad peaksid projektides kasutama mõistet shame.css, et silitada mis tahes kiirparandusega 'häkkida' CSS.
Roberts selgitas ajaveebipostituses, et see võib potentsiaalselt peatada arendajatel kogu CSS-is häkkinud häkke ja arvata seeläbi, et sellised asjad on vaikimisi vastuvõetavad.
Lisaks märgiti artiklis, et selline lähenemine, kui see on nõuetekohaselt dokumenteeritud ja millele on lisatud kordamise vahendid, võib võimaldada kiiremat edenemist puhtama CSS-i poole projektides, kus häkkeid kasutati (ükskõik mis põhjusel).
.net rääkis Robertsiga (HB) CSS-i häkkimisest ja võimalikest eelistest, mida häbi.css õigesti kasutada võiks.
.net: Kas arvate, et mõned valdkonna inimesed kipuvad ebarealistlikult suhtuma (loodetavasti) lühiajaliste häkkide vajadusse saidi tööle saamiseks?
HR: Suuresti. Kui töötate saidil või tootel, mis teenib aastas miljoneid naelu, tuleb vead, purunemised või veidrused võimalikult kiiresti parandada. Teie toote omanikul on ükskõik, kas teie CSS on täiuslik - nad hoolivad sellest, et sait oleks korras ja toimiv ning märkiks selle tulu üle. Hea kood on oluline ja häkkimine pole kaugeltki ideaalne, kuid mõelda, et häkkeid ja lühiajalisi / kiirparandusi saab alati vältida.
.net: Nii et te ütleksite, et nad on lihtsalt vajalik pahe ettevõtte sees?
HR: Kui klient hingab teie kaela - või on funktsioon veebisaidil katki - peate veenduma, et hoiate õiged sidusrühmad rahul. Kui veedate ühe tunni, kirjutades ideaalse lahenduse asjale, mille oleksite kahe minuti jooksul saanud pealiskaudselt parandada, ütleksin, et hoiate vale inimese - st iseenda - õnnelikuna!
Oma töös olen avastanud, et häkkimise vajadus suureneb üsna proportsionaalselt projekti suurusega, kuid hea on see, et tõenäoliselt on teil hiljem ka rohkem aega nende häkkide parandamiseks pühendatud.
.net: Millest tuleb häbi.css sisse. Mida peate selle kontseptsiooniga konkreetselt CSS-i häkkimiseks?
HR: Midagi, mida oleks saanud paremini teha, andes rohkem aega. Kontekstiväliseid näiteid on raske välja mõelda, kuid arvan, et saate sageli teada, kui midagi on häkkinud. Kirjutanud midagi, mida oleks häbi kolleegile seletada? See on ilmselt häkk!
Seetõttu on shame.css faili tegemine asjadest, mida oleksite võinud paremini teha, ja et saate paremini teha, kui teil on aeg neid uuesti vaadata. See on tegelikult ise kirjutavate ülesannete loend - häkkide fail, mille panete ühele küljele mõtlema, kui teil on rohkem aega.
.net: mainite oma artiklis häkkide dokumenteerimist, kuid kas pole argumenti, et arendajad peaksid CSS-i üldiselt rohkem dokumenteerima, mitte ainult häkkimise jaoks?
HR: Jah! Kui on üks asi, mida kõik arendajad peaksid rohkem tegema, on see kommentaaride kirjutamine. Kommenteerige kõike, mis pole ainuüksi koodist kohe ilmne. Dokumenteerige oma kood nii, et kui koduteel buss tabab teid, saaks teie kolleeg järgmisel päeval selle üle võtta.
.net: Mida soovitate häbi.css integreerimise osas?
HR: Kui kasutate eeltöötlust, @import häbi. [scss | vähem | jne] fail ideaalis kohe lõpus. (See võib alati põhjustada spetsiifilisust ja allikate tellimise probleeme, nii et teie läbisõit võib erineda.)
Kui te ei kasuta eelprotsessorit, kuid teil on korralik koostamisprotsess, tuleks kogu teie CSS enne juurutamist liita ja minimeerida, nii et jällegi saab shame.css selle otsa kinnitada.
Kui te ei kasuta eeltöötlust ja teil pole koostamisprotsessi, siis ühte, peaksite selle tõenäoliselt parandama ja kaks, teie stiililehe lõpus olev häkkimisjagu on teie parim valik. Shame.css ei ole mõeldud avalikuks vaatamiseks, nii et ärge oma juurdehindluses kunagi lisage eraldi stiililehte, mida kutsub lingi element. Peaksite serveerima ainult ühte liidetud ja minimeeritud stiililehte.
.net: Kui häbi.css kui mõiste tõepoolest hoogu võtab, siis kuidas see teie arvates disainiprotsessi ja veebisaite üldiselt muuta võib?
HR: Shame.css on ainult sama kasulik kui arendajad, kes seda rakendavad. See kõik on hästi ja häkkide eraldamine ja dokumenteerimine, kuid kui te neid kunagi ei paranda ega vaata uuesti, olete lihtsalt samas paadis nagu varem.
Minu jaoks näitab häbi.css laiemat muutust arengus; see ei pea piirduma CSS-iga. Kontseptsioon on lihtsalt „häkkide realiseerimine, dokumenteerimine ja punktide loomine“. Saate seda mõtlemist rakendada kõigele.
Häbi.css-iga seotud tegelik töö on teie meeskonna (arendajate) kaasamine ja seejärel ettevõtte / PM-de / scrum-meistrite / BA-de / tooteomanike (ja nii edasi) teadvustamine asjaolule, et toode sisaldab mõnikord vähem - kui ideaalne kood, kuid see kood on olemas ärinõuete täitmiseks.
Öelge neile, et eraldate ja dokumenteerite häkkimist, ja hankige korrastamiseks aega arendamiseks. Koodibaasi korrastamiseks on lihtsam teha ärijuhtum, kui saate seda kvantifitseerida. Lihtsalt öeldes oma projektijuhile: "Mul on mõned asjad, mida enne funktsiooni X juurde liikumist korrastada," see alati ei lõika! Võtke oma peaministrile nimekiri asjadest ja proovige saada pool päeva sprindiaega koristamiseks.
Shame.css idee on lihtsalt muuta teie häkid läbipaistvamaks, mõõdetavamaks ja isoleeritumaks. See, mida te selle teabega teete, on teie otsustada!
