Cześć 

Spring sprawia, że programowanie w Javie jest szybsze, łatwiejsze i bezpieczniejsze dla każdego. Spring skupia się na szybkości, prostocie i produktywności, dzięki czemu stał się najpopularniejszym na świecie frameworkiem Java.
spring.io

Cytat powyżej doskonale opisuje znaczenie Springa w dzisiejszym świecie (2020). Spring jest wszędzie – niezależnie od tego, czy chodzi o streaming telewizji, samochody z dostępem do internetu, zakupy online, czy też niezliczone inne innowacyjne rozwiązania. Dzięki swojej elastyczności, ilości projektów jakie rozwija (w sposób zadowalający programistów na całym świecie) oraz społeczeństwa (community) jakie zostało wokół niego stworzone, z pewnością można stwierdzić, że Spring Framework jest częścią obecnego świata.

Należy jednak pamiętać, że nadal jest to tylko framework a rynek bywa nieprzewidywalny. Co w przyadku, kiedy okaże się, że Spring jest już przeżytkiem? Czy będziesz musiał przepisać całą aplikację od zera tylko dlatego, że pozwoliłeś się mu uwięzić?

W dzisiejszym artykule:

• Elastyczność a kontrola
• Gdzie leży granica?
• Technika obrony przed oddaniem władzy w ręce Springa

Elastyczność a kontrola

Spring Boot, czyli jeden z podprojektów springa, który drastycznie poprawia produktywność. Pozwala na postawinie aplikacji od zera za pomocą dosłownie kilku kliknięć przy pomocy Spring Initializr. W dobie, kiedy duży nacisk jako IT kładziemy na architekturę, gdzie każdy moduł ma konkretną odpowiedzialność (mikroserwisy), Spring Boot jest świetnym wyborem bo dostarcza nam przygotowany projekt, który musimy tylko odpowiednio zakodować.

Skupiam się szczególnie na projekcie Spring Boot’owym, ale sprawa zabetonowania kodu frameworkiem równomiernie dotyczy każdego innego projektu. Generalnie chodzi o komponenty, gdzie w dużej mierze polegamy na sercu Springa – IoC, AOP. Zyskujemy dzięki temu dużą elastyczność bo możemy szybko dostarczać funkcjonalności, które chce biznes, ale jednocześnie płacimy za to tym, że polegamy na mechanizmach frameworka.

Czy jest z tym jakiś problem? Dopóki wszystko działa to nie. Problem pojawia się gdy coś przestaje działać. Wtedy okazuje się, że z 10-osobowego zespołu, jedna… może dwie osoby, mniej lub więcej wiedzą co dzieje się pod spodem (dobrze jeżeli chociaż tyle osób się znajdzie) i umieją rozwiązać problem. To nie znaczy, że mamy wywalić wszystkie frameworki z naszego kodu i napisać je samemu. Efekt końcowy będzie taki sam. Osoby, które napiszą daną rzecz za jakiś czas są nieobecne – inny projekt / zmiana pracy / emerytura.

Gdzie leży granica?

Niezaprzeczalnym faktem jest, że w znacznej większości przyapadków nie będziesz przepisywać funkcjonalności, które dostarczają Ci zewnętrzni dostawcy (biblioteki / frameworki). Dobrze byłoby wiedzieć co dzieje się pod spodem danego komponentu, jakie są kompromisy jego użycią – co zyskujemy a co tracimy. Niestety, znajomość, co dzieje się pod spodem, często nie jest adekwatna. Żeby nie teoryzować już za wiele i przejść do konkretów, to moim zdaniem granice wyznacza czas.

Załóżmy, że na projekcie używasz Spring Boota i działasz w branży księgowości. Dostałeś zadanie aby dodać nową funkcjonalność obsługi subskrypcji (użytkownicy co miesiąc płacą za usługę księgowości). Dla uproszczenia przyjmimy, że taka subskrypcja może być utworzona (użytkownik dołącza do planu księgowości), wyszukiwana (np. przez adminów systemu), przedłużana oraz może nastąpić rezygnacja przez użytkownika.

Na pierwszy rzut oka, typowy CRUD, ale tak nie jest. Nie będziemy wchodzić w domenę bo to nie jest temat tego artykułu, ale pozwól, że przedstawię Ci kilka argumentów utrudniających domenę:

