@maestrozo: moje zdanie jest takie, że kod piszesz po to (tzn oprócz spełnienia wymagań biznesowych ;)) żeby się go dobrze rozumiało, czytało i debugowało. Jeśli stosowanie przedrostków pomaga to stosujcie, jeśli nie to nie. Sam nie używam notacji węgierskiej, ale w niektórych językach jakoś mi się prywatnie przyjęło, że interfejsy zaczynam od małej literki i. Ale nie mam też problemu, kiedy zespół tego nie robi - IDE i tak to złapie
@maestrozo: Nazwa określa byt!


Jak mam obiekt Samochód, to kiedy obiekt Kierowca wywoła na nim metodę przyspiesz(), to oczywiste jest, że wtedy ukryte pole w obiekcie Samochód powinno nazywać się Silnik, a nie SilnikInterface.

Tak więc jak chcę mieć silnik, to będzie to klasa Silnik. A jak chcę mieć różne silniki to będzie to interface Silnik, a jego różne implementacje to będą SilnikBenzynowy, SilnikDiesel
W jakim języku najlepiej nauczyć się zasad DDD, CleanArchitecture, oraz generalnie biznesowych praktyk jakości kodu?

Pracowałem zawodowo C++/Lua/Dart (6 lat w zawodzie), ale w żadnej z tych technologii nie mogę znaleźć szerszych źródeł na temat 'enterprise level' architektury i jasnych standardów programowania. Z książek w stylu CleanArchitecture B. Martina niewiele da się wyciągnąć, ponieważ omawiają ogólne pojęcia, a chciałbym poznać konkretne biznesowe praktyki, konwencje nazewnictwa, najlepiej przeczytać kilka produkcyjnych, otwartoźródłowych implementacji tych
@Reevo: Zacznij od niebieskiej książki evansa, bo popełniasz największy błąd początkującego w DDD czyli podchodzisz do tych patternow zbyt technicznie i zerojedynkowo. To nie chodzi o to by wydzielać na siłę wzorce typu VO, Entity w kodzie, tylko by za pomocą zestawu przedstawionych technik stworzyć jak najbardziej dokładny model biznesu który probujemy odwzorowac w naszym kodzie. Od siebie polecam podcast bettersoftwaredesign.pl
@programista4k:
- używania mutowalnych zmiennych do zwracania wartości (przykładowo count). Zamiast takiego zwracaj wartość w miejscu
- w getResponses pętlę for można zamienić na map()
- nie wiem do końca, czy to aby na pewno nie Scala, bo dawno w tym nie pisałem, ale chyba powinieneś używać kolekcji z Scali a nie z Javy?

Inne rzeczy ciężko wyłapać, bo za mało kodu
#programowanie #wzorceprojektowe #programista15k #czystykod

Aktualnie zastanawiam się nad takim problemem, jak i gdzie powinno się umieszczać ścieżki do plików z których korzystają programy które piszę. Znam dwa sposoby. Pierwszy to hardkodowanie ich tam, gdzie z nich korzystam, czyli np.

string path = "C:\folder\plik.jpg";

Jest to sposób zły, gdyż po skompilowaniu programu nie można już zmienić ścieżki do pliku.

Drugi sposób, który uważam za lepszy to umieszczanie ich w plikach typu json, lub
@Harriet: robi się zbyt łatwo – wprowadzanie nowych zależności musi boleć. Trzeba się nauczyć czary-mary biblioteki do DI. Ale może w Unity korzyści są większe. Jeden rabin... ¯\_(ツ)_/¯
@Harriet: Siemka! Polecam się jeszcze zainteresować korzystaniem że scriptable objectow jako prostszego typu niż mono behaviour. Ta klasa niczym sobie nie zasłużyła na traktowanie jej jako kontener na dane ʕʔ
dalszy ciąg tego wpisu. W skrócie "pożarłem się z 'senior devem' o czystość kodu."

