Według Harry Robertsa, starszego programisty UI w BSkyB, programiści powinni stosować koncepcję o nazwie shame.css, aby odseparować wszelkie szybkie poprawki CSS w projektach.
Roberts wyjaśnił w poście na blogu, że mogłoby to potencjalnie uniemożliwić programistom zobaczenie hacków rozsianych w CSS i tym samym sądzić, że takie rzeczy są domyślnie dopuszczalne.
Ponadto w artykule zauważono, że takie podejście, jeśli zostanie odpowiednio udokumentowane i połączone ze środkami do iteracji, może umożliwić szybszy postęp w kierunku czystszego CSS w projektach, w których używano hacków (z dowolnego powodu).
.net rozmawiał z Robertsem (HB) o hakowaniu CSS i potencjalnych korzyściach, jakie shame.css może przynieść, jeśli zostanie prawidłowo użyty.
.net: Czy uważasz, że niektórzy ludzie w branży mają nierealistyczną tendencję do (miejmy nadzieję) krótkoterminowych hacków, aby strona działała?
HR: Wielki czas. Jeśli pracujesz w witrynie lub produkcie, który zarabia miliony funtów rocznie, wszelkie błędy, awarie lub dziwactwa wymagają jak najszybszej naprawy. Właściciela produktu nie obchodzi, czy Twój CSS jest doskonały - obchodzi go, że witryna działa, działa i notuje te przychody. Dobry kod jest ważne, a hacki są dalekie od ideału, ale myślenie, że zawsze można zapobiec włamaniom, a krótkoterminowe / szybkie poprawki jest naiwne.
.net: Więc można powiedzieć, że są one po prostu złem koniecznym w biznesie?
HR: Kiedy klient oddycha ci po karku - lub jakaś funkcja jest zepsuta w działającej witrynie - musisz upewnić się, że dbasz o zadowolenie właściwych interesariuszy. Jeśli spędzisz godzinę na pisaniu idealnej poprawki do czegoś, co mogłeś powierzchownie naprawić w ciągu dwóch minut, powiedziałbym, że uszczęśliwiasz niewłaściwą osobę - tj. Siebie!
W mojej własnej pracy odkryłem, że „potrzeba” hackowania rośnie proporcjonalnie do rozmiaru projektu, ale dobrą rzeczą jest to, że prawdopodobnie później będziesz miał więcej czasu poświęconego na naprawienie tych hacków.
.net: W którym miejscu pojawia się shame.css. Co konkretnie uważasz za włamanie do CSS?
HR: Coś, co można było zrobić lepiej, mając więcej czasu. Trudno wymyślić przykłady wyrwane z kontekstu, ale myślę, że często wiesz, kiedy coś jest włamaniem. Napisałeś coś, czego wstydziłbyś się wyjaśnić koledze? To prawdopodobnie hack!
Dlatego shame.css polega na utworzeniu pliku rzeczy, które mogłeś zrobić lepiej, i że możesz zrobić to lepiej, gdy masz czas, aby je ponownie odwiedzić. To tak naprawdę lista rzeczy do zrobienia - zbiór hacków, które odkładasz na bok, aby przemyśleć, kiedy masz więcej czasu.
.net: W swoim artykule wspominasz o dokumentowaniu hacków, ale czy nie ma argumentu, że programiści i tak powinni bardziej dokumentować CSS, a nie tylko dla hacków?
HR: Tak! Jeśli jest jedna rzecz, którą wszyscy programiści powinni zrobić więcej, to pisanie komentarzy. Powinieneś komentować wszystko, co nie jest od razu oczywiste na podstawie samego kodu. Udokumentuj swój kod, aby w przypadku potrącenia przez autobus w drodze do domu Twój kolega mógł przejąć kontrolę następnego dnia.
.net: Jeśli chodzi o integrację shame.css, co sugerujesz?
HR: Jeśli używasz preprocesora, @import the wstyd. [scss | less | etc] najlepiej plik na samym końcu. (Może to zawsze prowadzić do problemów ze szczegółowością i kolejnością źródeł, więc przebieg może się różnić).
Jeśli nie używasz preprocesora, ale masz przyzwoity proces kompilacji, cały kod CSS powinien zostać konkatenowany i zminimalizowany przed wdrożeniem, więc ponownie shame.css może przyspieszyć do końca.
Jeśli nie używasz preprocesora i nie masz procesu budowania, to jeden, prawdopodobnie powinieneś to naprawić, a po drugie, sekcja hacków na końcu arkusza stylów jest prawdopodobnie najlepszym rozwiązaniem. Shame.css nie jest przeznaczony do publicznego oglądania, więc nigdy nie używaj osobnego arkusza stylów wywoływanego przez element link w swoim znaczniku. Powinieneś udostępniać tylko jeden połączony i zminimalizowany arkusz stylów.
.net: Jeśli koncepcja shame.css naprawdę się rozwinie, jak myślisz, jak mogłaby zmienić proces projektowania i ogólnie strony internetowe?
HR: Shame.css jest tak przydatny, jak programiści, którzy go wdrażają. Wszystko dobrze i dobrze izoluje i dokumentuje hacki, ale jeśli nigdy ich nie naprawisz ani nie odwiedzisz, jesteś na tej samej łodzi co wcześniej.
Dla mnie shame.css sygnalizuje szerszą zmianę w rozwoju; nie musi ograniczać się do CSS. Koncepcja polega po prostu na „uświadomieniu sobie, udokumentowaniu i podkreśleniu swoich hacków”. Możesz zastosować to myślenie do wszystkiego.
Prawdziwa praca związana z shame.css polega na zaangażowaniu bezpośredniego zespołu (programistów) na pokład, a następnie uświadomieniu biznesowi / PM / Scrum Masters / BA / właścicielom produktów (i tak dalej) faktu, że produkt czasami będzie zawierał mniej -niż idealny kod, ale ten kod istnieje, aby spełnić wymagania biznesowe.
Powiedz im, że izolujesz i dokumentujesz włamania, i uzyskaj trochę czasu na rozwój, aby to uporządkować. Łatwiej jest przedstawić uzasadnienie biznesowe dla uporządkowania bazy kodu, jeśli można to określić ilościowo. Zwykłe powiedzenie kierownikowi projektu: „Muszę załatwić kilka rzeczy, zanim przejdę do funkcji X”, nie zawsze wystarczy! Zanieś listę rzeczy swojemu premierowi i postaraj się spędzić pół dnia sprintu na sprzątanie.
Ideą shame.css jest po prostu uczynienie hacków bardziej przejrzystymi, policzalnymi i izolowanymi. To od Ciebie zależy, co zrobisz z tymi informacjami!
