Jak dalej się rozwijać z PHP?, Nieco inny temat :) Opcje

[ALittleOne]

Cześć,
tytuł tematu od razu zdradza, że jest nieco inny i nie szukam pomocy czy naprowadzenia na rozwiązanie jakiegoś problemu stricte-programistycznego. Chodzi o rozwój w kwestii PHP.
Opisując w skrócie sytuację, to od nieco ponad roku pracuję z tym powiedzmy na poważnie, pełnoetatowo (wcześniej sam dłubałem z różnymi rzeczami i przy open source, własny cms itp.) przy sporym projekcie - niewielki zespół, a ze względu na maskarycznie zmieniające się potrzeby biznesowe (czasami zmiana koncepcji z dnia na dzień) kod to w dużej mierze takie nieco spaghetti... Pracujemy w zendzie i z tego co zdążyłem się zorientować, framework daje tutaj głównie podział wg. wzorca MVC oraz ułatwia nieco rzeczy. Reszta... no nie wiem czy można powiedzieć, aby zalety frameworka jako takiego są wykorzystywane.

Myślę natomiast o rozwoju. TDD, SOLID czy DDD... nie są mi to pojęcia obce, ale sucha teoria, wiecie jak to jest... tutaj bywa, że sam coś wdrażam, od choćby staram się stosować DRY, choć czy robię to na pewno dobrze, czy nie robię jakichś szalonych zależności między klasami... nie wiem. I zastanawiam się, jak mógłbym się tego dowiedzieć, nauczyć. Pracy nie chcę zmieniac, bo raz, że mimo wszystko właśnie przez te nagłe zmiany pozwala na rozwój (przez rok poznałem tyle nowości co wcześniej przez dłuuuuugo, dłuuugo), atmosfera jest świetna, mam wpływ na projekt i jego budowę, a do tego po prostu na chwilę obecną jest dla mnie bardzo dobrze płatna, a mam kwesti z życia osobistego, gdzie jest to potrzebne.

No to po pracy... tylko jak się za to zabrać? Przyznam, że chciałem poznać nowe narzędzia, zacząć od laravela i zrobić w nim aplikację malutką jakąś, może potem coś jeszcze.. potem symfony. Ale ostatnio rzuciła mi się w uszy wypowiedź Mariusza Gila na devtalk mówiąca o tym, że laravel to raczej antywzorce promuje... i bądź tu człowieku mądzy. Ja wiem, że w przypadku różnych rozwiązań i technologii jest często wojna jak masło vs margaryna, niemniej też nie chcę faktycznie "tracić czasu" (choć to nigdy nie jest strata, zawsze można później porównać i wybrać to, co w danej sytuacji lepsze) na coś, co nie nauczy mnie niczego sensownego. Ale wracając do choćby własnie TDD czy DDD - jak uczyć się samemu, albo jak ugryźć to inaczej, aby wiedzieć więcej i umieć wykorzystać to w praktyce, popełniać błędy, później je zauważać i natualnie, pojąć o co w tym chodzi, być w tym coraz lepszym? Siadam, robię przykładowo mini-bloga? Jakoś w tej sytuacji to wydaje mi się waleniem z haubicy do muchy, choć może się mylę i wymagam naprostowania przez bardziej doświadczonych.

Do tej pory polegałem głównie na książkach, ale np. w kwestii frameworków nie widziałem za wiele ciekawego - czy to laravel czy symfony, czy tym bardziej zend, np. z tego co mamy w PL dostępne to wszystko jest nieco przestarzałe i/lub moim zdaniem nieco dziwnie podchodzi do tematu (nie wiem czy dobrze, ale sam wyczuwam antywzorce jak ktoś w pliku routingu wrzuca sterowanie?). Z anglojęzycznymi wcale jednak nie jest jakoś specjalnie lepiej. To może kursy, szkolenia, o ile warto? Sam nie wiem, dlatego proszę o poradę - nie stoję w miejscu, ale czuję, że mógłbym sprawniej iść do przodu.

[thek]

Nie ma czegoś takiego jak branżowy standard. Są najwyżej dobre praktyki, których olewanie potrafi nas kopnąć po czasie boleśnie. To czego wiele osób nie mówi, to fakt, że bezkrytyczne ich stosowanie potrafi narobić więcej szkody niż pożytku czasem. O ile sama ich idea jest jak najbardziej słuszna nie znaczy to, że trzeba je stosować wszędzie, zawsze i w 100%. Może bowiem dochodzić do sytuacji, gdy jest to już sztuka dla sztuki i nie przyniesie żadnych korzyści. Może nawet wygenerować niepotrzebne koszty. Czy bowiem jest sens pisać test pokrycia dla setterów i getterów najprostszych? Dobre praktyki powinniśmy stosować, ale nie możemy tego robić automatycznie i bezrozumnie. Wszystko musi mieć swój sens. Dotyczy to wszystkiego: wzorców, SOLID, DRY, TDD, BDD, DDD i co tam jeszcze sobie nie wymyślisz za skróty. To musi naturalnie wynikać z tego co robisz i jak. Jeśli wrzucasz to na siłę, to może istnieć podejrzenie, że nie do końca to rozumiesz,a tym samym implementacja tego w projekcie może być błędna. To trochę tak jak z kultem Cargo. Naśladujesz coś, licząc na określony skutek, choć on nie musi nastąpić, ponieważ nie rozumiesz tego co robisz. Zrozumienie przychodzi często dopiero z doświadczeniem i odpowiednio dużą ilością projektów oraz "kłótniami" z innymi developerami.