[FEAofTruss]

21/100 dni z książką

“Nie zwracamy null.
Nie zliczę widzianych przeze mnie aplikacji, w których niemal każdy wiersz kodu zawierał test wartości null. [...] Gdy zwracamy wartość null, w rzeczywistości tworzymy sobie dodatkową pracę i powodujemy problemy w funkcjach wywołujących. W takich przypadkach brak jednego testu wartości null powoduje, że aplikacja wymyka się spod kontroli.”

[Więcej infomacji]


#feaoftruss #czystykod #programowanie #programista15k #webdev #gamedev

Podobało się? To zaplusuj i zapisz się do wołania (link w stopce)

************

[Chcesz być wołany?]

[krasnoludkolo]

@ZasilaczKomputerowy czyli musisz założyć że każda metoda w cały projekcie może zwrócić nulla czyli sprawdzac wszystko zawsze. Jak widzisz że metoda zwraca optional to bez czytanie doca/kodu wiesz że musisz go obsłużyć

[ZasilaczKomputerowy]

@krasnoludkolo: No zależy z jaką aplikacją pracujesz. Jeżeli klepiesz formularze to może założenie opa ma jakieś tam uzasadnienie. No, ale przypuśćmy są pola nullable, bo nie musisz ich ustawiać. To co, do bazy lepiej przekazać pusty string? Czy pusty string jest tożsamy z null? Jest sporo filozoficznych pytań które moim zdaniem są zależne od tego jak projektujesz aplikacje i jaki ma charakter. Null to narzędzie którego możesz użyć lub nie. W

[krasnoludkolo]

@ZasilaczKomputerowy dlaczego nie możesz ich ustawić?

[ZasilaczKomputerowy]

@krasnoludkolo: dlaczego nie mogę ustawić czego?

[krasnoludkolo]

@ZasilaczKomputerowy mówisz że nulle do bazy. Możesz też używać osobnego modelu do bazy, a osobnego do logiki

[ZasilaczKomputerowy]

@krasnoludkolo: Czyli potrzebujesz jeszcze jednej warstwy która jest pomiędzy bazą a logiką, żeby przetłumaczyła model bazowy na logiczny. Tracisz czas na ustawianie czegoś takiego, tracisz performance podczas przepływu danych między warstwami.

[krasnoludkolo]

@ZasilaczKomputerowy nie nazwał bym tego warstwą. Starczy żeby obiekty biznesowe umiały się tworzyć z klas bazodanowych bo rzadko kiedy są tam potrzebe jakiekolwiek działania

[ZasilaczKomputerowy]

@krasnoludkolo:

obiekty biznesowe umiały się tworzyć z klas bazodanowych

Same się nauczą? To jest to o czym pisałem i jest to jak najbardziej warstwa. Przykładem jest hibernate i jakieś DTO/DAO. To szkielet aplikacji pod logiką i tutaj są decyzje projektowe czy pole może być null, czy jest to tożsame z tym że w bazie jest null i tym podobne.

[krasnoludkolo]

@ZasilaczKomputerowy a to nie da się pisać logiki aplikacji niezależnie od infrastruktury? Architektura heksagonalna, DDD itp?

[Lewo]

@FEAofTruss: uczę się dopiero, jak powinno się tego unikać? Optionali jeszcze nie ogarniałem, znam tylko wyjątki. Trzeba dać wyrzucanie wyjątku jeśli miałoby zwrócić null, żeby wymusić jego obsługę? Trochę więcej kodu, ale chyba tak to jest jeśli chce się zapewnić obsługę błędów.

[ZasilaczKomputerowy]

@krasnoludkolo: Da się, ale to narzut na wydajność. Im bardziej uniezależniasz się od infrastruktury tym więcej warstw dokładasz.

[krasnoludkolo]

@Lewo to szybko ogarnij optionale ;)

[SwordPL]

@ZasilaczKomputerowy:

To normalnie nie masz tej warstwy? ¯\(ツ)_/¯ Bo taki wniosek można wyciągnąć, że wyciągasz sobie rowy i na nich operujesz, by odpowiedzialności za konwersję w obiekt dziedziny nie mieć dla mitycznego performance'u, którego wąskim gardłem i tak będzie I/O ¯\(ツ)_/¯

Zamiast nullowania pola wtedy wystarczy mapować do Some(x) | None i tyle. I wykorzystywać zalety Option(al) dalej w aplikacji. Jeżeli null w polu != null w bazie to

[krasnoludkolo]

@ZasilaczKomputerowy narzut tak mały że poza rzadkimi przypadkami nie ma znaczenie, tak samo jak nie ma znaczenia czy używasz LinkedList czy ArrayList itp

[krasnoludkolo]

@ZasilaczKomputerowy chyba że architektura 'encja na twarz i pchasz' ( ͡º ͜ʖ͡º)

[s.....a]

: I dzięki temu nie robimy testu wartości? O.o

@Vetinari: tak, tzn robimy ich znacznie mniej (tam gdzie są niezbędne).

Powiedzmy że masz aplikację która ma 50 metod zwracających Object które wywoływane są gdzieś 100 razy.
Jeżeli chcesz zagwarantować poprawność kodu teoretycznie powinieneś sprawdzić wartość null ok. 100 razy (za każdym wywołaniem dowolnej metody zwracającej Object, w końcu każda może zwrócić null).

Ale teraz przyszedł senior engineer i kazał w projekcie

[krasnoludkolo]

@sakfa dokładnie tylko tylko ostrożnie bym robił z tym isPresent

[s.....a]

@krasnoludkolo: też nie lubię isPresent, ale to najlepsza droga na bezinwazyjny refaktor istniejącego kodu (zamieniamy return null; i (if x!=null) na return Optional.empty() i (if x.isPresent()) . I ładnie nam wyskakują w kompilatorze na czerwono wszystkie miejsca w których zapomnieliśmy sprawdzić null elegancko utwierdzając nas w przekonaniu że refaktoring to był dobry pomysł :)

i czasami jest jednak czytelniejsze niż ifPresent czy map

[ZasilaczKomputerowy]

@krasnoludkolo: Jak masz aplikację która obsługuje bardzo dużo klientów, a infrastruktura jest taka, że normalnie wytrzymuje, ale są momenty natężonego ruchu parę razy do roku to wtedy wszystko ma znaczenie. Tym bardziej jak jest faza optymalizacji już zrobionych funkcjonalności. Nie wiem czy pracowałeś już z profilerami, indexami i tak dalej, ale mi się zdarzało i tylko mówię jakie są wnioski.

@SwordPL: Dla mnie te Optionale produkują więcej mniej czytelnego kodu,