• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Odnośnie programowania (PHP) - dobre praktyki + przydatna literatura [ankieta]

VPS Starter Arubacloud
+11 głosów
3,346 wizyt
pytanie zadane 10 września 2015 w PHP przez event15 Szeryf (93,790 p.)
przywrócone 29 września 2015 przez event15

Zauważyłem, że dużo osób ma problemy z wejściem w odniesieniu do języka PHP. Często pojawiają się tutaj pytania typu "jak zacząć? co dalej? itd." Z tego powodu postanowiłem napisać krótki poradniczek, jaką drogą warto pójść. Oczywiście to jest subiektywne i nie każdy musi się zgadzać.

Przede wszystkim warto poznać podstawy. Ja to nazywam fundamenty programowania (a raczej robił to mój wykładowca). Pod tym pojęciem kryją się następujące rzeczy:

  • Zmienne
  • Operatory
  • pętle
  • tablice
  • instrukcje warunkowe

To jest pięć filarów, na których opiera się praktycznie każdy język programowania. Nawet assembler. Warto poznać każdy z tych filarów tak dobrze jak ulubioną książkę czy film. Warto zrobić sobie dziesiątki przykładów operacji na tablicach (liczbowych, znakowych). Na przykład wyszukiwanie, sortowanie, przesuwanie, mieszanie, zliczanie sum po skosach, w całej tablicy, elementów parzystych, obliczanie średniej i mediany. Masa masa funkcjonalności. Z jednowymiarowych przechodzić do dwu-, trój-, dziesięcio-wymiarowych.

Warto poznać bardzo dobrze czeluścia operowania na plikach. Nie tylko zapis/odczyt. Ale też blokowanie w czasie otwarcia, nadawanie uprawnień, nastawianie czasowych znaczników.

W PHP nie powinien człowiek zbyt szybko zajmować się możliwością logowania, rejestracji na stronie. Wiem - jest to kuszace, ale zgubne. Operowanie na zmiennych GET bez odpowiedniej szkoły zrobi Tobie duzo więcej złego niż dobrego.
Warto PHP uczyć się tak jak języka Java. Java jest w pełni obiektowa, są ludzie, którzy uczą się jej jako pierwszego języka. PHP oferuje możliwość pisania w strukturze a także wręcz zachęca do mieszania HTML i PHP w jednym pliku. Jest to zła praktyka, ale nie znam osoby, która by zawsze oddzielała te warstwy od siebie. Kazdy kiedyś to robił.

Czemu oddzielenie kodu backendu od frondentu jest ważne?
Przede wszystkim dla zyskania czytelności. Jeżeli pracujesz samodzielnie nad kodem, to w jednym folderze masz sam backend, PHP, i doskonale się orientujesz w tym kodzie. Nie przeszkadza Ci HTML w wyszukiwaniu jakiś funkcji. Widzisz *prawdziwe* działanie swojej aplikacji. Kiedy wchodzisz do folderu z template, czy jakimkolwiek widokiem, to nie musisz się zastanawiać w którym ifie co tam dać. Widok jest oprogramowany, wystarczy tylko dbać o wygląd strony - nie przejmujesz się backendem.


Z literatury, do polecenia:
Robert C. Martin - wszystkie pozycje wink
Martin Fowler - odnośnie wzorców projektowych i architektury oprogramowania
Kent Beck o TDD
Matt Zandstra o obiektowości w PHP
O wzorcach projektowych Banda czworga (Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku)
Myślę, że warto się zainteresować autrem DDD - Eric'em Evans'em.
Do tego na YouTubie istnieje masa kanałów takich jak PHPers, Czy DevBookClub oraz warsztaty Roberta Martina jak i wielu wielu innych znamienitych postaci w programowaniu.

Warte poznania:
PHPSpec, PHPUnit, Selenium, Composer, Git, Bitbucket, Wakatime, PHPMetrics PHP code sniffer, php mess detector, gulp, bower, bootstrap.

PS. Umieszczam ankietę, żeby mieć feedback, czy to przydatny materiał na forum.
Pytanie brzmi: Czy ten post okazał/okaże się dla Ciebie przydatny?