• co z użytkownikami, którzy są stałymi klientami (zniżki / rabaty)
• użytkownicy, którzy wykupuja plan na kilka lat z góry (zniżki / rabaty)
• różne plany subskrypcji (np. najdroższy plan posiada support dostępny 24/7)
• subskrypcje w wersji trial (14/30 dni)

Znalazłoby się jeszcze kilka(naście) innych utrudnień, ale nie do tego zmierzamy. Jak byś to zaczął opędzlowywać w springu? @RestController, @Service, @Component nad każdą z klas, później dla metod, w których może wystąpić rollback @Transactional i jazda? Po miesiącu kodowania okazuje się, że Twój kod jest i działa. Tylko problem, że jest on w 100% zależny od Springa i jego mechanizmów.

Czy jest złoty środek, który pomoże w walce o niezależność kodu?

Technika obrony przed oddaniem władzy w ręce Springa

Skoro znamy już problem i wiemy, że Spring Framework daje nam dużo benefitów ale jednocześnie częściowo uniezależnia nas od siebie jako dostawcy, to jak możemy się tego ustrzec? Mam zarówno dobrą jak i złą wiadomość. Zacznijmy od złej – nie da się tego ustrzec. Dobra natomaist jest taka, że możemy to załagodzić.

Dlaczego nie możemy się ustrzec? Używając Springa w naszych aplikacjach zapewne będziemy chcieli skorzystać z jego głównych zalet – kontenera IoC czy też mechanizmu AOP (Aspect Oriented Programming). Mechanizmy wokół kontenera IoC są odpowiedzialne za inicjalizację, konfigurowanie i składanie obiektów (beanów), a sam kontener zarządza ich cyklem życia co znacznie ułatwia programowanie. Natomiast, jeżeli chodzi o AOP – jest to mechanizm wykorzystywany chociażby przy transakcjach, logowaniu, obsłudze wyjątków czy też kwestiach bezpieczeństwa (security).

To jak załagodzić standardowe flow?

Do tego celu przyda nam się:

• umiejętność tworzenia konfiguracji i beanów samodzielnie,
• wiedza jak działa wzorzec projektowy fasada.

I tyle. Te dwie rzeczy pomogą nam częściowo uwolnić się od zależności frameworka. Lecimy z przykładem wcześniej wspomnianych subskrypcji.

Na samym początku trzeba zdefiniować fasadę, która przykrywa wszystkie istotne akcje biznesowe (utworzenie, wyszukanie, przedłużenie, rezygnację):

public class CompanySubscriptionFacade {

	private final CreateNewCompanySubscriptionService createNewCompanySubscriptionService;
	private final UnsubscriptionService unsubscribeFromSubscriptionService;
	private final CompanySubscriptionRepository companySubscriptionRepository;

	CompanySubscriptionFacade(CreateNewCompanySubscriptionService createNewCompanySubscriptionService,
							  UnsubscriptionService unsubscribeFromSubscriptionService,
							  CompanySubscriptionRepository companySubscriptionRepository) {
		this.createNewCompanySubscriptionService = createNewCompanySubscriptionService;
		this.unsubscribeFromSubscriptionService = unsubscribeFromSubscriptionService;
		this.companySubscriptionRepository = companySubscriptionRepository;
	}

	public Result createCompanySubscription(UUID subscriberId) {
		return createNewCompanySubscriptionService.create(subscriberId);
	}

	public CompanySubscription update(CompanySubscription sub) {
		return companySubscriptionRepository.save(sub);
	}

	public Result unsubscribe(SubscriberId subscriber, SubscriptionId subscription) {
		return unsubscribeFromSubscriptionService.unsub(subscriber, subscription);
	}

	public Optional<CompanySubscription> findSubscription(SubscriptionId subscriberId) {
		return companySubscriptionRepository.findBy(subscriberId);
	}
}

Jest to czysta klasa Javowa, podobnie zresztą jak CreateNewCompanySubscriptionService oraz UnsubscriptionService (z perspektywy kodu Javowego przed konfiguracją, która za chwilę nastąpi). Teraz czas na samodzielną konfigurację:

@Configuration
public class CompanySubscriptionConfiguration {

	/**
	 * wykorzystywane w testach
	 */
	public CompanySubscriptionFacade companySubscriptionFacade() {
		InMemoryCompanySubscriptionRepository companySubscriptionRepository = new InMemoryCompanySubscriptionRepository();

		return companySubscriptionFacade(
				createNewCompanySubscriptionService(companySubscriptionRepository),
				enrollToCompanySubscription(companySubscriptionRepository, new NoOpDomainEventPublisher()),
				companySubscriptionRepository);
	}

