URL shortener - Symfony 4. Opcje

[smk]

Witam.
Prosiłbym Was o code review aplikacji do skracania adresów Czym więcej feedbacku, tym lepiej!
https://github.com/selfmadeking/URL-shortener-Symfony-4

[Pyton_000]

Nie ma takiej sytuacji że nie da się tego opisać jednolitym typem danych. IMO kwestia znalezienia rozwiązania.

[athabus]

Nie ma takiej sytuacji że nie da się tego opisać jednolitym typem danych. IMO kwestia znalezienia rozwiązania.

Ale uważasz, że zawsze jest sens walczyć o silne typowanie? PHP to jest język dynamiczny i KIEDY MA TO SENS warto korzystać z możliwości, które daje. O ile jestem zazwyczaj przeciwnikiem funkcji zwracających wszystkie możliwe typy danych, to czasami na to po prostu sens - np. wspomniana konfiguracja, która może przechowywać zarówno typy proste jak i obiekty. To bardzo generyczny obiekt i MZ nie ma sensu dla idei walczyć o typowanie. Oczywiście jeśli się mylę, to chętnie poznam argumenty i jakieś sensowne podejście do tego tematu w PHP.

Zaciekawił mnie kolejny wątek - czyli null (+ wartości domyślne, z którymi się poniekąd wiąże). Co do zasady jestem zwolennikiem, że funkcja nie powinna zwracać null, gdy jest to możliwe. Sztandarowy przykład - wolę zwrócić pusta tablicę niż null. Oczywiście znów nie zawsze jest sens o to walczyć i w praktyce mimo wszystko często stosuję null (zamiast np. stosować null object), ale zawsze 2 razy się zastanawiam, czy nie da się tego rozwiązać lepiej.
Exceptiony MZ zazwyczaj nie są dobrym wyjściem - Exception jak sama nazwa wskazuje powinien obrazować zjawisko wyjątkowe, a np. brak odczytanych rezultatów z bazy zazwyczaj nie jest zjawiskiem wyjątkowym - np. brak produktów w sklepie w danej kategorii. Oczywiście może takim być - np. loguje się użytkownik i nagle się okazuje, że nie ma tabeli z jego ACL'ami, a logika aplikacji zakłada, że każdy użytkownik ma tam jakieś wpisy - wtedy oczywiście Exception jest ok.

Ostatnio też miałem dość ciekawą rozmowę na temat domyślnych wartości argumentów w funkcjach. Do tej pory stosowałem je na potęgę z 2 głupich powodów:
- mniej pisania w kodzie klienckim
- w czasie refactoringu, gdy dochodził parametr stosowałem wartość domyślną aby nie trzeba modyfikować kodu klienckiego

Rozmowa otworzyła mi oczy, że głupio robiłem. Po pierwsze kod kliencki musi wiedzieć co chce zrobić i im mniej tam przerzucania odpowiedzialności na "inteligencję" swoich klas/funkcji tym lepiej, bo pomaga to zapobiegać efektom ubocznym. Przeróbka koda klienckiego przy refactoringu dzisiaj też jest prosta, więc nie jest to argument za stosowaniem wartości domyślnych. Przede wszystkim jednak ciekawym doświadczeniem było zaprzestanie używania wartości domyślnych w swoim kodzie. Po 2-3 dniach okazało się, że w 95% przypadków można pozbyć się tego brzydactwa.

Dlatego ogólnie na dzisiaj moja opinia jest taka - null / wartości domyślne powinno się stosować ale z umiarem. Zawsze się warto zastanowić czy robimy to z wygody, czy z realnej potrzeby.

Ogólnie muszę przyznać, że dużo w moim kodzie poprawiło stosowanie się do zasady YAGNI i polubienie się z refactoringiem. Wiele problemów typu domyślne wartości parametrów często się same rozwiązują, bo np. zakładamy, że dzisiaj co prawda parametr będzie zawsze taki sam (i dlatego dajemy u default value) ALE KIEDYŚ to się zmieni. W praktyce okazuje się, że w 9 na 10 sytuacji to się nigdy już nie zmieni, albo funkcję przepiszemy jescze 3 razy zanim się zmieni i zostajemy z parametrem, który w ogóle nie jest do niczego potrzebny.