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 :)