	@Bean
	CompanySubscriptionFacade companySubscriptionFacade(CreateNewCompanySubscriptionService createNewCompanySubscriptionService,
														UnsubscriptionService unsubscriptionService,
														CompanySubscriptionRepository companySubscriptionRepository) {
		return new CompanySubscriptionFacade(createNewCompanySubscriptionService, unsubscriptionService, companySubscriptionRepository);
	}

	@Bean
	CompanySubscriptionRepository companySubscriptionRepository() {
		return new InMemoryCompanySubscriptionRepository();
	}

	@Bean
	UnsubscriptionService unsubscriptionService(CompanySubscriptionRepository companySubscriptionRepository,
													  DomainEventPublisher domainEventPublisher) {
		return new UnsubscriptionService(companySubscriptionRepository, domainEventPublisher);
	}

	@Bean
	CreateNewCompanySubscriptionService createNewCompanySubscriptionService(CompanySubscriptionRepository companySubscriptionRepository) {
		return new CreateNewCompanySubscriptionService(companySubscriptionRepository);
	}
}

Klasa konfiguracyjna natomiast jest właśnie tą klasą, która odpowiada za utworzenie beanów. Sama posiada adnotację @Configuration oraz jest odpowiedzialna za prawidłowe powiązanie zależności.

Jeżeli chcesz dodać wsparcie dla transakcji / aspektów, które wykorzystują mechanizmy Springa to nie ma z tym najmniejszego problemu. Wystarczy że dodasz nowy @Aspect dla nowego aspektu, a w przypadku transakcji @Transactional na odpowiednim beanie lub jednej z metod. Posiadasz nadal pełne wsparcie mechanizmów Springa a jednocześnie nie betonujesz kodu na wymianę na inny framework. Będzie się to wiązało z przepisaniem konfiguracji (i oczywiście wsparcia dla ewentualnie napisanych aspektów / transakcji przez owy framework).

Podsumowanie

Koncept, który tu przedstawiłem jest poniekąd inspirowany podejściem jakie może być spotkane w architekturze hexagonalnej. Jeżeli chciałbyś dowiedzieć się więcej na ten temat to w źródłach zostawiam link do świetnej prezentacji Jakuba Nabrdalika z warszawskiego JUGA oraz dodatkowo takie podejście jest przedstawione w bardzo dobrym kursie DNA (tylko drogim).

Co do samego podejścia. Plusy? Sami kontrolujemy tworzenie beanów, więc doskonale wiemy, co jest tworzone i jakie są zależności. Przy klasach z większą ilością zależności szybciej dostrzegamy problemy z kodem bo sami musimy zarządzać zależnościami. Minusem natomiast jest to, że musimy wykonać więcej pracy. Jeżeli wszystkie klasy w naszym projekcie są bean’ami (najczęściej występuje to przy wykorzystaniu architektury warstwowej), to prawdopodobnie lepiej już oddać władze w ręce Springa i niech się dzieje co się ma dziać.

Źródła:

• Spring
• WJUG #211 – [PL] Modularity and hexagonal architecture in real life: Jakub Nabrdalik

Artykuł ✔️ Spring Framework – Jak Bronić Się Przed Oddaniem Kontroli Frameworkowi? ⛔️⛔️ pochodzi z serwisu bdabek.pl.

Cześć 

Dzisiejszy artykuł będzie poświęcony pisaniu dobrego kodu. Zdefiniujemy czym jest dobry kod i jak go pisać. W artykule, oprócz aspektów technicznych poruszę również kwestie mentalne – w końcu kod pisany jest przez ludzi. Następnie inni go czytają, modyfikują lub usuwają i przepisują od nowa. I tak kręci się nasz programistyczny świat

W dzisiejszym artykule:

• Czym jest dobry kod?
• Wzorzec Strategii a Dobry Kod
• Jak zastosować to w praktyce?

Czym jest dobry kod?

Aby pisać dobry kod należy zdefiniować czym on w ogóle jest. Moim zdaniem dobry kod to taki, który po pierwsze jest łatwy w zrozumieniu. Wiem, że czasami rozwiązujemy problemy, które nie są trywialne i faktycznie w tych przypadkach ciężko o pisanie kodu łatwego w zrozumieniu. Jednak w większości przypadków nasz kod jest sekwencją procedur, która w sposób mniej lub bardziej spójny spełnia wymagania biznesowe.

