• 1
@applicattura: Postępy w tworzonej grze? Na polskim discordzie "godociku" mam kanał na którym dzielę się postępem. Najlepiej jednak zrobisz jak zasubskrybujesz mój kanał na yt, na pewno i na nim pochwalę się gdy będzie coś konkretnego. Jeszcze nie zacząłem promocji, wciąż pracuję. Dzięki że pytasz. :)
  • Odpowiedz
Jest coś takiego jak ddd. Bardzo popularny temat ostatnio. Wiecie te szkolenia, podcasty, wywiady etc. Jak widzę informacje że rusza kolejna runda online kursu dla architektów/czystego kodu/czystej architektury i ile tysięcy ludzi już ten kurs zrobiło to naprawdę cieszę się szczęściem autorów kursu. 

Czemu? Bo większość projektów które mi się trafiły do przejęcia / poprawki / konsultacji były pisane w ddd xD Może i mają rozbudowana architekturę, nie potrzebne wzorce ale przynajmniej
  • 8
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@pkh: To co opisałeś to nie są problemy wynikające z DDD, tylko z wszechobecnego podążania za hypem w tej branży. Większość komercyjnych aplikacji nie potrzebuje mikroserwisów, CQRS, event sourcingu, event streamingu, NoSQL i różnych innych buzzwordów. Są oczywiście sensowne przypadki użycia dla każdego z nich, ale to zdecydowana mniejszość w porównaniu z tymi wszystkimi mniej lub bardziej rozbudowanymi CRUD-ami ¯_(ツ)_/¯

A samo DDD jest w rzeczywistości jedynie zbiorem pewnych dobrych
  • Odpowiedz
  • 1
@pkh: Te "projekty DDD" powstają tak:
1. Robiłem prostego CRUDa, który wymknął się spod kontroli bo n-------m narzędzi zamiast po prostu programować (easy vs simple)
2. Idę na kurs DDD bez znajomości podstaw, bo wszystkie moje błędy przed zderzeniem ze ścianą ukrywał framework.
3. Nadal nie wiem jak powinien wyglądać prosty CRUD, więc wrzucam wszystkie wzorce jakie jestem w stanie upchnąć, licząc że DDD magicznie wszystko naprawi.
4. Mam "DDD",
  • Odpowiedz
Czytam sobie "czysty kod". To ciekawe, że autor jest przeciwny używania przedrostków w nazwach, czy litery "I" na początku nazwy interfejsu. A z kolei microsoft właśnie zaleca konwencję z "I" na początku. Jakie jest wasze zdanie?

#programowanie #czystykod
  • 8
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@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
  • Odpowiedz
@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
  • Odpowiedz
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
  • 12
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@Reevo: jako programista #golang bardziej szedłbym w stronę kotlina jeśli chodzi o DDD. Głównie przez braki w systemie typów jak nulle, sum typy czy dobre wsparcie dla niemutowalnych obiektów
  • Odpowiedz
@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
  • Odpowiedz
@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
  • Odpowiedz
W wirze deadlinów i innych wymagań biznesowych, Twój kod może czasem trochę stracić na jakości. Jednak odrobinę większy wysiłek dzisiaj, zaoszczędzi Ci bólu jutro. Sprawdź, dlaczego nadal warto jest dbać o jakość pisanego kodu.

https://bulldogjob.pl/news/1054-co-znaczy-pisac-czysty-kod

#programowanie #naukaprogramowania #czystykod
Bulldogjob - W wirze deadlinów i innych wymagań biznesowych, Twój kod może czasem tro...

źródło: comment_1587047613iXwzKo4YZ2EKZpaQILmvWW.jpg

Pobierz
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

#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
  • 6
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@temokkor: Jeżeli masz program, który potrzebuje pliku konfiguracyjnego to jego położenie czytasz ze zmiennej środowiskowej, jeżeli nie ma zmiennej to z jakiegoś standardowego miejsca, np. /etc/mojprogram.conf albo ~/.mojprogram.conf.
  • Odpowiedz
@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... ¯\_(ツ)_/¯
  • Odpowiedz
@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 ʕʔ
  • Odpowiedz
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 się
  • 18
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

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 -
  • Odpowiedz
@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
  • Odpowiedz
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 pojedyncze
  • 34
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@beethoven: nie przesadziłeś, ja bym normalnie uwalał pull requesty i nie pozwolił mu merge'ować zmian. W przypadku braku porozumienia decyzje podejmuje przełożony lub kierownik projektu. Generalnie nie staraj się także atakować jego, tylko konkretne zmiany z podaniem konkretnych argumentów.
  • Odpowiedz
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 wypadku powinienem nazwać
  • 10
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@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
  • Odpowiedz
@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
  • Odpowiedz
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ą.
  • 10
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@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
  • Odpowiedz
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.”

[
  • 8
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

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
  • Odpowiedz
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.
  • 29
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@FEAofTruss: Podobnie jak w wielu innych uogólnieniach - nie należy nadinterpretować. Może się okazać, że w skrajnym przypadku będziemy pisać naprzemiennie po jednym znaku testu i kodu. ;-)
  • Odpowiedz
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ą procedurę. Z tego
  • 17
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach