Przyspiesz pracę podczas tworzenia motywów WordPress

Opublikowany: 2020-12-17

Szybkość jest najważniejsza w prawie każdym projekcie. Często terminy są dość napięte, a dobry przepływ pracy w zespole jest jedynym sposobem, aby dotrzymać go na czas i zapobiec wypaleniu się wszystkich w trakcie całego procesu.

Jak wyglądałby taki przepływ pracy? Jak możesz wdrożyć sprawdzone metody w codziennej pracy, aby przyspieszyć dostawy? Cóż, możemy się temu przyjrzeć na kilka sposobów. Pierwsza to:

Udoskonalenia techniczne przepływu pracy

W tej części przyjrzymy się narzędziom używanym przez programistów do przyspieszenia ich pracy. Najłatwiejszym sposobem ustalenia, co działa najlepiej, jest wskazanie najwolniejszych procesów - co zajmuje najwięcej czasu. Następnym byłoby - czego potrzeba najwięcej energii umysłowej. Czasami proces może być bardzo szybki, ale za każdym razem, gdy to robisz, wydaje się, że jest to obowiązek, który wolałbyś odłożyć na później.

Sugestia 1 - Przygotuj motyw startowy

Jednym z ogromnych ulepszeń naszego przepływu pracy w DevriX było wykonanie wszystkich standardowych czynności, które robimy przed rozpoczęciem każdego projektu, umieszczenie ich w repozytorium, a następnie po prostu sklonowanie za każdym razem, gdy pojawi się nowa kompilacja.

Przygotuj motyw startowy

Jak to pomaga?

  1. Nie ma potrzeby za każdym razem konfigurować Gulp. Wszystkie pakiety są dostępne po wyjęciu z pudełka, działają, konfiguracja została przetestowana na więcej niż jednym komputerze.
  2. Pochodzi z krótką dokumentacją. Jeśli są nowi członkowie zespołu, nie muszą zadawać pytań dotyczących podstawowych zadań konfiguracyjnych, ponieważ większość z nich została już wyjaśniona.
  3. Nie ma potrzeby za każdym razem decydować o strukturze plików dla front-endu. Przeważnie nasz zespół front-end pracuje nad nowym motywem od pierwszego dnia, więc gdyby za każdym razem musieli wymyślić strukturę folderów / plików dla plików Sass, marnowalibyśmy godziny na projekt.
  4. Utrzymujemy wszystko spójne - to kolejny ogromny impuls. Zwykle w tym samym czasie aktywny jest więcej niż jeden projekt, więc wiedza o tym, gdzie znaleźć to, czego szukasz po raz pierwszy, gdy otwierasz projekt, to ogromna oszczędność czasu. Przy tej samej strukturze we wszystkich motywach, style, pliki JS i pliki PHP są w tym samym miejscu.

Zawsze, gdy znajdziemy lepsze podejście do problemu, który może poprawić konfigurację kompilacji, wprowadzić lintery, haczyki, dodać kilka działań tu i tam lub funkcje pomocnicze, które są często używane, aktualizujemy nasz motyw startowy. Jeśli zmiany w konfiguracji kompilacji są poważne, aktualizujemy również kod źródłowy istniejących projektów, aby go śledzić.

Sugestia 2 - utrzymuj ten sam styl i podejście do kodowania

Dzięki temu wszyscy programiści zrozumieją, co zrobili ludzie przed nimi. Jest w tym jednak coś więcej - gdy zastosowane zostaną te same podejścia do implementacji układów, baza kodu będzie bardziej spójna. Jest to szczególnie potrzebne programistom front-end, ponieważ zanieczyszczanie stylów jest głównym problemem regresji.

Możesz zobaczyć na przykład przewodnik Google dotyczący stylu kodowania HTML / CSS.

Przewodnik Google po stylach kodowania HTML CSS

Źródło

Typowe sposoby nazywania „wpisu” lub „komentarza” lub sposoby zarządzania „listami”, takimi jak .list-<name> i polubienia, to tylko niektóre ze standardowych podejść, które stosujemy podczas tworzenia układów.

Sugestia 3 - Popraw lokalne warunki pracy

Szybki sposób poruszania się między projektami sam w sobie to duża oszczędność czasu. Samo $cd'ing między katalogami może z łatwością zająć pół godziny dziennie. To wszystko jest straconym czasem. Zamiast tego możesz ustawić TMUX na swoim komputerze, ustawić osobne okno dla każdego projektu i oddzielny panel dla każdego zadania / celu, np. „Running Gulp” - panel 1; „Uruchamianie poleceń w motywie” - panel 2; „Uruchamianie poleceń we wtyczkach” - panel 3.

Ponadto - upewnij się, że możesz otworzyć edytor kodu bezpośrednio z terminala. To szybszy sposób na programowanie niż otwieranie z poziomu ikony, a następnie przechodzenie do „otwartego projektu” i polubień. VS Code ma to naprawdę łatwe do skonfigurowania.

