Programovanie je disciplína, ktorá nie je úplne jednoduchá. Musíte byť schopný pochopiť zákazníka a pretaviť jeho požiadavky do funkčného softvéru. Riešiť okrajové stavy, ktoré nastávajú len v nejakom druhu konfigurácie počítača alebo snažiť sa odladiť náhodné chyby. Okrem toho musíte čítať kód, ktorý písal niekto iný alebo vy pred rokom a viac (čo je skoro to isté). Jedna z činností, ktorá sa preplieta celým vývojom softvéru a ktorú si uvedomíme len ak narazíme na naozaj veľký problém, je zvládanie komplexnosti (alebo zložitosti).
Stalo sa vám, že ste už niekedy riešili nejaké problémové udalosti, objekty, činnosti, ktoré s tým súviseli sa vám postupne objavovali v hlave, ale neboli ste schopní pojať to všetko naraz? Len sa to vracalo stále dookola. Bolo to ako keď stojíte pri kolotoči typu detská manéž a vidíte práve len to, čo vás akurát míňa. Vlak, koník, auto, motorka, bicykel, vlak, koník, auto … atď. Celé sa to deje preto, lebo náš mozog má obmedzenú kapacitu a naraz je schopný pojať (zobraziť vám) len určitý počet objektov. V knihe Dokonalý kód tvrdí Steve McConnell, že ich je sedem. Ja si myslím, že je to ešte celkom optimistický odhad. Pokiaľ totiž držíte zoznamy toho, čo máte spraviť v hlave, tak vám uprostred toho, ako riešite nejaký problém, váš rozum začne pripomínať, že máte ísť do lekárne alebo sa v blízkosti objaví nejaký zdroj hluku, ktorý vás vyruší (ale o tom niekde inde). Po každom takomto vyrušení sa detská manéž roztáča nanovo.
Takže viete udržať len obmedzený počet objektov alebo elementov. Čo to znamená pre programovanie? No je to obmedzený počet modulov alebo objektov alebo tried. Inak povedané, ak navrhujete niečo, kde musíte podrobne uvažovať o viac ako siedmych triedach naraz, tak máte problém. Aké sú riešenia tohto problému:
-
-
- písať jednoduché aplikácie (len žartujem),
- kresliť si,
- deliť veľký problém na menšie.
-
Kreslenie je celkom dobrý spôsob, ale funguje len v menšom. Je to preto, lebo zachytiť celý ten problém tak, ako ho vidí váš rozum na 2D papieri, chce mimoriadnu zručnosť v kreslení. Hlavným problémom pritom je, že informácie musia prúdiť z pravej hemisféry, ktorá je dobrá na riešenie problémov, ale nevie sa vyjadrovať do ľavej, ktorá zase pozná symboly, teda vám pomôže to celé nakresliť. Tento preklad z jednej polovice do druhej vôbec nie je jednoduchý a často sa nepodarí (vy pritom máte pocit, že tomu rozumiete, ale neviete to nakresliť ani opísať). Mimochodom tento popis fungovania mozgu nemám z vlastnej hlavy. Veľmi dobrá kniha o tom je Pragmatic Thinking and Learning od Andyho Hunta. Dobré čítanie. Odporúčam.
Takže ostáva nám už len posledný kandidát a to je delenie problému na menšie. Čo to znamená v praxi? Napríklad pre objektovo-orientované programovanie, že každý objekt má pevné hranice, jasne definovanú zodpovednosť. Celé sa to potom premietne do toho, že pri písaní triedy sa môžete sústrediť len na túto jednu a nič viac. Ak má váš rozum za úlohu pojať jeden objekt, tak má na to dostatočnú kapacitu, aby ho pojal dobre. Teda ak píšete triedu a je to jediná trieda, na ktorú sa máte sústrediť, mali by ste ju napísať dobre. Dobrá trieda je konzistentná, má len jednu zodpovednosť, robí práve to, čo má a nič viac. Ak máte aplikáciu plnú takýchto tried, tak vás bude bolieť hlava omnoho menej.
Opakom takého prístupu sú triedy bez jasných hraníc (majú napríklad zverejnené premenné na popis vnútorného stavu) a globálne premenné. Kdesi som čítal, že cesta do programátorského pekla je krátka, široká a vydláždená globálnymi premennými. Globálnou premennou je premenná jednej triedy, ktorá môže byť nastavovaná skupinou triedy (najhoršia možnosť je ktoroukoľvek triedou v aplikácii) alebo je lokálna premenná nejakej triedy, ktorá ale má niekoľko zodpovedností a tieto skryté pod-časti triedy komunikujú cez jednu takúto premennú. Prečo je to také nebezpečné? Ak trieda, ktorú píšete, číta globálnu premennú a podľa toho sa nejako správa, tak pri jej čítaní musíte uvažovať o všetkých triedach (a ich správaní), ktoré ju nastavujú. To znamená, že počet objektov, o ktorých máte uvažovať, narastá a ani si neuvedomíte a presiahnete svoje možnosti.
Bez ohľadu na to, aký spôsob vyrovnania sa s komplexnosťou si zvolíte, je to problém, ktorý vás bude pri vývoji stretávať stále. Kvalita návrhu tried v aplikácii môže ľahko degradovať a ani si neuvedomíte a pristihnete sa pri tom, že pri písaní jednej triedy musíte uvažovať o ďalších troch. Na internete nájdete nejeden článok, ktorý sa snaží túto degradáciu vysvetliť druhým zákonom termodynamiky, ktorý hovorí, že: „V uzavretom systéme pri cyklickom procese entropia narastá alebo ostáva rovnaká.“ V tomto prípade je tou entropiou neusporiadanosť kódu a cyklickým procesom jeho úpravy (napr. opravy chýb). Táto neusporiadanosť má potom pomerne veľmi silný vplyv na zložitosť.