Na etapie pracy z długofalowym projektem warto zadbać o to, aby w czasie tworzeni oprogramowania nie dopuścić do:
- tzn. kuli błota / kodu spaghetti i związanej z tym konieczności trzymania całego projektu w głowie,
- czytania kodu, który wymaga wykonywania skoków między odległymi metodami,
- bycia zdanym na debugger.
Rozwiązaniem na te problemy jest modularyzacja, czyli podział złożonego systemu na mniejsze niezależne moduły, między którymi zachodzi przepływ informacji.
Drobnoziarnistość
O ile sam podział projektu na moduły nie jest złożony, to trudnością może okazać się odpowiadanie na zmiany zachodzące w wymaganiach projektu.
Kierując się tą myślą, zwykle będziemy dążyć do dzielenia kodu na na drobnoziarniste moduły, ale czy to podejście jest najlepszym rozwiązaniem?
Niestety, ale nie zawsze, ponieważ im więcej mniejszych modułów, tym obszerniejsze API między nimi. W takim przypadku zmiana wymagań prowadzi do dezaktualizacji API, co finalnie skutkuje koniecznością dostosowania nie jednego, a kilku modułów w tym samym czasie.
Pracując z modułami warto mieć na uwadze, że zmiana w module A powinna być ograniczona swoim zasięgiem tylko do tego jednego modułu. Nieroztropne byłoby dopuszczanie do sytuacji, gdzie poprawianie modułu A pociągnie za sobą poprawianie modułu B, a dodatkowo jeszcze modułu C. W takim przypadku rozbijanie kodu na pojedyncze moduły mija się z celem.
Gruboziarnistość
Łatwiej jest dzielić kod na moduły wg biznesowego zastosowania. Te tematy, które są ze sobą silniej sprzężone powinny znajdować się w tym samym module, ponieważ wzajemnie na siebie wpływają i co ważne upraszczają komunikację -wtedy nie trzeba martwić się o dezaktualizację API.
W komunikacji między modułami warto wytypować moduł nadrzędny (ten który będzie wołał moduł B, ale sam nie będzie wołany). Jeśli nie ma takiej możliwości to lepiej zachować jeden większy moduł niż dwa z cykliczną zależnością.