Mój kolega z zespołu, senior dev, popełnił w kodzie parę nowych metod, o długości ok. 20 linijek, w których wymieszał najróżniejsze rzeczy typu tworzenie requesta, obsługa response'a, error handling na różnych poziomach (network, http, zawartość response'a), mapowanie, itd. Na review mu podpowiedziałem, że skoro metoda robi To, To i jeszcze To, to powinien powydzielać do mniejszych metod co
Będę uwalał wszystkie pull-requesty i nie obchodzi mnie czy będziemy mieć przez to opóźnienia.


@beethoven: Jesteś najgorszym typem programisty. No offence. Koleś dał bardzo sensowny argument a ty sie rzucasz jakby klepał kod bezmyślnie.

Kilka lat pracy z devami z USA nauczyło mnie pragmatycznego podejścia i tego że kod ma działać, dać sie rozwijać i zarabiać. To czy metoda ma 20 linijek czy 5 nie ma abosultnie żadnego znaczenia - ważne
@beethoven: brzmisz jak jakiś junior, co naczytał się zbytnio teorii a teraz kozaczy. W programowaniu sztuką jest podejmowanie masy kompromisów - wiele dobrych praktyk jest niemożliwe do zastosowania np: przez to jak został stworzony framework i jak zostały narzucone metody. Dobry programista rozumie, że nie zawsze warto podążać ślepo za wzorcami i czystym kodem, bo w wielu przypadkach po prostu się nie da. Mi np wiele razy zwracają uwagą, że zamiast
Ostatnio w pracy pożarłem się z 'senior devem' o czystość kodu.

Mamy nowo utworzony zespół składający się z ludzi z już istniejących zespołów, ale którzy nigdy bezpośrednio razem nie pracowali wcześniej. Jednym z nich jest gość, który jest kilka lat starszy ode mnie i ma jakąśtam wiedzę, ale nie przywiązuje aż tak dużej wagi do czystego kodu. Zwróciłem mu uwagę, że nie powinien przekazywać do funkcji w innej klasie całego obiektu, tylko
Mam obiekt którego jedyna publiczna metoda ma za zadanie coś zwrócić. Ciało, działanie nieistotne.
Mam funkcję walidującą dane wejściowe.

Jak zgodnie ze sztuką, z zasadami czystego kodu powinienem osadzić ciało funkcji (kilka linijek, praktycznie nie do rozbicia), w stosunku do walidacji danych wejściowych? Mam narzuconą nazwę metody publicznej, mam określone co ona ma zwracać.

Chciałbym przenieść ciało funkcji do osobnej metody i ją po prostu wywołać po walidacji, jednak jak w takim
@Jurix: @gzkk: Odwrócenie warunku to zły pomysł. Powinieneś wychodzić z metody najszybciej jak się da. Czyli masz:
if(!Validate()) {
throw exception;
}
// bez else bo nie potrzebne
standardowa logika()

Dodatkowo mnożenie metod w zakresie 1 klasy tylko po to żeby pogrupować kod w jakieś skrawki,w które potem będą i tak procedularnie wywoływane max 1 raz wiele nie daje poza tym, że musisz potem po tych metodach skakać.
Przykład:
prosto
@Jurix: Największym smrodkiem jest tu na razie return false na końcu - po co cokolwiek zwracać jeśli każde poprawne dane (nie rzucające wyjątku) dają z góry znany wynik? Inne opcje do poprawy to wspomniane wywalenie else i zostawienie samego early exit, prywatna metoda rzucająca wyjątek od razu zamiast przypisywania zmiennej valid i sprawdzania warunku później... W zasadzie to kwestia konwencji, która powinna być spójna i nie ma sensu wymyślać lepszej w
25/100 dni z książką

“Czyste testy powinny spełniać pięć zasad [...]:
Szybkie [...] Gdy testy działają powoli, nie chcemy ich uruchamiać zbyt często.
Niezależne [...] Jeśli testy zależą od siebie, to gdy nie uda się pierwszy test, powstaje kaskada awarii, co utrudnia diagnozę i ukrywa awarie na niższym poziomie.
Powtarzalne [...] Jeżeli nasze testy nie są powtarzalne w każdym środowisku, to zawsze będziemy mieli wymówkę, gdy się nie powiodą.
Samokontrolujące się. Testy
@FEAofTruss: Jak z wieloma rzeczami się zgadzam tak bardzo z gloryfikacją TDD mam problem.
Prawda jest taka, że test-first ma swoje zalety i test-last ma swoje (zwłaszcza, gdy mówimy o czymś zupełnie nowym, gdzie wymagania są bardziej niepewne, niż prawo podatkowe w Polsce ¯\_(ツ)_/¯).

