Jak napisać HTML, CSS i JavaScript, aby ułatwić programistom zaplecza pracę?

Kiedy otrzymuję projekt od projektanta, otrzymuję go jako plik PSD (Photoshop). Zawsze oczekuję odpowiednich nazw warstw i folderów, w zasadzie czystego i zarządzanego PSD. Z tego projektu rozwijam HTML, CSS i JavaScript i dostarczam go programistom. Aby ułatwić im zrozumienie, ja

• pisać kod semantyczny,
• przechowuj JavaScript i CSS w plikach zewnętrznych,
• dodawać przydatne komentarze w plikach HTML, CSS i JS,
• korzystaj ze sprite'ów CSS (choć deweloperom się to nie podoba),
• użyj płyty kotłowej HTML5,
• użyj jQuery dla JavaScript,
• w miarę możliwości staraj się używać nowych tagów HTML5 i CSS3
• wysłał plik ZIP zawierający HTML, CSS, JS i obrazy.

Oczekuję, że jeśli trzeba będzie wprowadzić niewielkie zmiany w układzie, programiści mogą to obsłużyć.

Chciałbym usłyszeć od programistów zaplecza i innych ninja CSS, co więcej można zrobić w zakresie organizacji plików i narzutów, aby ułatwić integrację z systemami zaplecza (tj. Technologiami back-end, PHP, .NET , Ruby itp.) Inny klient używa różnych systemów.

Wiele z tych odpowiedzi obejmuje szeroki zakres pomysłów, ale oto moje osobiste:

• Zostaw miejsce w projekcie formularza na komunikaty o błędach.
• Nie umieszczaj etykiet w polach wprowadzania!
• Umieść CSS i JavaScript w osobnym pliku, chyba że wiesz, co robisz i źle się z tym czujesz.
• Zachowaj takie same elementy projektu między stronami. To irytujące, gdy element projektu (np. Pole „ostatnio oglądane”) ma różne znaczniki na każdej stronie.
• Nie rób tego, co jest dla ciebie łatwe, rób to, co słuszne. <button>Tagi ssać. backround-imagedla rzeczy, które naprawdę powinny być do <img>bani.
• Upewnij się, że jeśli tworzysz komponent strony, można go skalować. Wiem, że robi to większość dobrych programistów front-end, ale miałem wiele przypadków, w których ktoś używał jednego obrazu w sytuacji, w której powinna być górna / dolna granica. Programiści nie lubią otwierać Photoshopa.
• Sprawdź swoje szablony. Programiści (dobrzy) to oddani, zorientowani na szczegóły ludzie. Jeśli zaczną zauważać problemy w projekcie (być może nawigacja w stopce zawiera błędy ortograficzne lub niespójną pisownię), sprawi, że będą zadawać pytania i spowolnią pracę.

Wreszcie, a może najważniejsze:

• Naucz się podstawowych konwencji języka rozwijanego w back-endie. Możliwość spojrzenia na szablon PHP i zrozumienia podstawowej składni stojącej za instrukcją foreachlub ifinstrukcją oraz sposobu formatowania echoinstrukcji lub przenoszenia <?php ?>znaczników znacznie zwiększy twoją wartość jako programisty front-end - uwielbiam, kiedy programista front-end potrzebuje aby dokonać prostej zmiany i zrobić to w szablonie zamiast wręczać mi nowy plik zip wszystkich swoich plików.
• Jako dodatek naucz się korzystać z oprogramowania do kontroli wersji. Nie musisz być ekspertem, ale jeśli mogę spojrzeć na różnicę zamiast próbować dowiedzieć się, co zmieniło się między dwoma plikami zip, moja praca jest sto razy łatwiejsza.

To tylko kilka - jestem pewien, że jest ich o wiele więcej, ale jeśli wykonasz je wszystkie, z pewnością zyskasz szacunek i uznanie dla każdego, kto przekształca twoje szablony w stronę internetową.

Oczywiste rzeczy, które mogę wymyślić, aby ułatwić życie facetowi z zaplecza, to prostota w zachowaniu. Projektując elementy strony internetowej, które mają różne zachowania (najazdy, menu itp.), Wszystkie te zachowania powinny być znormalizowane we wspólny sposób, aby programista nie musiał ciągle powracać do niektórych wykresów w celu ustalenia, która funkcja on musi zadzwonić, aby strona zachowała się.