Drugą metryką dobrego kodu jest możliwość jego zmiany lub jego całkowita wymiana bez obawy popsucia innych, teoretycznie niezależnych obszarów. Łatwo to brzmi na papierze. W praktyce jest to zadanie bardzo trudne do osiągnięcia. Dlaczego tak się dzieje? Wydaje mi się, że częściowo jest to pochodna tego jak angażujemy się w projekt. Z autopsji wiem, że występują sytuacje gdy nam się po prostu nie chce myśleć i piszemy aby było. Czy możemy temu zaradzić? Chyba nie. Aczkolwiek z pewnością możemy to załagodzić wykorzystując wzorzec strategii.

Kolejnym problemem z metryką zmiany lub całkowitej wymiany jest jej mierzalność. Otóz to czy dany kod jest łatwy do zmiany (rozszerzenia) czy też do całkowitej wymiany wyjdzie dopiero przy faktycznej potrzebie. Czasami na taką potrzebę czekamy tydzień a czasami 6 miesięcy. O ile w pierwszym przypadku zmianą może się zająć osoba, która implementowała początkowe rozwiązanie o tyle w drugim przypadku bardzo często będzie to osoba nie związana z początkową implementacją.

Jak widzisz pisanie dobrego kodu jest sztuką zrozumienia. Kod który piszemy będzie czytany i zarządzany przez innych. Największym wyzwaniem programisty jest aby napisać kod, który w jasny sposób przekaże intencje i będzie użyty we właściwym kontekście. Istnieją zasady i konwencje, które programiści powinni znać i stosować. Pomagają one dwóm zupełnie różnym osobom (programistom) na wzajemne zrozumienie bez względu na narodowość czy przekonania. Wydaje mi się, że must-have każdego programisty to przeczytanie lektur wujka Boba o czystym kodzie. Większość programistów na całym świecie przeczytała te lektury (przynajmniej Czysty Kod) dzięki czemu w naszym programistycznym świecie mamy wspólne pojęcie czym jest czysty kod i jak go tworzyć.

Wzorzec Strategii a Dobry Kod

Strategia czyli jeden z wzorców programowania obiektowego, którego raczej nie muszę i nie chcę szczegółowo przedstawiać. Jeżeli ktoś chce sobie przypomnieć jak ten wzorzec działa to odsyłam m.in. do tego linka. W dużym skrócie jest to wzorzec behawioralny, który pozwala na zdefiniowanie rodziny (zbiorów) algorytmów, umieszczenie każdego z nich w osobnej klasie i uczynienie ich obiektami wymiennymi.

Co strategia ma do dobrego kodu? Moim zdaniem kluczowe jest zdanie rodzina algorytmów. Może to być algorytm do obliczania ceny produktu w zależności który klient dokonuje zakupu lub obliczanie ceny pizzy w zależności od tego jakie składniki zostały użyte i jaki rabat będzie udzielony. Rodziną algorytmów równie dobrze może być wybór implementacji do obliczania drogi, jaką mamy do pokonania w zależności czy jedziemy autem, rowerem czy pokonujemy trasę pieszo (przykład: google maps). Przykłady użycia można mnożyć.

Rozkładając definicję rodzina algorytmów na łopatki to okaże się, że algorytm jest to wykonanie logiki pewnej decyzji biznesowej. A co się dzieje z decyzjami biznesowymi? Zmieniają się . Nie zawsze – dobrym przykładem mogą być jakieś regulacje prawne, które od X lat są niezmienne i szansa na to że ulegną zmianie jest nikła. Jednak znaczna większość decyzji biznesowych ulega zmianom. Są doprecyzowywane, usuwane, dodawane, zamieniane na inne.

Dostrzegasz korelację pomiędzy wzorcem strategii a decyzjami biznesowymi? Ja tak. Wykorzystując strategie nasze oprogramowanie jest bardziej elastyczne. Jeżeli miałbym przytoczyć zasady SOLID to kod, który wytworzymy z automatu przyjmuje jedną z zasad [1] a drugą [2] w momencie gdy pomyślimy i nie upychamy wszystkiego do jednego worka:

• Open-closed principle [1]
• Single-responsibility principle [2]

Dzięki temu nasz kod będzie otwarty na rozszerzenie. Będziemy mogli dowolnie dodawać nowe funkcjonalności przez dodanie nowego algorytmu i w jednym miejscu w kodzie definiować nowe rozszerzenie (wybór strategii). Wybór strategii może być instrukcją switch-case, prostym warunkiem if lub w bardziej hardcorowych przypadkach konfiguracją wyekstraktowaną do zewnętrznego pliku. Jednak moim zdaniem ostatnia opcja nie sprawdza się w przypadku rozwiązań biznesowych, gdzie wiemy dokładnie kto jest naszym klientem (nie jest to oprogramowanie kierowane do wszystkich).

