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
@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
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
@nilphilus nie chodzi mi o sytuację jak mówisz że jeden moduł pobiera sobie z drugiego coś (tak jak mowisz) tylko o to gdzie z obiektu dobierasz do obiektu gdzie dobierasz się do obiektu na którym potem coś robisz, jeśli te gety nie są jakimiś operacjami biznesowymi, a tylko getterami na pola
17/100 dni z książką

“A zatem powinniśmy tworzyć krótkie wiersze. Stare ograniczenie Holleritha do 80 znaków jest restrykcyjne [...] Ja staram się nie przekraczać długości 120 znaków.”


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

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

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

[Chcesz być wołany?]
16/100 dni z książką

“Jeżeli jedna funkcja wywołuje inną, powinny być one położone blisko siebie, a funkcja wywołująca powinna być umieszczona powyżej wywoływanej, o ile jest to możliwe.”


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

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

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

[Chcesz być wołany?]
14/100 dni z książką

“Niewiele jest praktyk tak nieprofesjonalnych, jak zakomentowanie kodu: Nie rób tego!

InputStreamResponse = response = new InputStreamResponse();
response.setBody(formatter.getResultStream(), formatter.getByteCount());
//InputStream resultStream = formatter.getResultStream();
//StreamReader reader = new StreamReader(resultStream);



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

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

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

[Chcesz być wołany?]
13/100 dni z książką

/*Dodane przez Ricka*/
Systemy kontroli wersji świetnie nadają się do zapamiętywania, kto (i kiedy) dodał określony fragment. Nie ma potrzeby zaśmiecania kodu tymi małymi dopiskami. Można uważać, że tego typu komentarze będę przydatne do sprawdzenia, z kim można porozmawiać na temat danego fragmentu kodu. Rzeczywistość jest inna - zwykle zostają tam przez lata, tracąc na dokładności i użyteczności.”


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

Podobało się? To
12/100 dni z książką

“W wielu przypadkach kod mógłby zupełnie obejść się bez komentarzy [...] Co wolelibyśmy zobaczyć? To:

if((employee.flags & HOURLY_FLAG) && (employee.age > 65))
czy to:

if(employee.isEligibleForFullBenefits())


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

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

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

[Chcesz być wołany?]
@FEAofTruss: A mi się wydaje, że to:

if((employee.flags & HOURLY_FLAG) && (employee.age > 65))

może być ciałem metody employee.isEligibleForFullBenefits()

Można też nie bawić się w takie rzeczy, że klasa employee która przechowuje zapewne informacje o pracownikach jest odpowiedzialna też za sprawdzanie ich, a napisać zgrabny interfejs który będzie się zajmował takimi rzeczami ( ͡º ͜ʖ͡º)
10/100 dni z książką

“Funkcje powinny coś wykonywać lub odpowiadać na jakieś pytanie, ale nie powinny robić tych dwóch operacji jednocześnie. [...] Jako przykład weźmy następującą funkcję:

Public boolean set(String attribute, String value);
Lepszym rozwiązaniem jest oddzielenie polecenia od zapytania, dzięki czemu niejasność nie występuje:

if(attributeExists(“username”) {
setAttribute(“username”, “unclebob”);
}



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

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

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

[Chcesz
@nilphilus: Jesli nawet nie do bazy to i tak przykład jest słaby
Coś jak:
if(zmienna == true ) zmienna = false;

jest masa funkcji które coś robią i coś zwracają i nie uważam że to nie jest czytelne.

BTW
Jesli już jesteśmy w temacie na temat tego co powinna robic funkcja to osoby początkujące czesto mają problem z takim czymś jak

list.Clear(); //modyfikuje[czyści] liste
name.Replace("old","new"); //nie modyfikuje obiektu, tylko zwraca zmodyfikowany
9/100 dni z książką

“Idealną liczbą argumentów dla funkcji jest zero (funkcja bezargumentowa). [...] Należy unikać konstruowania funkcji o trzech argumentach. [...] Więcej niż trzy argumenty wymagają specjalnego uzasadnienia - a nawet wtedy takie funkcje nie powinny być stosowane”


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

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

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

[Chcesz być wołany?]
@AnonimoweLwiatko: bo im więcej argumentów tym więcej zależności. Chociaż ja bym nie powiedział że 0 to idealna liczba, bo skads przecież dane trzeba mieć. Oczywiście pomaga DI i korzystanie z tego co wstrzyknieto ale jednak. No ale już co do 3 to się zgadzam, lepiej unikać. No i unikac bool w argumentach bo to prawie na 100% oznacza że w środku jest if który zmusza funkcje do dzialania zupełnie inaczej
8/100 dni z książką

“Warto zapamiętać zasadę Warda: Wiemy, że pracujemy na czystym kodzie, jeżeli każda procedura okazuje się taką, jakiej się spodziewaliśmy. Połową sukcesu w osiągnięciu tego stanu jest wybór dobrych nazw dla małych funkcji wykonujących jedną operację. Im mniejsze i lepiej ukierunkowane są funkcje, tym łatwiej wybrać dla nich opisową nazwę.”


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

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

************
7/100 dni z książką

“Funkcje nie powinny mieć 100 wierszy długości. Funkcje powinny mieć właśnie nie więcej niż 20 wierszy.
[...]
Poziom wcięć w funkcji nie powinien przekraczać dwóch.
[...]
FUNKCJE POWINNY WYKONYWAĆ JEDNĄ OPERACJĘ. POWINNY ROBIĆ TO DOBRZE. POWINNY ROBIĆ TYLKO TO.


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

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

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

[Chcesz być wołany?]
FUNKCJE POWINNY WYKONYWAĆ JEDNĄ OPERACJĘ. POWINNY ROBIĆ TO DOBRZE. POWINNY ROBIĆ TYLKO TO.”


@FEAofTruss: W skrócie SRP.

Jednak jest jedno "ale". W uproszczeniu powiem, że skoro funkcja ma 20 linii, to znaczy, że wykonuje 20 rzeczy (trzeba odliczyć nawiasy itp, ale upraszczam). To powoduje często błędne zrozumienie SRP i przesadzone rozdrobnienie kodu.
Więc jak ma robić jedną? Otóż brakuje tutaj pojęcia poziomu abstrakcji. Funkcja (lub ogólnie również klasa, metoda, pakiet itd)
6/100 dni z książką

“Ludzie często nie zmieniają nazw elementów z obawy, że inni programiści będą mieli zastrzeżenia. [...] Prawdopodobnie zaskoczymy kogoś, gdy zmienimy nazwę, podobnie jak w przypadku innych usprawnień kodu, ale nie powstrzymuje to nas przed dokonywaniem zmian.”


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

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

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

[Chcesz być wołany?]
@FEAofTruss: @chopak: zmienianie nazw modułów czy jakichś podstawowych klas oczywiście stworzy bałagan i tego lepiej nie robić.
Ale poprawianie np. zmiennych które są widoczne w jednym miejscu jak najbardziej jest ok. W większych projektach wiele klas ruszanych jest nawet raz na kilka miesięcy, więc po zmianie nazwy zmiennej nikt nie będzie tym później zaskoczony bo i tak nie będzie pamiętał co tam było, ani nie będzie co chwila zmian w