Software architecture

Projekty oprogramowania mogą stać się zbyt skomplikowane z wielu powodów. Często deweloperzy skupiają się na dodawaniu kolejnych funkcjonalności i rozwiązań bez zastanowienia się, czy są one naprawdę potrzebne. W efekcie, projekty stają się złożone, trudne do zrozumienia i problematyczne w utrzymaniu.

Wczoraj brałem udział w burzliwej dyskusji na temat architektury jednego z projektów. W głównej mierze rozchodziło się o to, że architektura jest „over complicated”, co oznacza chyba – za bardzo skomplikowana.

Z kolei w poprzednim tygodniu uczestniczyłem w fajnych warsztatach na których omawialiśmy diagramy C4. Na tych warsztatach było około 8 osób i mieliśmy do narysowania diagram C4 pierwszego i drugiego poziomu dla pewnego prostego systemu. Bodajże sześć osób wybrało architekturę mikro serwisową, a dwie modularny monolit w backendzie + headless frontend.

Padło nawet stwierdzenie, że architektura mikro serwisowa do „defaultowa architektura” dla nowych projektów.

Ja się z tym całkowicie nie zgadzam i uważam, że architekturę trzeba dobierać do danego problemu i możliwości. Mikro serwisy są super, pomimo tego mają też trade offy (jak wszystko). Czasem niepotrzebnie można sobie utrudnić życie, komplikując architekturę. Modnie nie zawsze znaczy wygodnie.

Problemem jest też tak zwany hype i trendy, które sprawiają, że czasem proponowanie prostych rozwiązań jest niekomfortowe, bo ktoś Cię może uznać za głupka. Proponowanie prostoty może nie przyniesie Ci wielu followersów na twitterze, pomimo tego możesz sobie zaskarbić tym sympatię swoich kolegów i klientów, którzy nie będą musieli ciągnąć za sobą bagażu technologii, które oprócz złożoności wnoszą do projektu tyle co Hector Bellerín do gry Barcelony.

---

Keep it simple, stupid!

Upraszczanie spraw, architektury i generalnie wszystkiego to bardzo fajny pomysł znany od dawien dawna i nazwany jako reguła KISS. Reguła ta mówi o tym, że prostota powinna być kluczowym celem w projektowaniu i należy unikać niepotrzebnej złożoności.

Reguła KISS ma zastosowanie tak naprawdę w każdym aspekcie życia, nie tylko architekturze. Prostota powinna być kluczowym celem w projektowaniu, a deweloperzy powinni unikać niepotrzebnej złożoności.

Warto zauważyć, że reguła KISS ma zastosowanie nie tylko w architekturze oprogramowania, ale w każdym aspekcie życia. Wprowadzenie prostoty do naszego myślenia i projektowania może pomóc nam uniknąć nadmiernego skomplikowania i osiągnąć lepsze wyniki.

Hype-driven architecture

Czasami trendy i “hype” mogą wpłynąć na podejście do architektury oprogramowania, co może prowadzić do nadmiernego skomplikowania projektów. Ważne jest, aby dobierać architekturę do konkretnego problemu i unikać niepotrzebnej złożoności. Dążenie do prostoty i unikanie niepotrzebnej złożoności może przynieść lepsze wyniki niż przejmowanie się modą i trendami.

Wybór odpowiedniej architektury to kluczowy element projektowania oprogramowania. Dlatego dokładnie analizuj problemy, które rozwiązujesz aby dopasowywać architekturę do jego wymagań. Pamiętajmy, że prostota jest często kluczowa dla sukcesu projektu.

To co dobrze działa to zadawanie pytań i wady i trade-offy różnych rozwiązań. Jeśli ktoś Ci mówi, że dane rozwiązanie jest receptą na wszystkie zło to od razu niech CI się zapali lampka ostrzegawcza z napisem: “Uwaga, hype”

Prostota jako wartość

Prostota powinna być postrzegana jako wartość, do której należy dążyć w procesie tworzenia oprogramowania. Dążenie do uproszczenia architektury i unikanie niepotrzebnej złożoności może pomóc w osiągnięciu lepszych wyników.

Im mniej masz bloczków na diagramie tym lepiej. Im mniej kodu, im mniej serwisów, im mniej repozytoriów. Skup się na tym, żeby rozwiązać problem, a nie na tym aby pokazać jaki jesteś mądry i czego to nie potrafisz wymyślić.

Praktyczne wskazówki i strategie, jak wprowadzać prostotę w architekturze oprogramowania

• Zastanów się, jakie funkcjonalności są naprawdę potrzebne, a które można pominąć.

• Projektuj z myślą o prostocie i łatwości utrzymania kodu.

• Unikaj nadmiernego skomplikowania, jeśli nie ma ku temu wyraźnej potrzeby.

• Dobieraj architekturę do konkretnego problemu, a nie do trendów.

• Wdrażaj regułę KISS (Keep It Simple, Stupid!) jako kluczowe podejście do projektowania.

• Często zadawaj pytania i analizuj wady i zalety różnych rozwiązań.

• Skup się na rozwiązaniu problemu, a nie na pokazywaniu swojej mądrości.

---

Podsumowanie

• Projekty oprogramowania mogą stać się zbyt skomplikowane, co utrudnia ich zrozumienie i utrzymanie.

• Reguła KISS (Keep It Simple, Stupid!) mówi o tym, że należy dążyć do prostoty w projektowaniu i unikać niepotrzebnej złożoności.

• Unikanie nadmiernego skomplikowania i dążenie do prostoty może przynieść lepsze wyniki niż przejmowanie się modą i trendami.

• Prostota powinna być postrzegana jako wartość w procesie tworzenia oprogramowania.

• Praktyczne wskazówki i strategie, jak wprowadzać prostotę w architekturze oprogramowania:

  • Zastanów się, jakie funkcjonalności są naprawdę potrzebne, a które można pominąć.
  • Projektuj z myślą o prostocie i łatwości utrzymania kodu.
  • Unikaj nadmiernego skomplikowania, jeśli nie ma ku temu wyraźnej potrzeby.
  • Dobieraj architekturę do konkretnego problemu, a nie do trendów.
  • Wdrażaj regułę KISS jako kluczowe podejście do projektowania.
  • Często zadawaj pytania i analizuj wady i zalety różnych rozwiązań.
  • Skup się na rozwiązaniu problemu, a nie na pokazywaniu swojej mądrości.

Czy zastanawiałeś się, co by się stało, gdybyśmy zawsze dążyli do prostoty w projektowaniu oprogramowania? Może warto spróbować zmienić nasze myślenie i eksperymentować z prostszymi rozwiązaniami? Pomyśl o projekcie w którym obecnie pracujesz. Czy są tam jakieś rzeczy, które są bardzo złożone i sprawiają trudności? Jakby Ci się pracowało gdyby ich nie było?

::: tip 📣

Podziel się tym artykułem ze swoimi współpracownikami, aby razem dążyć do prostoty i unikać nadmiernego skomplikowania w projektowaniu oprogramowania!

:::