Siatki nie powinny wymagać komórki poprzez manipulację danymi lub funkcjonalnością komórki. Blokowane elementy stron powinny być łatwe do zdefiniowania jako wspólne elementy, aby można je było łatwo segmentować w kodzie z tyłu. Pomoże to deweloperowi w ponownym użyciu kodu i / lub ułatwieniu komunikacji między różnymi aspektami strony.

Obszary strony nie powinny przekraczać określonych granic projektowych. Przedmioty z jednego elementu nie powinny ingerować w przedmioty z innego elementu.

Przychodzi jednak moment, w którym programiści nie mogą uniknąć skoku przez płonące obręcze. Niektóre elementy interfejsu będą po prostu trudne do zbudowania z samej swojej natury.

Zauważ, że czasami musisz dokonać wyboru między ułatwieniem modyfikacji rozwiązania dla programisty zaplecza a stworzeniem czegoś zoptymalizowanego.

Cytowany przez ciebie duszek CSS jest dobrym przykładem. Nie rozumiem, jak ktoś może stworzyć stronę internetową, gdy liczy się skalowalność i wydajność, i ma linki do 100 obrazów, 5 CSS i 15 plików JavaScript z każdej strony. Z drugiej strony, duszki CSS nie są łatwe w utrzymaniu, a niewielkie zmiany w projekcie mogą wymagać dużo pracy.

Na przykład, jeśli masz trzy ikony stanu, jedną pod drugą i musisz dodać czwarty stan, czy dodajesz czwartą ikonę na dole obrazu, niezależnie od trzech innych? Czy dodajesz go po trzeciej ikonie, przenosząc wszystko inne na dół, aby mieć trochę wolnego miejsca?

To samo dotyczy łączenia i minimalizowania plików CSS i JavaScript. Musisz to zrobić dla strony internetowej na pewną skalę, ale wymagałoby to dodatkowego wysiłku.

Dla CDN jest dokładnie tak samo. Musisz używać go do dużych witryn, ale zmiany byłyby trudniejsze. Na przykład, jeśli zmieniłeś plik CSS, musisz zmusić przeglądarki do pobrania nowego, modyfikując identyfikator URI pliku cdn.example.com/g.css?r=2, a następnie cdn.example.com/g.css?r=3itd.

Także „łatwiej” jest względne . Zobacz na przykład wytyczne dotyczące pisania kodu CSS: osobiście wolę jeden styl na linię, bez białych znaków:

#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;}

podczas gdy większość ludzi nienawidzi tej składni i woli tę, której nienawidzę i której czytanie jest trudne (nie, nie jestem szalona):

#TopMenu a
{
    text-decoration: none;
    color: #fff;
    padding: 5px 10px;
    float: left;
}

W ten sam sposób korzystanie z jQuery nie oznacza, że ​​ułatwisz programistom back-end modyfikowanie plików, ponieważ niektórzy programiści mają większe doświadczenie z Prototype lub innymi frameworkami.

We wszystkich przypadkach szczegółowa dokumentacja jest pomocna, jeśli deweloper chce ją przeczytać (większość z nich tego nie robi). Możesz także ułatwić życie programistom, pytając dokładnie konkretnego programistę, jak woli robić rzeczy, i pracując ramię w ramię na początku, jednocześnie budując strukturę (na przykład projektując przepływ pracy w celu zminimalizowania i łącz pliki).

Najlepsze ze wszystkich światów jest, gdy projektant nie rzuca pliku zip na ścianę i faktycznie pracuje w projekcie jako jeden z programistów. Konfiguracja wymaga trochę trzymania się ręki, ale jest naprawdę niesamowita, gdy nie ma żadnego tłumaczenia między designem a deweloperem i każdy może wziąć udział w tych samych iteracjach. Jeśli masz dobry, bezproblemowy i sprawny proces, nie jest to zbyt trudne.

W większości przypadków zadowoliłbym się projektantami pracującymi w kontrolowany sposób i wykorzystującymi to jako mechanizm dystrybucji. Naprawdę nie chcę radzić sobie z dużym, grubym plikiem zip za każdym razem, gdy pojawia się niewielka zmiana.

Elastyczność jest dla nich zazwyczaj elastycznością. Wszystkie te sprawdzone metody są wygrane po obu stronach aplikacji.

Jednym z krytycznych i często pomijanych punktów jest jednak pisanie solidnego interfejsu użytkownika. Zbyt wiele komponentów interfejsu użytkownika jest nadmiernie zakotwiczonych w jednym kontekście lub zbyt wymagającym zestawie HTML, a ich CSS jest skonfigurowany do niepowodzenia.

