Kehittäjien tulisi käyttää shame.css-nimistä konseptia piilottaakseen kaikki nopeasti korjattavat "hakkerointi" CSS-hankkeet BSkyB: n vanhemman käyttöliittymäkehittäjän Harry Robertsin mukaan.
Roberts selitti blogikirjoituksessaan, että tämä saattaisi estää kehittäjät näkemästä CSS: ään hakkeroituja hakkereita ja siten ajattelevat, että tällaiset asiat ovat oletusarvoisesti hyväksyttäviä.
Lisäksi artikkelissa todettiin, että jos tällainen lähestymistapa dokumentoidaan asianmukaisesti ja siihen liitetään keinot toistaa, se voi mahdollistaa nopeamman etenemisen kohti puhtaampaa CSS: tä hankkeissa, joissa hakkerointeja käytettiin (jostain syystä).
.net puhui Robertsin (HB) kanssa CSS: n hakkeroinnista ja mahdollisista eduista, joita shame.css voi tarjota, jos sitä käytetään oikein.
.net: Luuletko, että jotkut teollisuuden ihmiset ovat epärealistisia (toivottavasti) lyhytaikaisten hakkeroiden tarpeesta saada sivusto toimimaan?
HR: Suuri aika. Jos työskentelet sivustolla tai tuotteessa, joka ansaitsee miljoonia puntaa vuodessa, mahdolliset virheet, rikkoutumiset tai oivallukset on korjattava mahdollisimman pian. Tuotteen omistajasi ei välitä, onko CSS täydellinen - he huolehtivat siitä, että sivusto on toiminnassa ja merkitsee tuloja. Hyvä koodi On tärkeää, ja hakkeroinnit eivät ole kaukana ihanteellisista, mutta ajatella, että voit aina estää hakkeroinnit ja lyhytaikaiset / pikakorjaukset, on yksinkertaista.
.net: Joten voisit sanoa, että he ovat vain välttämätön paha yrityksen sisällä?
HR: Kun asiakas hengittää niskaasi - tai ominaisuus on rikki suorassa sivustossa - sinun on varmistettava, että pidät oikeat sidosryhmät onnellisina. Jos vietät tunnin kirjoittaessasi täydellisen korjauksen jollekin, jonka olisit voinut korjata pinnallisesti kahdessa minuutissa, sanoisin, että pidät väärän henkilön onnellisena - eli itsesi!
Omassa työssäni olen huomannut, että hakkerointien tarve kasvaa melko suhteessa projektin kokoon, mutta hyvä asia on, että sinulla on todennäköisesti myöhemmin enemmän projektiaikaa näiden hakkeroiden korjaamiseen.
.net: Missä häpeä.css tulee. Mitä tämän käsitteen avulla pidät CSS-hakkerointina?
HR: Jotain, mikä olisi voitu tehdä paremmin, antaa enemmän aikaa. On vaikea ajatella esimerkkejä kontekstista, mutta luulen, että tiedät usein, kun jotain on hakata. Kirjoitit jotain, mitä olisit häpeissään selittää kollegallesi? Se on luultavasti hakata!
Siksi shame.css on tiedoston luominen asioista, jotka olisit voinut tehdä paremmin, ja että voit tehdä paremmin, kun sinulla on aikaa palata niihin. Se on itse kirjoittava tehtäväluettelo - hakkerointitiedosto, jonka asetat toiselle puolelle ajattelemaan, kun sinulla on enemmän aikaa.
.net: Artikkelissasi mainitset hakkerointien dokumentoinnin, mutta eikö ole väitettä, jonka kehittäjien tulisi yleensä dokumentoida CSS: ää enemmän, ei pelkästään hakata?
HR: Joo! Jos kaikkien kehittäjien tulisi tehdä yksi asia, se kirjoittaa kommentteja. Kommentoi mitä tahansa, mikä ei ole heti ilmeistä pelkästään koodista. Dokumentoi koodisi niin, että jos bussi osuu kotimatkallasi, kollegasi voi ottaa haltuunsa seuraavana päivänä.
.net: Mitä ehdotat häpeän.css integroimiseksi?
HR: Jos käytät esiprosessoria, @tuonti häpeä. [scss | vähemmän | jne.] tiedosto oikealla puolella, mieluiten. (Tämä voi aina johtaa spesifisyyteen ja lähdejärjestysongelmiin, joten mittarilukema voi vaihdella.)
Jos et käytä esiprosessoria, mutta sinulla on kunnollinen rakennusprosessi, kaikki CSS: si tulisi olla ketjutettu ja pienennetty ennen käyttöönottoa, joten taas shame.css voi kiinnittyä sen loppuun.
Jos et käytä esiprosessoria ja sinulla ei ole rakennusprosessia, sitten yksi, sinun pitäisi todennäköisesti korjata se, ja kaksi, hakkeriosa tyylisivun lopussa on todennäköisesti paras veto. Shame.css-tiedostoa ei ole tarkoitettu julkiseen katseluun, joten älä koskaan merkinnässäsi erillistä tyylitaulukkoa, jota kutsuu linkki-elementti. Sinun tulee palvella vain yhtä ketjutettua ja pienennettyä tyylitaulukkoa.
.net: Jos shame.css käsitteenä todella lähtee liikkeelle, kuinka luulet sen muuttavan suunnitteluprosessia ja verkkosivustoja yleensä?
HR: Shame.css on vain yhtä hyödyllinen kuin kehittäjät, jotka toteuttavat sen. Kaikki on hyvin ja hyvä eristää ja dokumentoida hakkereita, mutta jos et koskaan korjaa tai palaa niihin, olet vain samassa veneessä kuin aiemmin.
Minulle häpeä.css merkitsee laajempaa muutosta kehityksessä; sen ei tarvitse rajoittua CSS: ään. Käsite on vain "hakata, ymmärtää, dokumentoida ja tehdä pisteen hakkerisi". Voit soveltaa tätä ajattelua kaikkeen.
Shame.css -palveluun liittyvä todellinen työ on saada tiimisi (kehittäjät) mukaan alalle ja saada sitten liike / PM: t / scrum-mestarit / BA: t / tuotteiden omistajat (ja niin edelleen) tietoiseksi siitä, että tuote sisältää joskus vähemmän - ihanteellinen koodi, mutta että tämä koodi on olemassa liiketoiminnan vaatimusten täyttämiseksi.
Kerro heille, että eristät ja dokumentoit hakkereita, ja hanki jonkin verran kehitysaikaa siistimiseen. Koodipohjan siivoamiseksi on helpompaa tehdä yritystapaus, jos pystyt kvantifioimaan sen. Yksinkertaisesti sanomalla projektipäälliköllesi, "Minulla on joitain asioita, jotka täytyy siivota ennen kuin voin siirtyä Feature X: een", se ei aina leikkaa sitä! Ota luettelo asioista pääministerillesi ja yritä saada puoli päivää sprinttiä viettää siivous.
Shame.css: n idea on yksinkertaisesti tehdä hakkereistasi läpinäkyvämpiä, kvantifioitavampia ja eristettyjä. Sinusta riippuu, mitä teet näillä tiedoilla!
