Mirki, uczę się #php i zrobiłem sobie zadanko zapostowane jakiś czas temu na mirko, starając się stosować w praktyce rzeczy, których ostatnio się nauczyłem. Mógłbym prosić kogoś mądrego o rzuceniem okiem na kod (nie ma tego dużo) i wytknięcie błędów / złych praktyk?
Uwagi: Starałem się stosować MVC (ale jakby bez View, bo tu sprowadza się tylko do wyświetlenia JSONa). Pierwszy raz ever pisałem testy i nie wiem czy w obecnej postaci mają sens (na pewno brakuje paru, zwłaszcza sprawdzających bazę danych).
@rtrv: na pierwszy rzut oka: użyj php7, typowania zmiennych, za dużo ifów w controllerze, zrób z tego jakąś fabrykę/strategię. Za dużo wzorca IFLETON! Poczytaj sobię zasady SOLID, KISS, DRY
@rtrv: 1. Jako root domeny z plikiem index.php zrób katalog public projektu. Nie będziesz potrzebował tych sztuczek z defined("DIRECT_ACCESS") OR exit;. Skrypt niech sobie zrobi require_once dirname(__DIR__) . '/src/bootstrap.php'; czy co tam mu trzeba. 2. Kontrolery nie są od przetwarzania danych - to jest część aplikacji, którą byś bez problemu wymienił w przypadku innego sposobu ich dostarczania (komenda+parametry z konsoli, import z pliku, pobrane wcześniej z innego serwisu...itp). W tym
@rtrv: Jak pisał kolega wyżej, wyrzuć kod poza public. A nawet jeśli ktoś odpali skrypt klasy bezpośrednio z poziomu www, to co z tego? Przecież nic się nie wykona, nie zainicjuje. Skrypt się zakończy. Nic nie wycieknie. Więc niepotrzebnie to wrzucasz i powodujesz, że kod nie będzie re-używalny w innym projekcie, który takiej stałej nie definiuje. Do tego zasada: skinny controllers, fat models. Tylko model to nie sama
@rtrv: Jest postęp. Dobry kierunek! ( ͡°͜ʖ͡°) Nie mam czasu przeglądać wszystkiego, ale tak po łebkach to bym sugerował wyrzucić zawartość tych złożonych funkcji kontrolerów do serwisów. Kontroler im mniejszy tym lepszy. Najlepiej, żeby wywoływał metodę jakiegoś serwisu. Wtedy jak będziesz chciał przenieść swój projekt na jakikolwiek framework, to zrobisz to w mig kopiując wywołania metod serwisu do akcji kontrolera, zamiast całe ciała funkcji, parametry,
Bardzo proszę o ciepłe słowa. Zawaliłem uczelnie, mam długi i jestem na najniższym punkcie życia, boję się jutro obudzić. Jeśli ktoś z szerszą perspektywą może popisać byłbym wdzięczny.
[[Link do githuba]](https://github.com/retrowaver/Transiter)
Uwagi: Starałem się stosować MVC (ale jakby bez View, bo tu sprowadza się tylko do wyświetlenia JSONa). Pierwszy raz ever pisałem testy i nie wiem czy w obecnej postaci mają sens (na pewno brakuje paru, zwłaszcza sprawdzających bazę danych).
#naukaprogramowania #codereview #programowanie
użyj php7, typowania zmiennych, za dużo ifów w controllerze, zrób z tego jakąś fabrykę/strategię.
Za dużo wzorca IFLETON!
Poczytaj sobię zasady SOLID, KISS, DRY
header('Content-Type: application/json');
echo json_encode($json);
wynoś takie rzeczy to metod osobnych, najlepiej jakąś własną klasę Response utwórz
CO TAM ROBI STFU OPERATOR!
do słownika jakiegoś, jako const
https://github.com/retrowaver/Transiter/blob/master/src/Controller/ReportsController.php#L83
no prosze cie.. poczytaj o DateTimeInterval
Do tego, deklarujesz
$day
przy każdym wykonaniu pętlihttps://github.com/retrowaver/Transiter/blob/master/src/Controller/TransitsController.php#L54-L62
takiego potworka jeszcze nie widziałem :D
https://github.com/retrowaver/Transiter/blob/master/src/Model/GoogleApiModel.php
To nie powinien być model, bardziej jakiś serwis
i po raz kolejny... formatowanie.... ヽ( ͠°෴ °)ノ
https://www.php-fig.org/psr/
@rtrv: I jakby bez Model ( ͡° ͜ʖ ͡°) Całą logikę z kontrolerów wynieś do osobnych serwisów.
I formatowanie kodu ( ͡° ʖ̯ ͡°)
1. Jako root domeny z plikiem
index.php
zrób katalogpublic
projektu. Nie będziesz potrzebował tych sztuczek zdefined("DIRECT_ACCESS") OR exit;
. Skrypt niech sobie zrobirequire_once dirname(__DIR__) . '/src/bootstrap.php';
czy co tam mu trzeba.2. Kontrolery nie są od przetwarzania danych - to jest część aplikacji, którą byś bez problemu wymienił w przypadku innego sposobu ich dostarczania (komenda+parametry z konsoli, import z pliku, pobrane wcześniej z innego serwisu...itp). W tym
@rtrv: Jak pisał kolega wyżej, wyrzuć kod poza public. A nawet jeśli ktoś odpali skrypt klasy bezpośrednio z poziomu www, to co z tego? Przecież nic się nie wykona, nie zainicjuje. Skrypt się zakończy. Nic nie wycieknie. Więc niepotrzebnie to wrzucasz i powodujesz, że kod nie będzie re-używalny w innym projekcie, który takiej stałej nie definiuje.
Do tego zasada: skinny controllers, fat models. Tylko model to nie sama
Link / link do poprzedniej wersji
@#!$%@?: @progreso: @h0lend9r: @qwelukasz: @Benzen: @MQs: @Jare_K:
Komentarz usunięty przez autora
Nie mam czasu przeglądać wszystkiego, ale tak po łebkach to bym sugerował wyrzucić zawartość tych złożonych funkcji kontrolerów do serwisów. Kontroler im mniejszy tym lepszy.
Najlepiej, żeby wywoływał metodę jakiegoś serwisu. Wtedy jak będziesz chciał przenieść swój projekt na jakikolwiek framework, to zrobisz to w mig kopiując wywołania metod serwisu do akcji kontrolera, zamiast całe ciała funkcji, parametry,