Lepiej wykorzystuj swoje narzędzia

  • Kod VS, Sublime Text i wiele innych narzędzi ma wyskakujące okienko „Polecenie”, w którym można wpisać prawie wszystko, co może zrobić edytor. Zapisać wszystkie otwarte dokumenty? Tylko kilka przycisków. Zamknąć je? Wszystkie takie same.
  • Poruszaj się po palecie poleceń - przeglądanie plików na pasku bocznym również zajmuje zbyt dużo czasu. Po prostu idź dalej i wpisz potrzebną nazwę pliku. Dodaj rozszerzenia, aby przyspieszyć typowe operacje, takie jak zmiana nazwy, przenoszenie, powielanie i usuwanie plików.
  • Skonfiguruj linters. Marnowanie czasu na formatowanie plików jest zbędne, gdy istnieją narzędzia, które mogą to zrobić za Ciebie. Za każdym razem, gdy wciskasz kod, dodaj spację między nawiasami i tak dalej, co może być lepiej spędzone na rozwiązywaniu problemów.
  • Wykorzystaj skróty i fragmenty - dla programistów front-end Emmet to ratownik. Proste nav>.site-nav>ul.list-items>li.list-item*5>a{title} takie jak: nav>.site-nav>ul.list-items>li.list-item*5>a{title} rozszerzają do ponad 15 linii kodu HTMl, wszystkie sformatowane i gotowe do stylizacji. Wpisanie tej linii zajmuje kilka sekund.
Przykład VSCode

Przykład palety poleceń VSCode. Możesz przeczytać o wiele więcej na ich stronie przeglądu.

Podejmowanie decyzji w celu poprawy przepływu pracy

Ten może być nieco trudniejszy i może wymagać większego doświadczenia i zrozumienia potrzeb biznesowych klienta. Jest to również jedno z bardziej odpowiedzialnych podejść, ale czasami to właśnie może uchronić projekt przed przekroczeniem terminu.

Zacznij od najważniejszych i najszybszych do wdrożenia. Jeśli istnieje niewielka szansa, że ​​strona nie zostanie uruchomiona pierwszego dnia, nie ma potrzeby, aby od niej zaczynać. Jeśli według Twoich szacunków możliwe jest, że coś nie jest gotowe - koniecznie porozmawiaj o tym ze swoim klientem. Im jaśniej określisz, co zrobiłeś, co może zostać opóźnione i gdzie mogą wystąpić problemy, tym większe jest prawdopodobieństwo, że uda Ci się przezwyciężyć potencjalny problem.

Deleguj pracę wcześnie, ale utrzymuj łączną liczbę zaangażowanych osób na niskim poziomie. Jest to coś, co wszyscy zauważają na pewnym etapie. Może najwcześniej jest w szkole, kiedy 10 dzieci bierze udział w projekcie, ale tylko dwoje lub troje wykonuje większość pracy.

Jest to szczególnie widoczne w projektach, które zaczynają się od bardziej front-endowej pracy. Rzadko od pierwszego dnia można mieć więcej niż jednego programistę pracującego, ponieważ jedną z pierwszych rzeczy, które należy określić, jest architektura projektu. Podstawowymi decyzjami zespołu projektowego powinien być build. Jakie są komponenty, jak je rozszerzają, separacja plików, struktura i reguły media query, konwencje nazewnictwa. Wszystko to.

wykonywanie zadań

A kiedy na tak fundamentalnym etapie jest więcej niż jeden programista, obaj mogą zacząć implementować podstawowy fragment kodu, którego potrzebują, aby nadać styl pozostałej części witryny. Kiedy wypchną ten kod, pojawią się konflikty i jeden z programistów może być zmuszony do ponownego wykonania większości pracy.

Dobry moment na dodanie większej liczby programistów front-endowych byłby wtedy, gdy wykonano więcej podstawowej pracy i można ją przekazać do oddzielnych komponentów, takich jak „Karty treści”, „Strona docelowa X” lub „Strona 404” i tym podobne. Do tego czasu stosowane są czcionki, ustalane są ogólne ustawienia typografii, tworzona jest większość plików i tworzone są co najmniej 1-2 strony.

Idealnie byłoby, gdyby całkowita liczba osób skupionych na jednym projekcie była jak najmniejsza. Jeśli chodzi o zarządzanie czasem i skupienie się na zadaniu, wskazówką, którą programiści pracujący w zespole mogą chcieć rozważyć, jest przełączanie obciążenia pracą w danym projekcie.

Załóżmy, że mamy Johna, programistę front-end, który pracuje nad nową witryną przez pełne dwa tygodnie. W tym czasie patrzył na to przez ponad 80 godzin dziennie. Najprawdopodobniej przestał dostrzegać problemy na stronie! Teraz byłby dobry czas, by jego przyjaciółka Kate wkroczyła i przejęła większość jego pracy. Kate może zacząć naprawiać drobne problemy, podwójnie sprawdzając, czy jest zgodny z projektem, poprawiając wydajność tu i tam, kończąc kilka stron i komponentów, które John odkładał tylko dlatego, że nie ma na to energii psychicznej.

Jest całkiem możliwe, że większość programistów doświadczyła tego i dobrze jest mieć kolegę z zespołu, który może wkroczyć i zająć się sprawami przez kolejny tydzień lub dwa, podczas gdy Ty trochę oczyszczasz swój umysł z nowym nowym projektem lub pracami konserwacyjnymi na starszych witrynach internetowych .

W podsumowaniu:

Istnieje więcej niż kilka oczywistych technicznych sposobów na przyspieszenie rozwoju witryny. To mieszanka pracy zespołowej - tego, jak definiujesz wspólne wytyczne w swoim zespole i jak konfigurujesz środowisko pracy / automatyzujesz pracę, korzystając ze wszystkich dostępnych narzędzi. Jak utrzymujesz świeży i bystry umysł przez dłuższy czas, aby utrzymać wysoki wskaźnik produktywności, jaki miałeś pierwszego dnia.

Aby poradzić sobie z tym wszystkim, silny zespół potrzebuje dobrych starszych programistów, którzy opracują architekturę, odpowiedzialnych członków programistów, którzy będą postępować zgodnie z wytycznymi i produkować wysokiej jakości pracę, oraz dobrych kierowników projektów, którzy będą szukać stanu psychicznego wszystkich.