Na jednym z forów trafiłam na świetną prezentację na temat programowania w PHP, w której autor podejmuje się pokazać różnice między programowaniem w PHP a klepaniem kodu nazwanym przez niego PHPowaniem. Błądzić jest rzeczą ludzką, ale najważniejsze by się umieć krytycznie przyjrzeć sobie. Na szczęście stać mnie na to, więc się sobie przyglądam.
Od kilku lat zajmuję się programowaniem na pół a może nawet na ćwierć gwizdka. Dobrze, że chociaż tyle, przynajmniej nie cofam się w rozwoju. A ponieważ teraz powoli się rozkręcam i tworzę coraz więcej, postanowiłam zrobić rachunek sumienia. Analizując podlinkowaną prezentację znalazłam kilka tematów w których powinnam się w najbliższym czasie nieco podciągnąć.
Po pierwsze testy jednostkowe. Niby wiem z grubsza o co chodzi, ale jakoś tak się nie złożyło. Pora się więc chyba zaprzyjaźnić z PHPUnit.
Po drugie wzorce projektowe. No wiem, że są, coś tam kiedyś czytałam, korzystam z MVC (a ostatnio nawet HMVC) w takim stopniu w jaki daje się to zrobić w PHP i to chyba tyle. Nie najgorzej, ale mogłoby być lepiej. Może dlatego, że tak naprawdę ich nie znam to nie czuję potrzeby wykorzystywania ich? No cóż, nie pozostaje nic innego jak jeszcze trochę o wzorcach projektowych poczytać. Na szczęście mam na to coraz więcej czasu.
Bezpieczeństwo kodu, to kolejny temat do którego powinnam się bardziej przyłożyć. Oczywiście mniej więcej wiem, gdzie mogą być luki bezpieczeństwa w kodzie. Tylko czy mniej czy więcej i czy naprawdę umiem je uszczelniać?
Optymalizacja bazy danych. Sądzę, że potrafię dobrze zaprojektować bazę danych. Pod warunkiem, że projektuję ją od zera i że pod koniec pracy nie pojawiają się nowe pomysły i wymagania. Projekt bazy to jedno, projektowanie zapytań to druga kwestia. Często staje się przed dylematem czy lepiej wykorzystać kilka prostych zapytań, czy jedno złożone. A jeśli złożone to join czy podzapytania czy jeszcze inaczej. W podjęciu decyzji pomocne jest wykorzystanie komendy EXPLAIN (jeszcze jeden artykuł)
Zagadnienia z którymi nie miałam jeszcze do czynienia (albo nie wiem, że w gruncie rzeczy to miałam):
- SOAP
- REST
- RSP i ogólnie SOLID
- Traits
- Lambda Functions
- Konwencja nazewnictwa PSR-0
- Agile
Nie wiem, czy powinnam się do tego przyznawać, no ale jak tego teraz nie podsumuję to zapomnę a za jakiś czas nie będę potrafiła powiedzieć czy i jak szybko robię postępy. W każdym razie zrobiłam uczciwy rachunek sumienia. Polecam każdemu. Nawet jeśli miałby dojść do wniosku, że niektóre zagadnienia to sztuka dla sztuki, albo, że to wyciąganie armaty do ustrzelenia muchy w przypadku jego niewielkich projektów, to jednak warto wiedzieć co w trawie piszczy i o czym do nas mówią.
SOAP – wszedzie gdzie prowadzisz komunikacje wymagajaca bezpieczestwa i stabilnosci – raczej wieksze projekty, ewentualnie zczytywanie danych z roznych api wystawianych przez wieksze portale
REST – cos na wzor prostrzej wersji SOAP, jednak imho jak jest wybor to lepiej korzystac z SOPA – wiecej narzedzie, gotowa walidacja schematu request/resposne
Lambda Functions – jak mialas minimalna nawet stycznosc z jQuery to powinnas w mig umiec wykorzystac
PSR-0,1 (2) – Warto korzystac, mniejszy balagan w kodzie, jak sie przestrzega to duzo latwiej odnalezc sie w dowolnym kodzie ktory tez korzysta z tych zasad. Bardzo uprasza szukanie klas przy pomocy IDE (no i autoloader PHPowy smiga sprawniej)
Agile – do kontaktow z klientem SCRUM albo Kanban, ale ciezko o klienta ktory bedzie umial to ogarnac i chcial stosowac – wiec koniec koncow konczy sie natym ze programista sam mus i to robic – ale ulatwia planowanie, a w zespole to jedyna metoda zeby calosc sprawnie leciala.
Dodatko polecam przyjrzec sie Composer, no i GIT’owi (sam w sobie GIT jest niezastapiony, ale jest wiarze sie z wieloma tematami pobocznymi, jak wersjonowanie, aktualizacja produkcji prodkow z duza liczba repozytoriow, etc) – ale to za pewne opanowalas :)
“Duże frameworki (Symfony2, Zend2) wymagają sporej dawki wiedzy na temat architektury i OOP. I między innymi dlatego są uważane, za “trudne””
Duże frameworki wcale nie wymagają dużo większej wiedzy. Ich problemem jest fakt że aby uzyskać jakąś funkcjonalność, trzeba stworzyć 3 razy więcej kodu.
Kolejna sprawa to boom na testy. Testy mają sens tylko w przypadku gdy przewidujemy dalszy rozrost aplikacji i musimy mieć pewność wstecznej kompatybilności. Jeśli tworzymy kod którego nie będziemy za rok rozwijać, lub jest to mała aplikacja, nie ma ma sensu go testować. Sam test w niczym nie jest lepszy od przeklikania. Jeśli nie wpadniesz na pomysł aby coś przeklikać, nie uwzględnisz też tego w testach. Dziwi mnie również fakt wymuszania pisania testów w projektach open-source które w większości przypadków nie utrzymują wstecznej kompatybilności. Kolejna sprawa to czy testy powinna pisać osoba która tworzyła kod? Raczej nie. Więc czemu się tego wymaga? Osobiście widzę rozgałęzienie rynku na firmy tworzące mały kod gdzie testy są zbędne, firmy ślepe na testy, firmy szukające człowieka orkiestry – czy to fw + fotoszop, czy też symfony + testy i na koniec firmy ogarnięte, które posiadają osobne zespoły programistów, audytorów, testerów. Czemu zamiast promowania tych ostatnich promuje się ludzi orkiestry? Moda. Trzeba ją przeczekać w bezpiecznym miejscu. Jako freelancer, lub w małej/średniej firmie. Można oczywiście też się dostosować do mody i klepiąc za 3.
PSR-0, wzorce, lambdy, klasy abstrakcyjne to obecnie podstawy podstaw które są narzucane przez większość fw i bez których trudno szybko napisać coś sensownego.
Spawnm chyba nie przeczytałeś uważnie tej prezentacji i skupiłeś się na kilku kwestiach wyrwanych z kontekstu. Jeśli ktoś jest sobie sam sterem żaglem i okrętem i pisze tylko małe aplikacje, które z założenia nie mają się rozwijać to ja rozumiem, że to jest człowiek w kategorii “jestem masterem i robię internety” OK. Niech sobie będzie, nikt mu się nie każe rozwijać.
Szczerze mówiąc nie uważam, żeby testy były związane jedynie ze wsteczną kompatybilnością projektu.
A to co piszesz o modzie to też nie jest prawda. To nie jest wcale nowe zjawisko, to szukanie człowieka orkiestry. To się nazywa prawo rynku stworzone przez studentów, którzy “potrafią wszystko”, pracodawców, którzy chcą ciąć koszty i kryzys (prawdziwy czy rzekomy to ja już nie wiem).
Ja się zgodzę z @Spawnm, może poza wsteczną kompatybilnością, ale reszta się zgadza. Nie należy wciskać testów na siłę, należy udowodnić, że w danym projekcie to się opłaca. Inaczej to jest często strata czasu i pieniędzy.
Ależ ja się zgadzam. Nic na siłę. Ale ten artykuł jest o czymś innym. Zaczynam wątpić w to, czy programiści potrafią czytać ze zrozumieniem. Jestem zdruzgotana.
@Spawnm. Piszesz o tym, że programista nie powinien sam pisać testów i wydaje mi się, że nie rozróżniasz testów jednostkowych od np. funkcjonalnych. Wg TDD testy jednostkowe powinien pisać sam programista i to przed napisaniem samej metody która ma być testowana. Testy takie pozwalają nie tylko zachowywać kompatybilność wsteczną, ale też ułatwiają refaktoryzację czy mogą być czymś w rodzaju dokumentacji kodu ponieważ pokazują jak używać jakąś metodę czy funkcję.
Mi się ta prezentacja niezbyt podoba. Może dlatego, że nie jestem tzw. “programistą PHP” i nie planuję rekrutować się do “ogólnopolskiej firmy”.
Autor chyba przesadnie doświadczony nie jest, bo niektóre stwierdzenia w prezentacji rozśmieszyły mnie.
Autor jakby nie dostrzega, że jest też rynek “małych aplikacji”, gdzie pisanie unit testów, czy też stosowanie design patterns, REST-a i paru innych nie ma zastosowania.
“Programujemy, byle jak, na ilość” i zaraz:
“nie zwracamy uwagi na potrzeby biznesowe klienta”
No, zwykle programowanie na ilość wynika właśnie z potrzeb biznesowych klienta (termin) :-)
Poza tym programista w dużej firmie nie jest od rozumienia potrzeb biznesowych klienta, tylko ma wykonać aplikację na podstawie projektu :-)
“Wzorce Projektowe? Przecież nikt z tego nie korzysta. No, może autorzy frameworków… I dużych aplikacji…” – no właśnie po to są m. in. FW, abyśmy się we wzorce projektowe nie bawili póki nie musimy.
“Nie wie co to testy jednostkowe, są dla niego zbędne. Czyli “przespał” ostatnie kilka lat, skutecznie ignoruje fakt, że testy istnieją dla większośći frameworków, bardzo wielu bibliotek i są już pewnym standardem.” – jakim znowu standardem, tam gdzie to ma sens (np FW) to się robi. Dla małej aplikacji
Wiem, że wzorce projektowe są potrzebne i sam korzystam z symfony. Czy jest trudna nie wiem. Natomiast wiem, że są tam rzeczy o których nie wiem albo nie mogę ich znaleźć. Dokumentacja może i jest ale jak potrzeba znaleźć coś konkretnego to trzeba stracić sporo czasu. Mało jest przykładów. Np. szukam teraz jak ustawić w formularzu zakres lat(bo ustawia mi zakres od 2008 do 2016 a ja potrzebuję daty urodzenia od powiedzmy 1900 do bieżącego) pamiętam, że już kiedyś tego szukałem. W każdym bądź razie znalezienie tego nie jest proste ani intuicyjne.