Jak zastosować to w praktyce?

To jest chyba najtrudniejsza część tego artykułu. Nie mogę dać Ci konkretnych wytycznych kiedy zastosować wzorzec strategii bo nie znam domeny w jakiej pracujesz. Nie wiem co jest elementem zmiennym i z czego biznes czerpie największą wartość. Co jest jeszcze trudniejsze – często bywa tak, że chociaż wiesz w jakiej domenie się obracasz to nie jesteś w niej ekspertem i nie masz pojęcia czy wymaganie, które właśnie implementujesz może być zmieniane. I co masz zrobić?

Teraz napiszę kilka zdań, z którymi część może się nie zgodzić (być może sam za jakiś czas stwierdzę, że to jest bez sensu). Zakładając, że nie możesz wyciągnąć więcej informacji ze strony biznesu (po prostu nie możesz dowiedzieć się więcej o domenie) musisz działać na czuja i wszędzie tam gdzie czujesz, że kontekst może być zmienialny stostuj wzorzec strategii.

Aby lepiej to zobrazować podam Ci przykład. Załóżmy że pracujesz dla sklepu, który zajmuje się produkcją i dystrybucją biurek. Do tej pory sklep działał lokalnie i cała sprzedaż opierała się o kontakt telefoniczny. Teraz przechodzą w sprzedaż online. Twoim zadaniem jest implementacja logiki prostego systemu płatności. Ma to być dostarczone szybko (każda stracona godzina to $). W celu uproszczenia załóżmy, że cały system jest już zrobiony a Ty musisz zaimplementować ten jeden mały feature.

Musisz zaimplementować płatność, która może być realizowana za pomocą płatności bankowej lub blika. Kiedy użytkownicy dokonują płatności przy pomocy blika, dodatkowo zyskują punkty lojalnościowe (taka promocja). Kod do tego może wyglądać następująco:

public OrderResult makePurchase() {
  OrderResult result = purchaseDesk();

  // implementacja płatności
  makePayment(result);

  return result;
}

private void makePayment(OrderResult result) {
  if (result.isWeb()) {
    result.setPaymentMethod(PaymentType.BANK_ACC);
    notificationSystem.sendEmailNotification();    
  } else if (result.isBlik()) {
    result.setPaymentMethod(PaymentType.BLIK);
    result.addLoyalityPoint();
    notificationSystem.sendMobileNotification();
  }  

  throw new UnsupportedOperationException("Payments other than Web and Blik are not supported");
}

Nie wchodźmy w mantry tego czy ten kod ma sens czy nie. Chodzi o fakt, że teraz dochodzi kolejne rozszerzenie. Sklep dostaje feedback, że wybór płatności jest zbyt skąpy i klienci chcą aby dodano szybkie przelewy oraz możliwość przelewu offline (co to za klienci?? ). Sterowany czasem możesz iść w kierunku dodawania kolejnych if’ów do metody makePayment(…).

