Jednou z najpreťaženejších špecializácií idiotmi sú manažéri, ktorí riadia programátorov. Nie všetci, ale tí, ktorí nikdy neboli programátormi. Tí, ktorí si myslia, že môžu "zvyšovať" efektivitu (alebo zvyšovať "efektivitu"?) metódami z knižiek. Ani si nedali tú námahu tieto knižky prečítať — veď existujú videá.
Tí, ktorí nikdy nepísali kód. Tí, pre ktorých točia hollywoodske filmy o programátoroch — no, tie, kde elektronickú poštu z príkazového riadka pozerajú. Tí, ktorých nezaujíma nič iné ako ukazovatele, termíny a vlastný plat.
Tí, ktorých je väčšina.
Ale sú idiotmi z iného dôvodu. Chcú efektivitu, alebo aspoň výsledkovosť (poď, manažér, googli, aký je medzi tým rozdiel), bez toho, aby rozumeli jednému či druhému. Úplne nechápu podstatu, proces dosahovania výsledku, straty, ktoré sa v tomto procese dejú, náklady na vývoj. Skrátka, pracujú s programátorom ako s čiernou skrinkou.
Do riadenia programátorov prichádzajú presne z jedného dôvodu: je tu hype, peniaze, trh a kopa takých istých idiotov. Je tu, kde sa schovať.
Keby bol hype v mechanickej výrobe — utekali by tam. Úbohí univerzáli. Nečudoval by som sa, keby chlapík, ktorý predáva v decembri v našej štvrti vianočné stromčeky, bol IT manažér na dovolenke.
Skrátka, ak máte možnosť, vykopte týchto chlapcov. Nebojte sa, nájdu si prácu. Nikto z nich nikdy neurobí nič poriadne, pokiaľ sa sám nestane programátorom. Pretože nechápe podstatu, mechanizmus, logiku procesu, ktorým riadi.
No, dosť o manažéroch. Teraz k veci, pre programátorov. Ako zvýšiť efektivitu vývoja učením sa písať kvalitný kód.
Aby ste zvýšili efektivitu, musíte rýchlejšie riešiť úlohy bez straty kvality. Aby ste rýchlejšie riešili úlohy, musíte vedieť okamžite písať kvalitný kód. A "kvalitný", a "písať", a "okamžite". Vysvetlím to metaforou.
Písať kvalitný kód je ako správne hovoriť v cudzom jazyku. Keď jazyk nepoznáte, strácate veľa času na to, aby ste svoje myšlienky formulovali.
Keď je potrebné rýchlo niečo povedať, jednoducho prilepíš nejaké slová, často nie tie správne, zabudneš na články, správny slovosled, nehovoriac o časovaní slovies a biednej výslovnosti.
Ak je čas na formuláciu odpovede, bude treba otvoriť slovník alebo internetový prekladač a tráviť veľa času formulovaním svojich myšlienok. Pocit bude aj tak nep príjemný: odpoveď povieš a nevieš, či je správna alebo nie. Podobne je to aj s kódom – akoby si napísal, akoby fungoval, ale či je kvalitný alebo nie – to je otázne.
Vychádza z toho dvojitá strata času. Na to, aby si vymyslel odpoveď, ide čas. Na to, aby túto odpoveď formuloval, ide tiež čas – a nie málo.
Ak však zručnosť písania kvalitného kódu existuje, odpoveď môžeš formuluje okamžite, ako sa usadí v hlave, bez toho aby si strácal ďalší čas na preklad.
Zručnosť písania kvalitného kódu pomáha pri navrhovaní architektúry. Len jednoducho nebudeš zvažovať v hlave nesprávne, nerealizovateľné alebo amatérske možnosti.
Zhrnúc: zručnosť písania kvalitného kódu výrazne urýchľuje riešenie úloh.
Ale to nie je všetko. Vďaka manažérom s gumovými čižmami, existuje jeden zádrhel – nemáme naozaj dôvod písať kvalitný kód. Manažér kód nesleduje, klient kód nesleduje. Navzájom si kód ukazujeme zriedka, len občas, v niektorých projektoch, kde je určený "kontrolór" kódu alebo periodicá refaktoring.
Vyzerá to, že v väčšine prípadov zlý kód ide do produkcie alebo k klientovi. Osoba, ktorá napísala zlý kód, si vytvára stabilné neurónové spojenie – písať zlý kód nie je len možné, ale aj potrebné – prijímajú ho, a ešte za to platia.
V dôsledku toho, zručnosť písania kvalitného kódu nemá vôbec šancu sa rozvinúť. Kód napísaný podmienečným zamestnancom nikto nikdy nekontroluje. Jediný dôvod, prečo sa naučí normálne programovať, je vnútorná motivácia.
Ale táto vnútorná motivácia je v konflikte s plánmi a požiadavkami na efektívnosť a produktivitu. Toto napätie sa vyrieši zjavne nie v prospech kvalitného kódu, veď za zlý kód ťa ani nenapomenú. A za nesplnenie plánu – veď to áno.
Čo robiť? Vidím a navrhujem dve cesty, ktoré je možné kombinovať.
Prvá cesta – ukázať svoj kód niekomu vo firme. Nie reaktívne (keď sa pýtajú/nútia), ale proaktívne (hej, pozri si môj kód, prosím). Tu je dôležité neprekrývať kritiku kódu zdvorilou formou. Ak je kód zlý, proste povieme: kód je zlý. Samozrejme s vysvetleniami a odporúčaniami, ako ho vylepšiť.
Ale ani táto cesta nie je ideálna. Jej použiteľnosť závisí od bodu, v ktorom došlo k kontaktu. Ak už práca išla do produkcie a ukázalo sa, že kód je zlý, jeho prepracovávanie už nemá zmysel. Presnejšie, nemáš dôvod — aj metriky sa zhoršia. Prídu manažéri a zavalí ťa požiadavkami na efektivitu. A ani sa ich nesnaž vysvetliť, že zlý kód sa určite vráti vo forme chýb — ty budeš mať z toho problémy. Môžeš si iba vziať na seba záväzok, že to už nebudeš robiť.
Ak práca ešte nie je odovzdaná, alebo je len na začiatku, tak nadávanie na kód (alebo jeho projekt, myšlienku) môže mať celkom praktický zmysel – človek to urobí poriadne.
Druhá cesta, tou najlepšou – zaoberať sa open-source vývojom vo voľnom čase. Cieľ totiž je, aby množstvo programátorov, presne programátorov, videlo tvoj kód a vyjadrilo sa k nemu. Vo firme nie je nikto čas. A programátorom na celom svete sa aj tak nič nechce robiť, a ak napíšeš niečo užitočné z praktického hľadiska, určite sa pozrú dovnútra.
Hlavná vec, podľa môjho názoru, je písanie kódu vo voľnom čase, pretože nebude fungovať rozpor medzi kvalitou kódu a rýchlosťou výsledku. Môžeš písať svoju vývoj dlhý rok. Nebude ťa tlačiť termíny, zadania, peniaze ani šéf. Úplná sloboda a kreativita.
Iba v slobodnej tvorbe pochopíš a precítiš, čo je to skvelý kód, uvidíš krásu programovacích jazykov a technológií, pocítiš pôvab obchodných úloh. A naučíš sa písať kvalitný kód.
Pravda, to si vyžaduje tvoje osobné časové náklady. Rovnako ako vlastne každé iné vzdelávanie. Ber to nie ako náklad, ale ako investíciu – do seba.
Zdroj: habr.com
