Modularność oprogramowania

Oprogramowanie powinno być, ortoagonalne, modularne, komponentowe i luźno powiązane. Co to właściwie znaczy?

Powyższe koncepcje to podstawa dla każdego programisty, który chce tworzyć łatwe do zaprojektowania, skonstruowania, testowania, utrzymania i rozwijania projekty czy całe systemy. Niestety idea ta rzadko jest przekazywana w procesie edukacji i nowi adepci programowania musza do niej dochodzić metodą prób i błędów. Kiedy opanujemy jak tworzyć systemy złożone z klocków (modułowe) to zauważymy ogromną poprawę jakości wytwarzanego oprogramowania. Co za tym idzie zmniejszymy ilość błędów.

System nie modularny:

Świetnym przykładem niemodularnego systemu jest helikopter. W śmigłowcu każdy ruch jakimś przyrządem prowadzi do jakiś skutków ubocznych które trzeba kontrować innymi ruchami innych przyrządów. Np. obniżenie dźwigni trzymanej w lewej ręce wymaga jednoczesnego kontrowania dźwignią w prawej i lekkiego dociśnięcia pedału stopą. Jak widać tym przykładzie za jedną operacją musi podążać wiele innych, żeby maszyna się nie rozbiła. Możemy to przenieś na system informatyczny w bardzo prosty sposób. Kiedy zmiana nazwy kolumny w bazie danych wymaga również zmiany po stronie widoku dla użytkownika to mamy idealny przykład systemu, który nie jest ortogonalny.

Jakich zasad się trzymać by nasze oprogramowanie było modularne?

Elementy ze sobą niepowiązane nie powinny mieć na siebie wpływu. Jeżeli trafiliśmy do projektu, który nie przestrzega tej reguły to należy stopniowo pozbywać się zależności między niepowiązanymi elementami.

Powinniśmy projektować autonomiczne (niezależne) komponenty. Niezależne byty ,które są tworzone z myślą o jednym precyzyjnie zdefiniowanym celu. Powinny być od siebie odizolowane bo tylko wtedy jesteśmy pewni, że zmiana w jednym z nich nie będzie wymagała zmiany w drugim.

Jeżeli będziemy trzymać się powyższych to dopóki nie zmienimy interfejsów naszych zewnętrznych komponentów, możemy być pewni że modyfikacje nie wpłyną na inne części systemu.

Zwiększona produktywność

Przez enkapsulację komponentów zmiany są ściśle związane z konkretnymi miejscami. Czas wytwarzania i testowania będzie znacznie, krótszy. Dodatkowo zwiększamy nasze możliwości ponownego wykorzystania tego samego kawałka kodu a łączenie modularnych funkcjonalności pozwala uzyskać większą ich liczbę w krótszym czasie niż w przypadku niemodularnych rozwiązań gdzie duplikowalibyśmy kod.

Zmniejszenie ryzyka

Kiedy problematyczne sekcje są odizolowane od reszty i ukryte za abstrakcją możemy spodziewać się, że najwięcej wad będzie ujawniać się właśnie tu i nie będą rozsiane po całym projekcie. Utworzony w sposób modularny system jest mniej wrażliwy na zmiany bo tak samo jak w przypadku problematycznych sekcji zmiana w jednym miejscu nie powoduje problemów w innym. Takie systemy też łatwiej jest testować co bezpośrednio zmniejsza ryzyko powstawania błędów. Dodatkowo eliminujemy zależności między platformami (np. obsługa bazy danych czy klienta mailowego jest odizolowana od reszty i zmiana dostawcy usługi nie jest dużym problemem).