Divide and Conquer je známa fráza z antiky ako zvládať nepriateľov, ale aj názov algoritmu na riešenie problémov. Rovnaká fráza sa dá použiť aj na delenie softvéru na menšie časti, teda jeho modularizáciu. To, že softvérové riešenie musíte v nejakom momente začať deliť na menšie časti, je základný fakt vývoja. Čo ale nie je tak jasné je ako ho správne rozdeliť. Častokrát je to delenie podľa štruktúry organizácie, ktorá softvér vyvíja (tzv. Conway law), alebo sa aplikácia rozdelí, aby bola jej štruktúra ľahko pochopiteľná. Aj keď to vyzerá ako dobrý prístup, strácajú sa tým niektoré výhody modularizácie. Povedzme si teraz ako sa to dá urobiť lepšie.

Správne narezať softvér je veda a vstupuje do toho niekoľko hľadísk. Tie najčastejšie používané sú hranice v biznis a technologickej doméne (viď. môj článok o doménach softvérového projektu). Vezmite si mikroslužbu, ktorá obsluhuje jeden centrálny objekt (používateľa, faktúru, dokument) a kolekciu objektov, ktoré ho dopĺňajú. Dostávate tak komponentu, ktorá má jasné a pre nás prirodzené hranice v technologickej a biznisovej doméne. Toto delenie je časté, pretože okrem iných to prináša ľahšie pochopenie a vývoj.

Okrem tohto prístupu ale existujú aj ďalšie hľadiská, ktoré je dobré brať do úvahy. Pri delení softvéru by ste mali myslieť minimálne na tieto ďalšie kritériá:

• Prevádzka
• Bezpečnosť
• Potenciálne zmeny

Poďme ich teraz postupne rozobrať.

Prevádzka

Asi najdôležitejšie hľadisko pri modularizácii. Na začiatok si dajme niekoľko príkladov:

• Vyvinuli ste serverovú komponentu, ktorá obsahuje dva kritické procesy. Potrebujete, aby mali obe čo najmenší čas výpadku. Jeden z nich ale skončí s chybou a zasekne sa. Potrebovali by ste ten komponent reštartovať, ale to bude znamenať, že dôjde aj výpadku druhého kritického procesu, čo nechcete.
• V inom prípade ste vyvinuli komponentu, ktorá obsahuje kritický proces. Okrem toho obsahuje množstvo menej dôležitých procesov. Keďže všetky procesy zdieľajú tie isté prostriedky operačného systému, neviete poriadne sledovať a škálovať ten jeden kritický proces. Okrem toho, keď navýšite ich množstvo, tak tieto prostriedky naviac konzumujú aj ostatné procesy.

V oboch prípadoch je to rovnaký problém – kritický proces je zabalený v jednej komponente s niečím iným, čo sťažuje jeho spravovanie. Základnou myšlienkou pri zohľadňovaní prevádzky pri modularizácii je, že procesy, ktoré sú kritické (je dôležité, aby bežali stabilne, nepretržite alebo pracujú s veľkým množstvom údajov) boli osamostatnené.

Pre prevádzku nie je nič horšie, ako keď dostane zle modularizovanú aplikáciu. Kritické procesy a ich údaje sú premiešané s tými menej dôležitými. Zdieľajú tie isté systémové prostriedky. Tým pádom nie je možné ich prioritizovať a osobitne spravovať. Na druhej strane, riešenie nespočíva v úplnom rozdrobení systému. Ak je komponentov príliš veľa, tak to prináša zbytočne veľa pracnosti a mikromanažment. Preto je dôležité nájsť správnu granularitu, a v rámci nej osamostatniť tie najdôležitejšie časti.

Bezpečnosť

Bezpečnosť je ďalšia z domén, cez ktorú sa dá nazerať na softvérový projekt. V zásade je táto doména tvorená akciami alebo dátami, ktoré chcete chrániť, vektormi možného útoku a ochranou (teda zabránenie útoku). Fakt je, že nie všetky dáta a akcie vo vašom systéme majú z pohľadu bezpečnosti rovnakú dôležitosť. A teda aj v tejto doméne existujú určité hranice a modularizácia by ich mala rešpektovať. V opačnom prípade sa môže stať, že sa vyššia bezpečnosť aplikuje aj tie časti systému – procesy a údaje – ktoré to nevyžadujú len preto, lebo sú súčasťou komponenty s procesom, ktorý je z pohľadu bezpečnosti kritický. A bezpečnosť – bez ohľadu nakoľko je potrebná – nie je zadarmo. Aj pri vývoji a aj pri prevádzke.

Potenciál zmeny

Ja osobne som sa nestretol so softvérom, ktorý by sa po naprogramovaní roky používal a nebolo by potrebné do neho robiť pravidelné zmeny. A čím je systém rozsiahlejší a dôležitejší, tým je väčšia pravdepodobnosť ďalších zmien. Pri zmenách ale vo všeobecnosti platí, že majú byť čo najmenšie. Čím je zmena v systéme väčšia, tým je drahšia a rizikovejšia. Nie nadarmo sa hovorí, že v komplexných systémoch neexistuje malá zmena. Preto je vhodné navrhnúť aplikáciu tak, že sú časti systému, ktoré majú veľký potenciál zmeny, izolované.

Ale ako vedieť, čo sa zmení? Na prvý pohľad to môže vyzerať ako ťažká otázka. Na ten druhý to nemusí byť až také zložité. V prvom rade sa opäť na softvér treba pozrieť z pohľadu rôznych domén (biznisová, technologická, bezpečnostná…). V každej z nich dochádzalo v minulosti k nejakým zmenám. V každej z nich existuje konkurencia alebo alternatíva, ktorá je v nejakých hľadiskách iná. To všetko sú body potenciálnej zmeny. Tieto časti – časti s veľkým potenciálom zmeny – by mali byť pri modularizácii osamostatnené. Výsledkom môže byť, že zmena bude izolovaná len v jednom komponente na rozdiel od situácie, kedy by sa zasiahla veľkú čast systému. Modularizácia je teda o hľadaní hraníc v rôznych doménach projektu. A potom o implementácii týchto hraníc v softvéri. Všetky tieto aspekty by mali byť pri delení softvéru zvažované. Ich ignorovanie vedie k riešeniu, ktoré je fakticky v rozpore s reálnym svetom a prostredím softvéru. Je to ako keď sa snažíme vložiť drevenú kocku do kruhového otvoru. Nakoniec sa vám to môže podariť pomocou veľkej sily. Presne tak vyzerá občas riešenie problémov s prevádzkou, bezpečnosťou alebo zmenovými požiadavkami v praxi, ak softvér nie je vhodne modularizovaný.