Jednou z nejvíce idiotských profesí jsou manažeři, kteří řídí programátory. Ne všichni, ale ti, kteří sami nebyli programátory. Ti, kteří si myslí, že je možné „zvýšit“ efektivitu (nebo zvýšit „efektivitu“?) pomocí metod z knih. Aniž bych se obtěžoval číst ty samé knihy, video je cikánské.
Ti, kteří nikdy nepsali kód. Ti, pro které se točí hollywoodské filmy o programátorech – inu, ty, kde sledují e-maily pomocí příkazového řádku. Ti, které nezajímá nic jiného než ukazatele, termíny a vlastní mzda.
Ti, kteří jsou většinou.
Ale jsou to idioti z jiného důvodu. Chtějí efektivitu, nebo alespoň efektivitu (no tak, manažere, Google jaký je rozdíl), aniž by chápali jedno nebo druhé. Bez obecného pochopení podstaty, procesu získávání výsledku, ztrát, ke kterým v tomto procesu dochází, nákladů na vývoj. Zkrátka práce s programátorem jako s černou skříňkou.
Narazili na vedení programátorů přesně z jednoho důvodu: je tam humbuk, peníze, trh a hromada stejných idiotů. Je kde se ztratit.
Kdyby byl humbuk ve výrobě strojních montáží, tak bychom tam běželi. Kombi jsou na hovno. Nedivil bych se, že ten, kdo v prosinci prodává vánoční stromky v našem sousedství, je IT manažer na dovolené.
Zkrátka, pokud je to možné, střelte těm chlapům do krku. Neboj, práci si najdou. Nikdo z nich nikdy neudělá nic slušného, dokud se sám nestane programátorem. Protože nechápe podstatu, mechanismus, logiku procesu, který řídí.
Dobře, dost o manažerech. Nyní k věci, pro programátory. Jak zvýšit efektivitu vývoje tím, že se naučíte psát vysoce kvalitní kód.
Chcete-li zvýšit efektivitu, musíte problémy řešit rychleji bez ztráty kvality. Chcete-li problémy řešit rychleji, musíte být schopni okamžitě psát vysoce kvalitní kód. A „vysoce kvalitní“ a „zapsat“ a „okamžitě“. Dovolte mi to vysvětlit metaforou.
Psaní kvalitního kódu je jako správně mluvit cizím jazykem. Když neznáte jazyk, trávíte spoustu času snahou formulovat v něm své myšlenky.
Potřebujete-li něco akutně říct, jen nalepíte některá slova, často ne správná, zapomenete na články, správný slovosled, nemluvě o slovesných časech a špatné výslovnosti.
Pokud máte čas na formulaci odpovědi, budete si muset otevřít slovník nebo online překladač a strávit spoustu času formulací svých myšlenek. Pocit však bude stále nepříjemný: říkáte odpověď a nevíte, zda je správná nebo ne. Stejné je to s kódem – zdá se, že byl napsán, zdá se, že funguje, ale zda je kvalitní nebo ne, je záhadou.
Ukazuje se, že je to dvojnásobná ztráta času. Přijít s odpovědí chce čas. Formulovat tuto odpověď také vyžaduje čas – a ne tak málo.
Pokud je přítomna dovednost psaní vysoce kvalitního kódu, pak může být odpověď formulována okamžitě, jakmile uzrála v hlavě, aniž byste museli trávit další čas překladem.
Schopnost psát vysoce kvalitní kód pomáhá při navrhování architektury. Jednoduše nebudete ve své hlavě uvažovat o nesprávných, nerealizovatelných nebo nepoužitelných možnostech.
Abych to shrnul: dovednost psát kvalitní kód výrazně urychluje řešení problémů.
Ale to není všechno. Díky správcům plstěných bot to má jeden háček – nemáme důvod psát vysoce kvalitní kód. Manažer se nedívá na kód, klient se nedívá na kód. Zřídka si navzájem ukazujeme kód, pouze někdy, v některých projektech, kde je určený kód „kontrola“ nebo periodické refaktorování.
Ukazuje se, že ve většině případů jde posraný kód do výroby nebo ke klientovi. Člověk, který napsal posraný kód, vytváří stabilní neuronové spojení – posraný kód je nejen možné napsat, ale je to také nutné – je to akceptováno a dokonce za to platí.
Tím pádem se dovednost psaní kvalitního kódu nemá vůbec šanci rozvíjet. Kód napsaný podmíněným zaměstnancem nikdy nikdo nekontroluje. Jediný důvod, proč se naučí normálně programovat, je vnitřní motivace.
Tato vnitřní motivace je však v rozporu s plány a požadavky na efektivitu a produktivitu. Tento rozpor zjevně není vyřešen ve prospěch vysoce kvalitního kódu, protože lidé ani nekritizují lidi za posraný kód. A za nesplnění plánu – i tak.
Co bych měl dělat? Vidím a navrhuji dvě cesty, které lze kombinovat.
První je ukázat svůj kód někomu uvnitř společnosti. Ne reaktivně (na požádání/vynucení), ale proaktivně (uh, kámo, podívej se na můj kód, prosím). Tady jde hlavně o to neposílat přeslazené soplíky, nesnažit se dát kritiku kodexu zdvořilou formou. Pokud je kód svinstvo, říkáme to: kód je svinstvo. S vysvětlením samozřejmě a doporučeními, jak to zlepšit.
Ale tato cesta je také taková. Jeho použitelnost závisí na bodě, ve kterém došlo ke kontaktu. Pokud se dílo již dostalo do výroby a ukáže se, že kód je svinstvo, nemá smysl ho předělávat. Přesněji důvody – metriky také klesnou. Manažeři přispěchají a rozdrtí vás požadavky na efektivitu. A ani se jim nesnažte vysvětlovat, že ten posraný kód se určitě vrátí ve formě chyb – obrátí se proti vám. Můžete se pouze zavázat, že už to neuděláte.
Pokud dílo ještě nebylo dodáno, nebo teprve začalo, tak vysypání sraček na kód (nebo jeho projekt, nápad) může mít docela praktický význam – ten člověk to normálně udělá.
Druhý způsob, ten nejúžasnější, je dělat vývoj open source mimo pracovní dobu. Jaký je cíl: aby parta programátorů, jmenovitě programátorů, viděla váš kód a mluvila o něm. Všichni ve firmě nemají čas. Programátoři po celém světě ale stále nemají co dělat, a pokud napíšete něco užitečného z aplikačního hlediska, určitě se podívají dovnitř.
Hlavním trikem je podle mě psaní kódu v mimopracovní době, protože rozpor mezi kvalitou kódu a rychlostí dodání výsledku nebude fungovat. Napište svůj vývoj alespoň na rok. Ani termíny, ani technické specifikace, ani peníze, ani šéf na vás nebudou tlačit. Naprostá svoboda a kreativita.
Pouze ve svobodné kreativitě pochopíte a pocítíte, co je skvělý kód, uvidíte krásu jazyka a technologie a pocítíte kouzlo obchodních úkolů. Naučíte se psát kvalitní kód.
Je pravda, že to bude vyžadovat, abyste trávili osobní čas. Stejně jako každý jiný vývoj. Nedívejte se na to jako na náklady, ale jako na investici – do sebe.
Zdroj: www.habr.com