13. GIT?
• GIT czy nie GIT? Kiedy GIT?
• Repozytorium?
• Częste błędy i problemy
• git status
• git config --global core.excludesfile ~/.gitignore_global
• chmod
• Commit message!
16. TESTY
• Testuj! Jeśli możesz to test-first (TDD)
• Zacznij od małych/prostych testów
• Dużo mocków = błędny design
• Behat to nie konieczność, BDD to nie jedyne
wyjście
• Czytaj
Najpierw opowiem o środowisku: systemie, serwerze www, oprogramowaniu, IDE itp.
Następnie przedyskutuję uruchamianie projektu i decyzje jakie należy podjąć: podział na bundle, kontrola wersji, testy, automatyzacja zadań.
W kolejnej części przedstawię na przykładach wybrane elementy kodu Symfony 2 i zalecane praktyki z nimi związane
Na koniec powiem trochę o podejściu do projektu i wykorzystywanych technologii
Środowisko na pewno nie jest najważniejszym, ani najbardziej ekscytującym elementem związanym z rozwojem oprogramowania. Niestety, bez odpowiedniego środowiska ciężko jest rozwijać jakiekolwiek oprogramowanie, a co dopiero robić to wydajnie.
Jeśli chcesz się nauczyć Symfony2 to pewnie siłą rzeczy przebrniesz przez całą konfigurację, ale chyba każdy się zgodzi, że poświęcony na to czas można wykorzystać znacznie lepiej. Dodatkowo często chęc zaoszczędzenia czasu powoduje, że przywiązujemy się do znanych nam technologii, w sytuacjach, gdzie zmiana na nowsze byłaby znacznie lepsza.
Postaram się omówić kolejne elementy środowiska, abyś pokazać na co zwracać uwagę. Na końcu przedstawię szybki sposób na uruchomienie takiego środowiska z wykorzystaniem Ansible.
Ułatwia ale nie zastępuje programisty; Notepad++ to nie to samo; Szybka nawigacja, skakanie po plikach/metodach itp;
Composer - do tej pory; łatwo, ale trochę wolno i dodawał śmieciowe bundle
Symfony Installer - nowość, bardzo szybkie, łatwiejsze, ale też dodaje śmieciowe bundle
Generalnie: jakakikolwiek sys. kontr. wersji. GIT używa się b. przyjemnie. Nie wymaga serwera, może być używany tylko lokalnie. Zawsze warto - np. prywatne projekty, praca mgr. Można założyć repo na github/bitbucket za darmo.
Śmieci - .idea, cache, parameters.yml, composer.phar, vendor; Używać ‚git status’ ; chmod (php-fpm) i kiedy wrzucać composer.lock
Pamiętaj, aby wszystkie parametry takie jak nazwa i dane do bazy danych, smtp, systemów płatności trzymać w parameters.yml i ustawić domyślne lub puste wartości w parameters.yml.dist. Dodając funkcję zastanów się, czy któryś parametr nie powinien być definiowany w parameters.yml - np. co ile dni wysyłać automatyczny newsletter :) Istnieją wyjątki do tej reguły, o których wspomina “Best Practices”.
Zalecenia mocno się zmieniały; obecna wersja w “Best Practices”. Nie będę zagłębiać się w ten temat, nie powinniście się zbytnio tym przejmować. ważne żeby dzielić projekt na bundle (logicznie); nie wszystko musi być w bundlu.
Wpływ ma podejście - np. DDD.
Buzzword BDD - 90% robi to źle, a Ty wcale nie musisz zaczynać do Behata.
Automatyzuj co tylko możesz. Uruchomienie projektu/przeładowanie bazy wymaga kilku komend? Automatyzuj to! Assety wymagają kilku komend - automatyzuj! Tak samo zautomatyzowaliśmy podstawową konfigurację ubuntu - pracownik zamiast 4 godzin poświęci na set-up tylko 1.
Wiemy jak uruchomić i na co zwracać uwagę. A co robimy źle w kodzie? Czyli zaczyna się „mięso”
controller: szybko, łatwo, sporo metod pomocnicznych, czytelnie
popo: lepsza świadomość zależności, separacja od FW, warto spróbować, ale prawdopodobnie nie warto stosować zawsze; ciekawe ćwieczenie
fw: adnotacje: security, paramconverter, template, metody addFlash, redirect, not found etc.
Jeśli tworzysz serwis, pomyśl najpierw o interfejsie -np. dla repozytorium. To ułatwia podmianę m.in. w testach. Uważaj co wstrzykujesz. Nie wstrzykuj zbyt wiele i nie wstrz. kontenera.
Prostym i często tworz. serwisem są repozyt. Warto je tak definiować i warto tworzyć dla nich interfejsy.
Uwaga na wrzucane logiki do encji. Zwykle nie powinna się znaleźć. Przykład: generowanie slug; sprawdzanie czy użytkownik ma do czegoś prawa.
Do ładowania danych startowych do bazy używaj fixtures. Będzie o tym na prezentacji live
Tworz klasy dla formularzy i definiuj je jako serwisy! Gdy nagle zajdzie potrzeba nowej zaleznosci, bedzie latwo ją dodać. Łatwo tez podmienic formularz.
Koniecznie przejrzyj dokumentację dost. formow - wiekszosc da sie zrobic z ich uzyciem, a czesto niepotrzebnie ludzie sobie to komplikuja.
Czasem warto zastanowic sie nad handlerami