Secondo Harry Roberts, sviluppatore UI senior di BSkyB, gli sviluppatori dovrebbero utilizzare un concetto chiamato shame.css per isolare qualsiasi CSS "hack" di correzione rapida nei progetti.
Roberts ha spiegato in un post sul blog che questo potrebbe impedire agli sviluppatori di vedere gli hack disseminati in CSS e quindi pensare che tali cose siano accettabili per impostazione predefinita.
Inoltre, l'articolo ha notato che un tale approccio, se adeguatamente documentato e accompagnato dai mezzi per iterare, potrebbe consentire una progressione più rapida verso CSS più puliti nei progetti in cui sono stati utilizzati gli hack (per qualsiasi motivo).
.net ha parlato con Roberts (HB) dell'hacking dei CSS e dei potenziali vantaggi che shame.css potrebbe portare se usato correttamente.
.net: Pensi che alcune persone del settore tendano a non essere realistiche sulla necessità di (si spera) hack a breve termine per far funzionare un sito?
HR: Alla grande. Se lavori su un sito o un prodotto che guadagna milioni di sterline all'anno, eventuali bug, rotture o stranezze devono essere risolti il prima possibile. Il proprietario del prodotto non si preoccupa se il tuo CSS è perfetto: gli interessa che il sito sia attivo e funzionale e ticchetti su tali entrate. Buon codice è importante, e gli hack sono tutt'altro che ideali, ma pensare di poter sempre prevenire gli hack e le soluzioni rapide / a breve termine è fondamentale.
.net: Quindi diresti che sono solo un male necessario negli affari?
HR: Quando un cliente ti ha il fiato sul collo - o una funzionalità è rotta su un sito live - devi assicurarti di mantenere felici le parti interessate giuste. Se passi un'ora a scrivere la soluzione perfetta per qualcosa che avresti potuto sistemare superficialmente in due minuti, direi che stai mantenendo felice la persona sbagliata, cioè te stesso!
Nel mio lavoro, ho scoperto che la "necessità" di hack aumenta in modo abbastanza proporzionale con le dimensioni del progetto, ma la cosa buona è che probabilmente in seguito avrai più tempo dedicato al progetto per correggere quegli hack.
.net: Ed è qui che entra in gioco shame.css. Con questo concetto, cosa consideri nello specifico un hack CSS?
HR: Qualcosa che avrebbe potuto essere fatto meglio con più tempo. È difficile pensare a esempi fuori contesto, ma penso che spesso saprai quando qualcosa è un hack. Hai scritto qualcosa che ti vergogneresti di spiegare a un collega? Probabilmente è un trucco!
Pertanto, shame.css riguarda la creazione di un file di cose che avresti potuto fare meglio e che puoi fare meglio quando hai il tempo di rivisitarle. È un elenco di cose da fare che si autodefinisce, davvero - un file di hack che metti da parte per pensare quando hai più tempo.
.net: Nel tuo articolo, hai menzionato la documentazione degli hack, ma non c'è un argomento che gli sviluppatori dovrebbero comunque documentare di più i CSS, piuttosto che solo per gli hack?
HR: Sì! Se c'è una cosa che tutti gli sviluppatori dovrebbero fare di più, è scrivere commenti. Dovresti commentare tutto ciò che non è immediatamente ovvio dal solo codice. Documenta il tuo codice in modo che, se vieni investito da un autobus mentre torni a casa, il tuo collega può subentrare il giorno successivo.
.net: In termini di integrazione di shame.css, cosa suggerisci?
HR: Se si utilizza un preprocessore, @importare il vergogna. [scss | less | etc] file alla fine, idealmente. (Ciò potrebbe sempre portare a problemi di specificità e ordine di origine, quindi il tuo chilometraggio potrebbe variare.)
Se non stai utilizzando un preprocessore, ma hai un processo di compilazione decente, tutti i tuoi CSS dovrebbero essere concatenati e minimizzati prima della distribuzione, quindi, ancora una volta, shame.css può proseguire fino alla fine.
Se non stai utilizzando un preprocessore e non hai un processo di compilazione, quindi uno, dovresti probabilmente aggiustarlo, e due, una sezione di hack alla fine del tuo foglio di stile è probabilmente la soluzione migliore. Shame.css non è concepito per la visualizzazione pubblica, quindi non avere mai un foglio di stile separato chiamato da un elemento link nel tuo markup. Dovresti servire solo un foglio di stile concatenato e minimizzato.
.net: Se il concetto di shame.css decolla davvero, come pensi che potrebbe cambiare il processo di progettazione e i siti web in generale?
HR: Shame.css è utile solo quanto gli sviluppatori che lo implementano. Va tutto bene isolare e documentare gli hack, ma se non li aggiusti o li rivedi mai, sei sulla stessa barca di prima.
Per me, shame.css segnala un cambiamento più ampio nello sviluppo; non ha bisogno di essere limitato ai CSS. Il concetto è semplicemente "realizzare, documentare e fare un punto sui tuoi hack". Puoi applicare questo pensiero a tutto.
Il vero lavoro coinvolto con shame.css è coinvolgere il tuo team immediato (sviluppatori) e quindi rendere il business / PM / scrum master / BA / proprietari di prodotti (e così via) consapevoli del fatto che un prodotto a volte includerà meno -di un codice ideale, ma che questo codice esiste per soddisfare i requisiti aziendali.
Dite loro che state isolando e documentando gli hack e dedicate del tempo di sviluppo per riordinare le cose. È più facile creare un business case per riordinare una base di codice se è possibile quantificarla. Dire semplicemente al tuo project manager: "Ho alcune cose da riordinare prima di poter passare alla funzione X" non sempre la taglierà! Porta un elenco di cose al tuo PM e cerca di ottenere mezza giornata di sprint da dedicare alle pulizie.
L'idea alla base di shame.css è semplicemente quella di rendere i tuoi hack più trasparenti, quantificabili e isolati. Dipende da te cosa fare con queste informazioni!
