Jeśli prowadzisz firmę, która koncentruje się zarówno na opracowywaniu rozwiązań od podstaw, jak i na wdrażaniu niestandardowego rozwiązania w kontekście wcześniej istniejących projektów (a może obu), prawdopodobnie – w pewnym momencie – w sytuacji dziedziczenia projektów WordPress.
Radzenie sobie z projektami z obu uchwytów niesie ze sobą zestaw wyzwań – większość z nich jest mile widziana – ale wydaje się, że jest to znacznie bardziej powszechne miejsce, w którym ludzie narzekają na pracę z wcześniej istniejącą bazą kodu.
Nie chodzi o to, że nie odczuwam tego, ale sądzę, że jest w tym pewien poziom niedojrzałości. Z jednej strony tak, niektóre bazy kodów są wręcz okropne. Ale niektóre bazy kodu nie są takie złe. W rzeczywistości twierdzę, że są tylko trochę inne od tego, w jaki sposób je rozwijasz.
To jest przypadek, w którym w grę wchodzą standardy, ale na razie dygresję w tej sprawie.
Załóżmy więc, że dziedziczysz projekty WordPress i nie jesteś szczególnie podekscytowany bazą kodu, z którą pracujesz. Jak to jest, że nadal możesz cieszyć się pracą, którą wykonujesz, bez poczucia, że musisz krytykować każdy aspekt tego, z czym masz do czynienia?
Dziedziczenie projektów WordPress
Po pierwsze, pojęcie narzekania na pracę innych ludzi to przysłowiowa woda, po której nie lubię stąpać.
- Nie znam tła, które doprowadziło do tego, że baza kodu jest w swoim stanie,
- nie wiem, dlaczego pewne rzeczy zostały opracowane tak, jak były (ograniczenia czasowe, brak znajomości projektu itp.),
- Mam za zadanie zrobić coś w kontekście projektu, więc po co spędzać czas skupiając się na rzeczach, które nie należą do moich obowiązków?
Rozumiem: są chwile, w których kod, który piszemy, musi komunikować się z kodem, który już istnieje. A to może być trudne. Istnieją wzorce projektowe, które nie są przeznaczone specjalnie do tej sytuacji.
Ale zamiast opisywać to, pomyślałem, że podzielę się trzema rzeczami, które moim zdaniem pokazują dojrzałość, jeśli chodzi o rozwój podczas dziedziczenia projektów WordPress, które mogą nas irytować.
1 Nie refaktoryzuj wszystkiego
Jak stwierdził Martin Fowler :
Ta oportunistyczna refaktoryzacja jest określana przez wujka Boba jako przestrzeganie zasady harcerza – zawsze zostawiaj kod w lepszym stanie, niż go znalazłeś.
Ogólnie rzecz biorąc, podoba mi się ta zasada, ale w zależności od wymagań projektu może to wykraczać poza zakres naszych obowiązków.
Jeśli więc natrafimy na coś, o czym wiemy, że wymaga refaktoryzacji, ale projekt przebiega sprawnie. Jeśli wprowadzisz w czymś jedną zmianę, ponieważ uważasz, że trzeba to zrobić, nie wiesz, jak to się potoczy w całym projekcie.
Jeśli masz czas na pełny audyt kodu, to jedno, ale jeśli nie, to Twoim zadaniem jest wprowadzenie tego, na co się zgodziłeś.
2 Skoncentruj się na tym, na co się zgodziłeś
I to prowadzi do tego punktu: podczas dziedziczenia projektów WordPress masz do wykonania pewną ilość pracy i nic więcej (dlatego mamy zestawienie pracy, prawda?).
Więc pomimo tego, jak bardzo chcesz zmienić środowisko, w którym się znajdujesz, nie rób tego. Skoncentruj się na tym, co możesz zrobić, co tylko Ty możesz zrobić i na co się zgodziłeś.
Myślę, że dobrze jest robić notatki o problemach i myślę, że może to być nawet korzystne (o czym za chwilę), ale nie trać uwagi na tym, na co się zgodziłeś. Robienie czegokolwiek, ale nieprofesjonalne.
3 Nie oceniaj poprzedniego programisty
Inną powszechną rzeczą – zwłaszcza w open source – jest ocena dewelopera, który napisał początkowy zestaw kodu, z którym pracujesz.
Co to jest? Nigdy nie napisałbym tego w ten sposób.
Chodzi mi o to, ile razy myśleliśmy o tym sobie? Ale nie znamy czasu, ograniczeń, doświadczenia ani kontekstu, w którym pracował deweloper.
Udostępniony przez nas kod niekoniecznie odzwierciedla nasz poziom umiejętności. Często jest to podyktowane zmiennymi zewnętrznymi, które mają wpływ na sposób, w jaki wdrażamy rozwiązanie.
I wiemy, jak to jest, prawda? Ile razy chcieliśmy zrobić coś w jedną stronę, ale ograniczenia i harmonogram, w którym pracujemy, dyktują nam to, co robimy?
Dlaczego więc mielibyśmy oczekiwać, że ci programiści będą inni?
Opcjonalnie: zaoferuj przyszłe wsparcie
Jak wspomniano wcześniej, jeśli natkniesz się na obszary w kodzie, które są problematyczne, nie oznacza to, że jest to przegrana przyczyna.
Zamiast tego, kiedy natkniesz się na tego typu problemy, myślę, że dobrym pomysłem jest:
- robić notatki o rzeczach, które widziałeś,
- opisz, co byś zrobił, aby to naprawić i dlaczego,
- porozmawiaj z klientem o tym, co widziałeś i korzyściach płynących z aktualizacji.
To oczywiście prowadzi do przyszłej pracy, ale być może powyżej tego pozwala oferować rozwiązania umożliwiające tworzenie lepszego, lepiej zaprojektowanego oprogramowania i pozwala upewnić się, że czynisz Internet lepszym miejscem dla tak popularnego systemu CMS.
Nie, ta praca nigdy nie jest gwarantowana, ale jest pomocna.
Jestem pewien, że jest więcej
To tylko trzy wskazówki, które oferuję w oparciu o doświadczenie, jakie mam przy dziedziczeniu projektów WordPress. Nie ma być wszechogarniająca.
Zamiast tego ma na celu dostarczenie kilku wskazówek, które pozwolą ci być bardziej ostrożnym w stosunku do pracy innych osób w odniesieniu do twojej pracy, lepiej przemyśleć, co możesz zrobić w obliczu podobnych sytuacji, oraz zebrać więcej pracy poprzez ulepszenie istniejących rozwiązanie potencjalnie.
Ale wiem, że to, o czym wspomniałem, to tylko kilka moich obserwacji. Masz własne? Wymień je w komentarzach.