Na przykład, jeśli masz listę rozwijaną, znacznie mniej pracy JS polega na zakotwiczeniu bezwzględnie umieszczonego elementu upuszczającego w ustawionym klikniętym pojemniku (bez żadnych współrzędnych) niż na wyciągnięciu młota JQuery i uzyskaniu współrzędnych, aby go unieść na element i po prostu przyklej go na miejscu. Jest również znacznie mniej prawdopodobne, że się zepsuje w przypadkach, gdy strona przesuwa się lub niektóre nowe funkcje przeglądarki odrzucają informacje o pozycjonowaniu. Im bardziej polegasz na umiejętnościach HTML / CSS, aby uniknąć pracy JS, tym bardziej solidny będzie twój interfejs użytkownika.

Zasadniczo staram się upewnić, że jedyne, czego potrzebują moje komponenty interfejsu użytkownika, to znacznik HTML, w którym można mieszkać z odpowiednim identyfikatorem lub klasą. Im więcej rzeczy możesz zrobić z tym kontenerem bez interfejsu użytkownika wewnątrz pękania lub z pojemnikiem faktycznie dostosowującym się, takim jak rozszerzanie / kurczenie, aby dopasować się do zmian wymiarów kontenera, tym bardziej można go łatwo wdrożyć w dowolnej części aplikacji bez potrzeby po stronie klienta ekspert. Wszystko, co muszą zrobić, to nakleić na to klasę.

Preferuj delegowanie zdarzeń w kontenerach interfejsu użytkownika zamiast przypisywania detektorów bezpośrednio do węzłów punktów końcowych, takich jak przyciski. Ten komponent interfejsu użytkownika może teraz działać ze statycznym HTML, ale nigdy nie wiadomo, kiedy ktoś będzie chciał wydrzeć i przepisać HTML wewnątrz za pomocą innerHTML lub coś takiego. Jeśli kontener jest nienaruszony, a wszystkie zdarzenia są delegowane (patrz metoda „włącz” jquery), nie musisz się tym martwić i może nigdy nie nauczysz się, jak zastąpienie HTML przerywa słuchaczy.

W celu utrzymania delegowania jako opcji, nie używaj stopPropagate nigdzie indziej niż węzły końcowe i wysyłaj e-maile z nienawiścią do programistów idiot Framework, którzy rozsyłają je wszędzie.

Jeśli chodzi o układ, HTML powinien być minimalny, semantyczny i unikaj opakowań div. Im mniej HTML, tym łatwiejsze problemy z układem diagnozują nowi układacze.

Użyj oczywistych nazw klas dla narzędzia CSS. Klasa „row” prawdopodobnie będzie bardziej zrozumiała dla noobów CSS niż „clearfix”.

Zawsze podawaj unikalne elementy przekroju, unikalne identyfikatory. Ułatwia to identyfikację, gdzie dzieją się rzeczy specyficzne dla sekcji, łatwiej jest nadpisywać rzeczy, a także może być wygrana przez czytelność i wydajność JS.

Oczywiście to złe wieści, że przesadza się ze schematem klas, ale im bardziej twórca zaplecza może ustawić po prostu dodając odpowiednie klasy do rzeczy, tym łatwiej będzie im wprowadzić zmiany w istniejącej stronie.

I oczywiście na początku projektu poproś ich, aby zgodzili się co najmniej na jedno: połączenie zaplecza i interfejsu tylko poprzez HTML i JSON. Nie pozwól im używać rzeczy, które „zapisują JavaScript dla Ciebie!” To cholerny bałagan i koszmar konserwacji.

Podobnie jak w przypadku wszystkich rzeczy związanych z rozwojem, preferuj DRY i minimalizm.

To wciąż nie pozwala mi tylko komentować (tak głupio), ale jako osobistą notatkę, wspomnę, codziennie pracuję z koderem PHP (a także pomagam w jego pracy), a najłatwiejszym narzędziem, jakie znaleźliśmy, jest aby skorzystać z zestawu narzędzi Komodo i wypisać zmienne „przeniesione” każdego widoku / kontrolera / modelu w przybornikux, aby w dowolnym momencie, jeśli zamierzam zaprojektować stronę wokół zestawu danych wysłanych na tę stronę, I może zajrzeć do przybornika i zobaczyć dokładnie, jakie dane są wysyłane i jaki „typ” jest wysyłany jako, a także odwrotnie z jego strony. Tylko wskazówka.