Ako si vďaka vhodným zásadám uľahčiť život pri vývoji softvéru
Modernejším názvom pre tento článok by mohlo byť niečo v štýle „Best practices softvérového vývoja„. Názvom „Udržateľný vývoj“ som sa však snažil poukázať na účel—na dôvod, prečo by sme sa vôbec mali trápiť tým, aký kód po sebe zanecháme. Nie preto, že by išlo o nejaký aktuálny trend. Ale hlavne preto, že s čistým kódom sa pracuje príjemnejšie, a to počas celého životného cyklu projektu.
Dobre navrhnutý kód sa jednoduchšie rozširuje a jednoduchšie sa dokáže prispôsobiť meniacim sa podmienkam počas vývoja. Naproti tomu, pri projekte s nahromadeným technickým dlhom sú zmeny náročné a ohrozujú aj ďalšie, pôvodne funkčné časti projektu. Vývojár potom musí venovať dodatočný čas opravám rozbitých a nespolupracujúcich častí, prípadne, ak to čas neumožňuje, nájde si len ďalšie skratkovité riešenie, ktoré technologický dlh zasa o niečo zväčší a odsunie na dobu, kým prestane byť únosný. Mojím presvedčením teda je, že dobre napísaný kód dokáže pri väčších projektoch ušetriť omnoho viac času ako rýchlo napísaný kód.
Čo je to teda ten "dobre napísaný kód"?
Otázkou samozrejme zostáva „čo je to čistý kód“. K tejto téme sa už vyjadrilo nemalé množstvo autorov. Každý z trochu iného uhla pohľadu. Definícia, ktorá najviac utkvela v pamäti mne osobne, pochádza z knihy The Pragmatic Programmer. Autori David Thomas a Andrew Hunt argumentujú, že čistý kód je taký, ktorý sa dá jednoducho zmeniť. Tento jeden princíp v sebe zahŕňa prakticky všetky ostatné bežne nasledované princípy (DRY, KISS, SOLID atp.). Poďme si teda porovnať kvality dobre a zle navrhnutého hypotického kódu, so zameraním sa práve na to, ako jednoducho je daný kód možné zmeniť.
Good design is easier to change than bad design.
— The Pragmatic Programmer (David Thomas, Andrew Hunt)
Kód, ktorý sa mení ťažko
- Názvy premenných a funkcií sú nejednoznačné, alebo vyslovene zavádzajúce. Komentáre sú neaktuálne.
- Kód obsahuje množstvo neoznačených a duplicitných hodnôt. Tie isté informácie sú reprezentované v rôznych častiach projektu. Zmeny je nutné vykonávať na mnohých miestach súčasne, aby sa predišlo nekonzistentnému správaniu aplikácie.
- Implementácia existujúcich funkcionalít a komponentov kvôli svojim pevným väzbám sťažuje ich prepoužitie na nových miestach. Vývojárov to núti vytvárať ďalšie implementácie pre dosiahnutie rovnakých alebo veľmi podobných cieľov.
- Zmena implementácie jedného modulu si vyžaduje zmeny v ďalších moduloch, ktoré na ňom závisia (priamo alebo aj nepriamo). Moduly majú nejasné a neštandardizované rozhrania.
- Metódy a moduly sa spoliehajú na globálny kontext, alebo na iné predpoklady, ktoré si nijako neoverujú / nevynucujú.
- Funkcie, triedy a komponenty sú príliš veľké a neprehľadné. Venujú sa mnohým úlohám naraz.
- Projektová štruktúra je nekonzistentná. Dokumentácia absentuje.
Kód, ktorý je možné meniť jednoduchšie
- Projektová štruktúra aj štruktúra kódu je navrhnutá s dôrazom na to, aby vývojár vždy vedel, kde čo hľadať a čo kam umiestniť. Účelu jednotlivých modulov a funkcií je možné porozumieť na prvý pohľad. Názvy premenných, funkcií a tried jasne vystihujú ich zámer a predpoklady. Všetko je umiestnené v blízkosti miesta, kde sa to používa.
- Komplexná logika je rozdelená na menšie, ľahko uchopiteľné časti s jasne definovanými vzťahmi. Každý modul alebo komponent má jednoznačne definovanú zodpovednosť a komunikuje prostredníctvom dobre navrhnutého, konzistentného a zdokumentovaného rozhrania (požadované vstupy, výstupy a správanie).
- Funkcie a metódy vykonávajú presne to, čo naznačuje ich názov. Nič menej, nič viac. Žiadne neúmyselné vedľajšie efekty.
- Implementačné detaily sú abstrahované do izolovaných častí, ktoré sú ľahko prepoužiteľné a nezávislé na iných moduloch. Moduly neodkrývajú nič, čo nie je nevyhnutné pre ich použitie.
- Každá informácia a konštantná hodnota má v kóde len jednu rozumne umiestnenú a označenú reprezentáciu (single source of truth).
Ako sa dopracovať k čistému kódu
Ak sa teda zhodneme na niektorých vlastnostiach dobre a zle navrhnutého kódu, akým spôsobom môžeme maximalizovať podiel toho dobre navrhnutého? Aj keby sme vedeli vymenovať všetky populárne anglické akronymy, navrhnúť dobrý kód nemusí byť vôbec jednoduché. Napriek tomu existujú projekty, ktoré si aj v turbulentných podmienkach vedú lepšie než iné.
- Základom udržateľného projektu je dobre navrhnutá architektúra. Zjednodušene sa dá povedať, že architektúra predstavuje súbor rozhodnutí s dlhodobým a celoplošným dopadom na vývoj. Ide najmä o tie voľby, ktoré sa pri rozbehnutom projekte menia len veľmi ťažko, bez ohľadu na kvalitu kódu. Napríklad výber architektonického štýlu (monolit, mikroservisy…), použitých technológií, spôsobu komunikácie medzi systémami, alebo aj rôzne „guidelines“ na ktorých sa dohodne tím. Preto je obzvlášť dôležité dať si na týchto rozhodnutiach záležať a byť si vedomý ich kladov a záporov.
- Veľkou pridanou hodnotou sú určite predošlé skúsenosti jednotlivých vývojárov. Na základe skúseností z rôznych typov projektov, technológií a tímov človek sám zistí čo funguje a čo nie, a tieto zistenia si postupne internalizuje. Osvedčené postupy z jedného projektu môžu byť prenosné aj na iný projekt, a mechanizmy zaužívané v jednej technológii môžu inšpirovať inovatívne riešenia v inej. S každou novou skúsenosťou sa naša intuícia zdokonaľuje a princípy efektívneho vývoja sa stávajú prirodzenou súčasťou nášho rozhodovania.
- Neoceniteľnou pomôckou sú dnes aj moderné vývojové nástroje. Lintovacie nástroje eliminujú mnohé chyby už v ich zárodku, formátovacie nástroje zabezpečujú konzistentný zápis kódu, refaktorizačné pomôcky zjednodušia hĺbkové zmeny v kóde a automatizácia odľahčí vývojárov od mechanických úloh náchylných na chybovosť. Programátorom to umožní sústrediť sa na podstatu problémov namiesto riešenia vedľajších komplikácií. Dosiahnuť úpravu prostredia je navyše omnoho jednoduchšie (a realistickejšie) ako dosiahnuť zmenu správania ľudí.
- Kvalita kódu závisí aj od tímovej kultúry. Prostredie, kde sa ľudia neboja priznať si chybu, navrhnúť zmenu alebo klásť otázky, vedie k lepším rozhodnutiam. Otvorená komunikácia a zdieľanie poznatkov podporujú jednotný prístup k riešeniam. V tíme, ktorý podporuje dôveru a spoluprácu, sa potom ľudia neboja čeliť novým výzvam a prevziať zodpovednosť za svoju časť práce, aj za spoločný výsledok tímu.
Špeciálnou pomôckou, ktorá pre udržiavanie čistého kódu pomáha mne, je, že keď sa snažím vyriešiť určitý problém, nezameriavam sa na to „ako by sa dal vyriešiť“, ale na to „ako by mal byť vyriešený“. Hoci existuje obrovské množstvo odpovedí na otázku „ako sa dá niečo urobiť“, odpovedí na otázku „ako by to malo byť urobené“ (ak to má spĺňať atribúty ľahko meniteľného kódu) nebýva až tak veľa. A hoci cesta k nim nemusí byť viditeľná vždy na prvý pohľad, časom sa väčšinou predsa nájde. Alebo upozorní programátora na niečo, čo by malo byť vyriešené na inej úrovni, kým bude možné zodpovedne pokračovať vo vývoji.
Write code that bends and doesn’t break.
— The Pragmatic Programmer (David Thomas, Andrew Hunt)
Čistý kód za každú cenu?
V tomto článku som sa snažil vyzdvihnúť dôležitosť kvalitného kódu. Jeho uplatňovanie by však nemalo byť rigidné. Skutočný vývoj si vyžaduje neustále balansovanie medzi ideálom a realitou. Nie vždy sa oplatí prepísať existujúci kód len preto, aby bol „správny“. Niekedy to nie je možné z časových dôvodov, niekedy to nie je možné kvôli závislostiam na tretej strane a niekedy je to zbytočné riziko.
Vždy je dôležité posudzovať prioritu, riskantnosť, rozsah prípadných škôd a časové náklady. Kritická business logika si vyžaduje vyššiu pozornosť ako napríklad perfektná hierarchizácia CSS štýlov. Aj keď však developer nemá priestor urobiť veci dokonale, väčšinou má možnosť voliť riešenia, ktoré sú o niečo lepšie než tie najrýchlejšie a najjednoduchšie. Z týchto dôvodov tak schopnosť písať dobrý kód do určitej miery považujem skôr za umenie, než za exaktnú vedu.
A dôležitá je aj ochota zasahovať do už napísaného kódu. Kvalitný dizajn nevzniká na prvý pokus, ale postupným vylepšovaním. S refaktorovaním by sa teda nemalo začínať, až keď je už technologický dlh neúnosný. Mal by predstavovať prirodzenú súčasť každodennej práce.
Don’t live with broken windows.
— The Pragmatic Programmer (David Thomas, Andrew Hunt)
Tomáš Bencko
Autorom článku je Tomáš, frontend developer so zameraním na React, Vue.js a TypeScript. Jeho úlohou je vytvárať moderné a škálovateľné frontend riešenia, pričom zvláda nielen vývoj, ale aj jemné detaily dizajnu. Okrem práce pre klientov neustále hľadá spôsoby, ako zefektívniť prácu v tíme, hrá sa s AI a automatizáciou, a prináša nové nápady, ktoré posúvajú projekty aj kolegov vpred.