Co więcej polecam lekturę poniższego papera :)
https://www.researchgate.net/publication/315743099_An_Experimental_Evaluation_of_Test_Driven_Development_vs_Test-Last_Development_with_Industry_Professionals

A co do reszty... Jakby tylko zawsze tak było, że testy są niezależne, powtarzalne i szybkie. Fajnie by było
24/100 dni z książką


“Istnieje szkoła programowania twierdząca, że każda funkcja testowa w JUnit powinna mieć jedną instrukcję asercji. Zasada ta może wydawać się drakońska [...] Uważa, że zasada jednej asercji jest dobrą wskazówką. [...] Jednak nie obawiam się umieszczać więcej niż jednej asercji w teście. Uważam, że możemy jedynie stwierdzić, iż liczba asercji w teście powinna być zminimalizowana.
Lepszą zasadą dotyczącą testów jest obejmowanie jednej koncepcji w każdej funkcji testowej.”

[
via Wykop Mobilny (Android)
  • 3
@Przegrywek123: To jest ciekawe. Ogólnie rzecz biorąc inna część książki pisze o różnicy między obiektem, a strukturą. Jak testujesz 5 pól, a nie zachowanie to testujesz strukturę. A strukturę możesz testować przez equals jedną asercją. Bo co innego testować w POJO? Settery i konstruktor? xD

Po drugie, Uncle Bob pisze: testuj jeden koncept - jedno zachowanie w danych warunkach. Jeżeli metoda zmienia 2 pola w obiekcie to sprawdź stan tylko tych
23/100 dni z książką

Trzy prawa TDD

“Możemy zdefiniować trzy następujące prawa:
Nie można zacząć pisać kodu produkcyjnego do momentu napisania niespełnionego testu jednostkowego.
Nie można napisać więcej testów jednostkowych, które są wystarczające do niespełnienia testu, a brak kompilacji jest jednocześnie nieudanym testem.
Nie można pisać większej ilości kodu produkcyjnego, niż wystarczy do spełnienia obecnie niespełnionego testu.”

[Więcej infomacji]


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

Podobało się? To zaplusuj i
22/100 dni z książką

Wczoraj rozgorzała gorąca dyskusja - dzisiaj temat nawiązujący.

Nie przekazujemy null.
Zwracanie wartości null z metod jest niedobrą praktyką, ale przekazywanie wartości null do metod jest jeszcze gorsze. O ile nie korzystamy z API, które oczekuje wartości null, i o ile mamy taką możliwość, powinniśmy unikać przekazywania null we własnym kodzie. [...] W większości języków programowania nie istnieje dobra metoda obsługi wartości null przypadkowo przekazywanych przez wywołującą
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
@FEAofTruss: Ta książka trochę przesadza w drugą stronę. W jaki sposób zwrócisz błąd wykonania (alternatywa dla nulla)?

Wyjątek? Jeszcze więcej kodu do złapania i zwijanie stosu.

Optional? Pole w obiekcie? Nadal potrzebujesz ifa.

Zwracanie pary obiektów? Nadal potrzebujesz ifa i na dodatek paskudnie wygląda.

Bardzo często jeżeli coś zwraca null to znaczy, że coś się nie udało. Jeżeli coś się nie udało to zwykle nie olewa się takiej sytuacji tylko potrzebujemy
@FEAofTruss swoją drogą należy według mnie rozróżniać wyjątki od błędów Wyjątek- sytuację wyjątkowe jak brak internetu, brak połączenia z bazą itp i je obsługiwać normalnie Exceptionami Błędy - normalne sytuacje takie brak użytkownika, niedozwolona akcja itp i je już powinno według mnie się obsługiwać normalnie z poziomu kodu a nie jakieś magiczne goto w postaci wyjątku. Pomocne tu są chociażby Either z vavra