Programowanie obiektowe w WordPress: analiza, część 1
Kiedy po raz pierwszy zacząłem oferować członkostwo na tej stronie, wiedziałem, że pierwszą rzeczą, którą chcę się zająć, jest wprowadzenie do programowania obiektowego.
Jest to coś, co wydaje się być interesujące dla większości osób pracujących w WordPressie, ale jest problem, który albo odwraca wielu ludzi, albo generuje słabe wyniki:
Programowanie obiektowe może szybko się skomplikować. A to staje się demotywujące.
Oto, co mam na myśli: Załóżmy, że jesteś programistą WordPress, który zaczyna badać programowanie obiektowe. Zaczyna się od mówienia o klasach, konstruktorach i funkcjach, i wszystko wydaje się dobrze.
Ale potem szybko przechodzi do:
- metody prywatne i chronione,
- dziedzictwo,
- wielopostaciowość,
- wzorce projektowe,
- wstrzykiwanie zależności,
- repozytoria,
- i tak dalej.
To śnieżki, prawda? I wcale tak nie musi być, ale trudno jest znaleźć odpowiednie wprowadzenie, z wyjątkiem kilku dostępnych zasobów.
Biorąc to wszystko pod uwagę (i służąc jako tło dla tego, dokąd zmierzam), chciałem stworzyć serię treści dla tych, którzy:
- są szczerze zainteresowani programowaniem obiektowym,
- nie wiesz od czego zacząć,
- chcą rozwijać swoje umiejętności,
- chcą zacząć od punktu zerowego bez zbyt szybkiego przechodzenia do bardziej skomplikowanego materiału.
I to właśnie zaczynam dzisiaj iw pierwszej poważnej planowanej poważnej dla członków. Powiedziawszy to wszystko, zacznijmy.
W szczególności zacznijmy mówić o programowaniu obiektowym, analizie, projektowaniu i dlaczego powinna od tego zacząć.
Programowanie obiektowe: analiza
Jeśli chodzi o pisanie kodu, obecnie są na to trzy popularne sposoby:
Za każdym razem, gdy pracujemy i czytamy kod WordPress, będziesz czytać kombinację kodu proceduralnego i kodu obiektowego.
Jest kilka powodów, dla których tak jest, ale wykracza to poza zakres naszej dyskusji.
Dzieje się tak dlatego, że WordPress jest zbudowany z obu i ponieważ niektóre aspekty programowania WordPress mogą być napisane za pomocą kodu proceduralnego, takiego jak wtyczki i motywy, a inne wymagają programowania obiektowego, takiego jak widżety.
Analiza i projektowanie
Tak często pierwszą rzeczą, którą chcemy zrobić jako programiści (początkujący lub nie), jest natychmiastowe przystąpienie do pisania kodu. Ja też. To zabawne. Mamy pomysł, chcemy go urzeczywistnić, chcemy zacząć z niego korzystać i chcemy go pokazać innym.
Oto jednak problem z robieniem tego: często przechodzimy od razu do pisania kodu, aby spróbować sprawić, by projekt robił to, czego chcemy.
Jeśli jest to prosty (a mam na myśli naprawdę prosty) projekt, to nie jest to taka wielka sprawa. Szczerze mówiąc, zrobiłem to (a GitHub jest tego dowodem). Ale jeśli chodzi o pracę, którą wykonujemy w Pressware ; to inna historia.
Jeśli chodzi o takie projekty, chcemy zrobić trochę analizy i projektowania przed napisaniem kodu.
Co rodzi pytanie, czym jest analiza i projektowanie obiektowe?
Analiza
Krótko mówiąc, pomyśl o tym w ten sposób:
Analiza to proces przejmowania pomysłu klienta lub tego, co masz i wydobycia tego, co naprawdę musi zostać zbudowane.
Może to pomóc w ustaleniu, co jest celem aplikacji, a co nie jest konieczne w przypadku pierwszej wersji aplikacji. Lubię określać je jako „niezbędne" i „miło mieć”.
Dobra zasada jest taka:
- must-have to rzeczy, które są rdzeniem aplikacji i muszą przejść do pierwszej iteracji projektu,
- rzeczy, które w końcu możemy w nią wbudować, to rzeczy, które warto mieć
Ostatecznie pomaga nam to w pracy nad silną pierwszą wersją dla klienta. Być może jeden przykład dotyczy WordPressa:
- Czy pierwsza wersja WordPressa musiała mieć interfejs API wtyczek, czy po prostu musiała umożliwiać ludziom pisanie postów i publikowanie ich w sieci?
Jeśli budujesz platformę do blogowania, czy musi być rozszerzalna od pierwszej wersji? To tylko przykład, ale masz pomysł.
Co sprawia, że analiza jest tak trudna?
Myślę, że często ma to związek z personami.
Na przykład my, jako programiści, uważamy, że projekt powinien zawsze robić to, czego chce klient. Prawda jest taka, że nie zawsze tak jest.
To znaczy, w końcu może tak być, ale pierwsza wersja projektu niekoniecznie musi tak być.
Co więcej, jedną z zasad programowania obiektowego jest to, że nie piszemy wielu duplikatów kodu. Ale może to być bardzo trudne, jeśli nie przeprowadzono odpowiedniej analizy.
Wreszcie ci, którzy są bardziej doświadczeni, powiedzą, że dobre oprogramowanie będzie korzystać ze sprawdzonych i prawdziwych zasad – czy to wzorców projektowych, czy nie – ale z czasem można je łatwo zmieniać. To w pewnym sensie rośnie organicznie.
Więc co mamy zrobić?
W następnym artykule omówię trzy rzeczy, które możemy zrobić jako programiści, aby upewnić się, że oprogramowanie, które budujemy dla siebie lub innych, prowadzi nas we właściwym kierunku.
Nie powiem, że to srebrna kula, ponieważ nie wierzę, że istnieje, ale powiem, że jest to dość mocne podejście, które znalazłem dla innych i dobrze jak ja i że prowadzi w całkiem dobrym kierunku w zakresie analizy obiektowej.
To ostatecznie doprowadzi nas do projektowania. Ale jeszcze nas tam nie ma.