private void makePayment(OrderResult result) { 
  if (result.isWeb()) { 
  ....

  else if (result.isFastPayment()) {
    result.setPaymentMethod(PaymentType.FAST_PAYMENT);
    metricService.measureUsage();
  } else if (result.isOffline()) {
    result.setPaymentMethod(PaymentType.OFFLINE);
    result.extractLoyalityPoint();
    metricService.addDumbness();
    notificationSystem.sendSmsNotification();
    notificationSystem.informAboutLegacyPaymentMethod();
  }

  throw new UnsupportedOperationException("Payments other than Web and Blik are not supported"); 
}

Będę z Tobą szczery – nie mam z tym problemu do czasu kiedy logika metody makePayment(…) zaczyna się rozrastać, tak jak w naszym wyimaginowanym przypadku. Kolejny problem to kiedy różne osoby modyfikowały ten kod i teraz żadna inna (nawet te, które ten kod pisały) nie chce tego fragmentu ruszać bo nie do końca wie jak to działa i boi się zepsuć. Byłem w tym miejscu w kodzie produkcyjnym. Nadal się z tym spotykam i myślę, że każdy kto pisze software zna to uczucie. Wiesz, że przydałoby się zrefaktoryzować ten fragment kodu ale nie możesz bo nie ma czasu i zasobów a żeby zrozumieć całość trzeba będzie wejść głęboko w logikę.

Gdybyśmy zamiast tego od razu wyczuli możliwość zmian, zaoszczędzilibyśmy późniejszych bólów. Oczywiście zdaję sobie sprawę, że niesie to inne problemy, typu przekazywanie zależności do konkretnych strategii (coś czego nie uwzględniłem w przykładzie poniżej). Można to załatwić w najprostszy sposób, czyli wstrzykując zależność przez konstruktor. Jednak najważniejsze pytanie które się pojawia i na które nie umiem Ci odpowiedzieć – czy warto? Według mnie w wielu przypadkach tak ale jednak nie zawsze.

public OrderResult makePurchase() {
  OrderResult result = purchaseDesk();

  PaymentStrategy strategy = choosePaymentStrategy(orderResult);
  strategy.makePayment(orderResult);

  return orderResult;
}

private PaymentStrategy choosePaymentStrategy(OrderResult result) {
  if (result.isWeb()) {
    return new WebPaymentStrategy();
  } else if (result.isBlik()) {
    return new BlikPaymentStrategy();
  }  else if (result.isFastPayment()) {
    return new FastPaymentStrategy();
  } else if ( result.isOffline()) {
    return new OfflinePaymentStrategy();
  }   
  throw new UnsupportedOperationException("");
}

// przykładowa implementacja Strategii
class WebPaymentStrategy implements PaymentStrategy {
  @Override
  public void makePayment(OrderResult orderResult) {
    result.setPaymentMethod(PaymentType.BANK_ACC); 
    notificationSystem.sendEmailNotification(); 
  }
}

Może się zdarzyć tak, że miałeś złe przeczucie i kod, który ująłeś w strategię nie ma żadnych rozszerzeń. Skończyłeś z interfejsem i jego dwoma implementacjami które się nie zmieniają. Coś co mógłbyś ująć w jednej metodzie z dwoma if’ami i 15 liniami kodu jest hierarchią klas. Pytanie – czy to jest aż tak złe? W najgorszym przypadku masz 2 dodatkowe klasy, każda zawierająca po 5 linii logiki kodu. Nie jestem zwolennikiem takiego podejścia ale uważam, że będzie to lepsze niż metoda z zagnieżdżającymi się if’ami, które z czasem mogą dojść. Czy jest złoty środek? I tak i nie. Zależy z kim pracujesz. Ja osobiście jestem zdania, że powinniśmy zaczynać jak najprościej – w tym przypadku od metody. A kiedy widzisz, że to się rozrasta robisz refaktor. Nie akceptujesz wymówek typu: to ma być na już!

Podsumowanie

Mam nadzieję, że ten artykuł uświadomi nas trochę w działaniu. Nie piszmy kodu bez myślenia! Patrzmy, co może się zdarzyć dalej. Być może kod, który właśnie klepiesz za 3 miesiące będzie musiał być wyrzucony do kosza a zamiast niego o wiele szybciej powstanie nowa implementacja? Tylko pytanie – czy Twój kod jest gotowy na tak szybką wymianę? Czy kod, który wcześniej naklepałeś nie zawiera zawiłości i nieoczekiwanych wyników?

Oczywiste jest, że im dłużej jesteś na danym projekcie, tym większą wiedzę masz na temat tego co tworzysz. Może faktycznie będzie tak, że uznasz iż kod, który pisałeś 2 miesiące temu trzeba przepisać z nowo poznaną wiedzą. Jak duży będzie koszt przepisania? Czy będzie to tylko kwestia napisania nowej logiki i jej odpowiednie wstrzyknięcie? A może modyfikowanie 10 miejsc z dozą niepewności czy system będzie działać dalej tak samo? Sam odpowiedz na to pytanie i pamiętaj, że kod który dziś tworzysz jutro może być zarządzany przez kogoś innego.

Na koniec pozwolę sobie utworzyć własny cytat:

Kod jest jak bumerang, kiedyś do Ciebie wróci.

Bartosz Dąbek

Źródła:

• Strategy
• Strategy Pattern – Design Patterns (ep 1)

Za tydzień

Mamy pierwszy tydzień nowego miesiąca a to oznacza podsumowanie października oraz plany na listopad.

Artykuł Wzorzec Strategii 🙏. Jak Czytelnie Pisać Kod? 🤔 pochodzi z serwisu bdabek.pl.