Możliwe odpowiedzi:
Zdecydowanie nie (1 głos, 4%)
Raczej nie (5 głosów, 19%)
Dużo rzeczy nie zrozumiałem (2 głosów, 7%)
Raczej tak (6 głosów, 22%)
Zdecydowanie tak (13 głosów, 48%)

1 odpowiedź

+3 głosów
odpowiedź 10 września 2015 przez event15 Szeryf (93,790 p.)

Czego się uczyć? PHP MySQL, HTML JS?
To zależy. Jeśli lubisz bawić się w układanie elementów na ekranie, przemieszczanie ich i cieszy Cię kiedy strona, którą zrobiłeś wygląda ładnie - pójdź na początek w stronę HTML/CSS/Js. Zrób to dobrze. To nie jest trudna nauka, szybko można się nauczyć wszystkich podstaw. Kolejnym krokiem jest poznanie czegoś takiego jak Gulp, Bower, Less/Sass, Bootstrap (który służyć powinien tylko do prototypowania, a nie jak myśli dużo ludzi, do produkcji).

Jeżeli interesuje Cię sposób działania aplikacji, zastanawia Cię jak zrobić żeby dany guzik uruchamiał szereg mechanizmów to idź w PHP/ JS (tak Js też - np Node.Js). Tu początki już opisałem. Ale musisz poznać dobrze zasady tworzenia sesji, metody autentykacji. Przede wszystkim skupić się na podstawowych funkcjach gwarantujących Twoje bezpieczeństwo. Tak Twoje. Bo to Ty bierzesz odpowiedzialność za swój kod i wszystkie szkody będą musiały byc pokryte przez Ciebie.

Warto wszystko, co tworzysz wgrywac na githuba lub bitbucketa. Naprawdę. Chociażby naukę algorytmów, czy tworzenie pdf w PHP. Wrzucaj to do osobnych projektcików, możesz je robić prywatne. Ale będziesz miał dzięki temu umiejętność obsługi narzędzia do wersjonowania.

Kiedy już będziesz potrafić napisac kilka skryptów, jakiś stron internetowych - przerzucaj się na obiektówkę. To jedyna słuszna droga - chyba, że chcesz zarabiac 1200zł/mc jako programista PHP piszący w strukturze.

Obiektówkę warto zacząć od tylko poznania pojęć klas, klas abstrakcyjnych, interfejsów, implementacji, polimorfizmu, hermetyzacji danych, dziedziczenia. To jest kilka pojęć. Groźnie brzmią ale nie są straszne. Chociażby hermetyzacja oznacza utworzenie metod i pól które sa prywatne i chronione. Jeszcze prościej ujmując to po prostu "private $wiek;" w klasie.

Jak już zaczniesz pisac swoje pierwsze klasy to rób to wszędzie. Bierz stare programy i przepisuj je na obiektówkę - Robert C. Martin napisał za pomocą programowania sterowanego testami (TDD - o czym dalej) program obliczający ciąg Fibbonaciego. Niby prosta sprawa - jest algorytm to go skopiujmy. Okazało się, że w podejściu obiektowym zajmuje to duzo więcej kodu, ale nastolatek zrozumie całą ideę tego kodu bo będzie go czytał jak język pisany. Wszystko ma swoją logiczną strukture i swoje miejsce oraz odpowiednie nazwy.

Jak pisac dobrze obiektowo?
Poznać zasady SOLID. Opisane właśnie w książkach Roberta C. Martina. Poznać zasady clean code (czystego kodu). Co prawda pozycje sa dla Javowców, ale kod obiektowy ma to do siebie, ze jest uniwersalny dla każdego języka programowania (który oferuje obiektowość).
Poza tym trzeba poznać kilka/kilkanaście wzorców projektowych. Wzorce to schematy, które zostały stworzone lata temu i przetestowane przez nawet setki tysięcy programistów. Pomagają one nam utworzyć kod o niskiej zależności i dobrej jakości.

Co pomaga w pisaniu obiektowym?
Po pierwsze YouTube:) Następnie wiedza z zakresu TDD czy BDD. Pierwsze to tworzenie oprogramowaina sterowane testami, drugie to prawie to samo, ale skupia się bardziej na specyfikacji.
Chodzi w tym wszystkim o to, że tworzymy najpierw kod testu, np:

public function testAddTwoNumbers()
{
    $expected = 5;

    $this->assertEquals($expected, 2 + 3);
}

A następnie sprawdzamy czy test przechodzi. Niestety nie przechodzi, ponieważ nie mamy funkcji AddTwoNumbers. Tworzymy funkcję AddTwoNumbers, sprawdzamy, czy test przechodzi - tym razem nie zwraca ona nic więc test nie przechodzi.
Następnie dopisujemy return 5; Test przechodzi. Ale to nie koniec. Następnie sprawdzamy inne warunki, np. czy dla 4+2 wyjdzie 6. Nie przechodzi. Więc modyfikujemy funkcję. I wychodzi nam to:
 

public function AddTwoNumbers($a, $b)
{
    return $a + $b;
}

Później mozna sprawdzać, czy zmienne otrzymane to sa zmienne całkowitoliczbowe/zmiennoprzecinkowe. Można rzucac wyjątkiem, gdy poda się dwie literki. To tak na szybkiego.
BDD czy SpecTDD (SpecBDD) - różne nazwy a mniej więcej to samo znaczenie - to tworzeine żywej specyfikacji kodu, jego dokumentacji i jednocześnie testów.
Działa to na zasadzie: "JAKO zalogowany użytkownik CHCĘ miec zakładkę Wiadomości ABY móc sprawdzać pocztę" Pisze się takich testów setki dla jednej aplikacji. Są to teksty, które pozwalają sprawdzic, czy logika biznesowa jest skończona (bo to o te rzeczy pyta klient i ich wymaga). To z klientem ustalasz, jakie maja byc funkcjonalności. Czy ma byc logowanie czy ma tło skakać itp. To są te specyfikacje. W zasadzie, gdy aplikacja przechodzi te testy, można dac klientowi ja na produkcję.
Ale sa jeszcze testy jednostkowe, czy sprawdzanie działania aplikacji za pomoca np Selenium. To wszystko pozwala się upewnić, czy aplikacja rzeczywiście robi to, czego się od niej spodziewaliśmy.
Do tego dołącza się oczywiście audyty bezpieczeństwa.

Teraz staje się modne DDD - Domain-driven Design. Jest to gruba ryba. Ciężko przebrnąć przez książki traktujące o tym. Warto cokolwiek wiedzieć o tym. Jest to sposób tworzenia wielkich biznesowych kolosów, które maja tysiące klas i nawet kilkaset tysięcy linii kodu wzwyż. Jest to sposób projektowania nastawiony na dziedzinę problemu więc pojedyncza osoba tego nie osiągnie. Chociażby dlatego, ze nie można być jednocześnie domain-expertem i developerem. Ale też z wielu innych powodów.

Warto też poznać moc narzędzi takich jak composer i packagist.

Oczywiście zapomniałbym o najważniejszym chyba. Standardy PSR.
https://github.com/php-fig/fig-standards/tree/master/accepted/pl
Najlepiej skonfigurowac sobie edytor by za nas myślał o pewnych kwestiach :)

komentarz 10 września 2015 przez Comandeer Guru (603,480 p.)

Co prawda pozycje sa dla Javowców, ale kod obiektowy ma to do siebie, ze jest uniwersalny dla każdego języka programowania (który oferuje obiektowość). 

A później okazuje się, że musisz pisać w JS i możesz se tę wiedzę wsadzić… ;) 

Jest to sposób tworzenia wielkich biznesowych kolosów, które maja tysiące klas i nawet kilkaset tysięcy linii kodu wzwyż.

Wystarczy popatrzeć na Symfony czy Isolate i zastanowić się czy na pewno chcemy poruszać się aż po tak wysokich poziomach abstrakcji.

Co do PSR - polskie tłumaczenia prawdę mówiąc ssą… 

komentarz 10 września 2015 przez event15 Szeryf (93,790 p.)
@commander, z tłumaczeniami wystarczy pójść folder wyżej i ma się również po angielsku, francusku, rosyjsku czy włosku. Do wyboru do koloru.

Nie za bardzo rozumiem aluzji do Js. Napisałem, że chodzi o języki obiektowe.
Co do wysokich poziomów abstrakcji, to jeśli się pracuje to raczej nie ma się wyboru zbytniego. Dla własnej wiedzy warto poznać chociażby kod Symfony oraz liznąć trochę wiedzy o DDD. Nie każdy projekt musi być oparty o tę "metodologię" tak samo nie sa to całe projekty, tylko jakies ważne ich części.
komentarz 10 września 2015 przez Comandeer Guru (603,480 p.)

Nie za bardzo rozumiem aluzji do Js. Napisałem, że chodzi o języki obiektowe.

Przecież JS jest językiem obiektowym, ze sporą liczbą elementów funkcyjnych.

 Co do wysokich poziomów abstrakcji: jasne, nie można od nich uciec. Ale osobiście jakoś obecne OOP wydaje mi się zbyt przekombinowane i na siłę zdogmatyzowane. W większości normalnych projektów poziom skomplikowania Symfony czy Isolate po prostu się nie zwróci.

komentarz 10 września 2015 przez event15 Szeryf (93,790 p.)

Przecież JS jest językiem obiektowym

Hmm pisywałem w JS jakies 10 lat temu. Zapisało mi się, że nie był to obiektowy język. Możliwe, że coś się zmieniło od tamtego czasu. Ale czytam teraz i widzę, że zarzuca mu się jednak, że nie jest w pełni obiektowy. Nie mnie oceniać.

komentarz 10 września 2015 przez Comandeer Guru (603,480 p.)
JS jest językiem obiektowym - ale jedynym, który jest oparty na prototypach, nie klasach; stąd zarzuty "konserwatystów" OOP. Ale z własnego doświadczenia mogę Cię zapewnić, że jest ;)
komentarz 10 września 2015 przez event15 Szeryf (93,790 p.)

Ok wierzę na słowo smiley Ogólnie dzięki za wypowiedź.

komentarz 10 września 2015 przez event15 Szeryf (93,790 p.)
Przy okazji, jeżeli ktoś zaznacza, że materiał mu się nie przyda lub nie przydał to w miarę możliwości prosiłbym o krótkie uzasadnienie (może być długie).
Chodzi o kwestię ilości rzeczy? Lakoniczności ich opisu, czy temat nieciekawy itp. Cokolwiek, ale zawsze to jakiś feedback.
Tym bardziej, że jestem w trakcie pisania czegoś większego, traktującego o PHP.
komentarz 10 września 2015 przez Comandeer Guru (603,480 p.)
Ja zaznaczyłem "nie" z prostej przyczyny: wiem to. Od dawna stosuję Composera, PSR znam, staram się pisać SOLID-ny kod z testami i wgl ;) Tylko i wyłącznie dlatego. Jako materiał merytorycznie wszystko jest w porządku.
komentarz 10 września 2015 przez efiku Szeryf (75,160 p.)
Ja zaznaczyłem 'Raczej nie". Tak samo jak wyżej.. Nic dodać nic ująć. :)

Comandeer, Norbert by Ci przybił piątkę za wspomnienie tu o Isolate ! haha.
komentarz 10 września 2015 przez Boshi VIP (100,240 p.)
Ja podobnbie jak Efik :)

Podobne pytania

+1 głos
1 odpowiedź 374 wizyt
pytanie zadane 1 kwietnia 2021 w PHP przez michal_php Stary wyjadacz (13,700 p.)
+1 głos
2 odpowiedzi 481 wizyt
pytanie zadane 15 sierpnia 2021 w HTML i CSS przez kajman_Rrzeczny Użytkownik (960 p.)
+1 głos
2 odpowiedzi 370 wizyt
pytanie zadane 11 marca 2021 w SQL, bazy danych przez CSSoup Mądrala (6,460 p.)

92,770 zapytań

141,695 odpowiedzi

320,518 komentarzy

62,107 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...