Kiedy przydają się wzorce projektowe

Dariusz Ciesielski • 13/11/2019


Niedawno dyskutowałem na temat wzorców projektowych i momentu, w którym warto je wdrażać w systemie.

Zacznijmy od podzielenia systemu na kilka kategorii

System pisany od zera bez ustalonych procesów biznesowych

Jako, że procesy biznesowe dopiero będą modelowane wraz z rozwojem firmy i oczekiwań klientów, nie ma sensu na początku tworzenia oprogramowania, dodawać dodatkowej warstwy abstrakcji do kodu - w tym przypadku wzorców projektowych. Przeważnie tego typu oprogramowanie możemy spotkać w startupach. Startup w swojej idei jest firmą dostosowującą się bardzo prężnie do potrzeb klientów, tym samym oprogramowanie musi być często aktualizowane o nowe funkcjonalności, a stare powinny być kasowane. Poświęcanie czasu i energi na tworzenie idealnego kodu w początkowej fazie rozwoju aplikacji jest tylko ich stratą. Na tego typu działania przyjdzie czas później.

System pisany od zera, w którym znamy procesy biznesowe

Jest to przypadek, w którym przychodzi do nas firma, znająca swoje procesy, ale nie ma jeszcze dedykowanego oprogramowania pod te procesy. Może być to firma, z branży ubezpieczeniowej, w której pani Krysia zapisuje nowych klientów w excelu albo zakłada im nową teczkę w segregatorze. Aby usprawnić proces firma potrzebuje dedykowanego oprogramowania i tu pojawiamy się my. Znając już procesy jakie zachodzą w firmie łatwiej będzie nam dopasować odpowiednie wzorce projektowe do tych procesów. Mamy także większą pewność, że funkcjonalności, które mają zostać zaimplementowane, nie zmienią się tak szybko jak w przypadku startupa. Trzeba mieć tu na uwadze jeszcze inne zmienne. Naszą znajomość wzorców oraz czas na wykonanie oprogramowania. Jeżeli mamy mało czasu i nie mamy doświadczenie ze wzorcami, wzbroniłbym się przed ich stosowaniem. Natomiast jeżeli czasu jest dużo, a my nie znamy wzorców, warto wykorzystać taki projekt do ich poduczenia.

Raczkujący system, budowany przez 1-2 lata

Na tym etapie system jaki rozwijamy powinien przynosić już przychody lub być wartościowy dla firmy. Tym samym system ma duże szanse na dalszy rozwój, a to oznacza stabilne poszerzanie funkcjonalności oraz ulepszanie aplikacji. My natomiast powinniśmy już dostrzec powtarzalne elementy jak i elementy wymagające poprawy. Warto więc na tym etapie dołożyć wzorce projektowe, nawet jeżeli oznacza, to poświęcenie dodatkowego czasu w naszą naukę owych wzorców. W przyszłości czas ten i tak się zwróci, ponieważ utrzymanie systemu będzie o wiele mniej problematyczne.

Dojrzały system budowany przez kilka lat

W przypadku dojrzałego systemu, możemy być pewni, że jest on przydany dla firmy oraz możemy być pewni, że taki system był długo rozwijany. Tym samym istnieje duża szansa posiadania dużego długu technologicznego. Dlatego też, nawet jeżeli nie znamy wzorców powinniśmy wyuczyć się ich i zacząć je stosować. Tak jak poprzednio pomoże nam, to w zminimalizowaniu czasu jaki będzie potrzebny do dalszego rozwoju aplikacji jak i jej utrzymania.

Frameworki

Zapewne mało kto z was pisał frameworki od podstaw, przeważnie jako programiści korzystamy już z jakiegoś gotowego systemu, ale jeżeli jesteś w projekcie, który pisze swój własny framework, w tym przypadku jak najbardziej należy korzystać ze wzorców. A ich lista jest długa, czy to:

  • Front Controller
  • MVC
  • Dependencie injection
  • Strategy
  • Singleton
  • Factory

Framework jest to baza, na której buduje się wszelkiego rodzaju systemy. Począwszy od tych najmniejszych do tych dojrzałych, dlatego też tego typu baza musi być tworzona z zastosowaniem wszystkich dobrych praktyk.

Podsumowując

Osobiście uważam, że wzorce projektowe są potrzebne i warto je wykorzystywać. Ale należy robić to z głową, aby nie marnować swojego czasu i pieniędzy firmy. Jeżeli masz już doświadczenie z w tej kwestii, możesz implementować wzorce wcześniej. Natomiast jeżeli dopiero chcesz się ich poduczyć, proponuje robić to w projektach, które będą miały już stabilną pozycję. Implementacja w projektach, które dopiero powstają jest bardzo ryzykowna, bo nigdy nie wiemy, która część systemu zostanie przeprojektowana, a która będzie trzonem aplikacji.

Moja zasada jest prosta, zaczynam projekt jak najprościej, a dopiero wraz z jego rozwojem refaktoryzuje go wykorzystując wzorce projektowe - w myśl zasady KISS