Jedním z nejvíce přetížených idiotů mezi profesemi jsou manažeři, kteří řídí programátory. Ne všichni, ale ti, kteří nikdy samotnými programátory nebyli. Ti, kteří si myslí, že je možné "zvyšovat" efektivitu (nebo zvyšovat "efektivitu"?) metodami z knížek. Dokonce se ani neobtěžují ty nejrůznější knížky přečíst – vždyť existuje videíčko, že?
Ti, kteří nikdy nepsali kód. Ti, pro které natočili hollywoodské filmy o programátorech – ano, ty, kde se elektronická pošta sleduje z příkazového řádku. Ti, které nezajímá nic jiného než ukazatele, termíny a vlastní plat.
Ti, kterých je většina.
Ale idioti jsou z jiného důvodu. Chtějí efektivitu, nebo alespoň výsledky (tak jdi, manažere, googli, jaký je rozdíl), aniž by rozuměli jednomu nebo druhému. Vůbec nechápou podstatu, proces dosažení výsledku, ztrát, které v tomto procesu vznikají, nákladů na vývoj. Zkrátka, pracují s programátory jako s černou skříňkou.
Přicházejí k řízení programátorů přesně z jednoho důvodu: tady je hype, peníze, trh a spousta dalších idiotů. Je tu, kde se ztratit.
Kdyby byl hype v mechanosmontážní výrobě – běželi by tam. Universální neschopní. Nebudu se divit, když chlapík, který v prosinci prodává stromy v našem bloku, je IT manažer na dovolené.
Zkrátka, pokud máte tu možnost, pošlete tyhle kluky pryč. Nebojte se, najdou si práci. Nikdo z nich nikdy neudělá nic slušného, dokud se sám nestane programátorem. Protože nechápou podstatu, mechanismus, logiku procesu, kterým řídí.
Tak, dost o manažerech. Teď k věci, pro programátory. Jak zvýšit efektivitu vývoje tím, že se naučíte psát kvalitní kód.
Abychom zvýšili efektivitu, musíme rychleji řešit úkoly, aniž bychom ztratili kvalitu. Abychom rychleji řešili úkoly, musíme umět okamžitě psát kvalitní kód. A „kvalitní“, a „psát“, a „okamžitě“. Vysvětlím na metaforě.
Psát kvalitní kód je jako správně mluvit cizím jazykem. Když jazyk neznáte, trávíte spoustu času tím, abyste formulovali na něm své myšlenky.
Pokud je potřeba rychle říct něco, prostě nalepíte nějaká slova, často ne ta správná, zapomenete na články, správný pořádek slov, nemluvě o časech sloves a chabé výslovnosti.
Pokud máte čas na formulaci odpovědi, budete muset otevřít slovník nebo internetový překladač a strávit spoustu času formulováním svých myšlenek. Pocit, pravda, bude stejně nepříjemný: odpovídáte a nevíte, jestli je to správné nebo ne. Podobné je to s kódem - jako byste napsali, jako by to fungovalo, ale jestli je kvalitní nebo ne - to netuším.
Vytváří to tedy dvojnásobnou ztrátu času. Na to, abyste vymysleli odpověď, se ztrácí čas. Na to, abyste tuto odpověď formulovali, také ubíhá čas – a to rozhodně není málo.
Pokud však dovednost psaní kvalitního kódu existuje, můžete odpověď formulovat hned, jakmile se uzraje ve vaší hlavě, aniž byste trávili další čas překladačem.
Dovednost psaní kvalitního kódu pomáhá při návrhu architektury. Jednoduše nebudete v hlavě zvažovat nesprávné, nerealizovatelné nebo hloupé možnosti.
Shrnuto: dovednost psaní kvalitního kódu výrazně urychluje řešení úkolů.
Ale to není všechno. Díky manažerům, máme jeden problém – tak či onak, nemáme důvod psát kvalitní kód. Manažer se na kód nedívá, klient se na kód nedívá. Navzájem si kód ukazujeme zřídka, jen někdy, v některých projektech, kde je určený "kontrolor" kódu nebo občasná refaktoring.
Ve většině případů tak tedy odchází do produkce nebo ke klientovi špatný kód. U člověka, který napsal špatný kód, se utváří stabilní neuronová vazba – psát špatný kód není jen možné, ale dokonce nutné – přijímají ho a ještě za to platí.
Nakonec tedy není šance na rozvoj dovednosti psaní kvalitního kódu. Kód napsaný běžným zaměstnancem nikdo a nikdy neprověřuje. Jediný důvod, proč se naučí normálně programovat – vnitřní motivace.
Ale tato vnitřní motivace vstupuje do rozporu s plány a požadavky na efektivitu a produktivitu. Toto napětí se očividně neřeší ve prospěch kvalitního kódu, přece jen za špatný kód vás ani nemusí kárat. Ale za neplnění plánu – určitě.
Co teď? Vidím a navrhuji dvě cesty, které lze kombinovat.
První je ukazovat svůj kód někomu v rámci firmy. Ne reaktivně (když o to požádají/nutí), ale proaktivně (hele, kámo, koukni se na můj kód, prosím). Hlavní je, nebýt příliš jemný, nesnažit se obalit kritiku kódu do zdvořilé formy. Pokud je kód špatný, říkáme, že je špatný. Samozřejmě s vysvětlením a doporučeními, jak ho zlepšit.
Ale ani tato cesta není ideální. Její použitelnost závisí na bodu, ve kterém došlo ke kontaktu. Pokud je práce již nasazená v produkci a ukáže se, že kód je špatný, nemá smysl ho přepracovávat. Přesněji, motivace — metriky se totiž zhorší. Přiběhnou manažeři a zatlačí na efektivitu. A ani se nesnaž jim vysvětlit, že špatný kód se nutně vrátí v podobě chyb — to ti nakonec uškodí. Můžeš si jen vzít za závazek, že to už nebudeš dělat.
Pokud však práce ještě není odevzdána, nebo právě začíná, pak kritizování kódu (nebo jeho projektu, nápadu) může mít zcela praktický smysl – člověk to udělá pořádně.
Druhá cesta, ta nejlepším způsobem – zapojit se do vývoje open source ve volném čase. Cílem je, aby spousta programátorů, právě programátorů, viděla tvůj kód a vyjádřila se k němu. Ve firmě není čas. A světoví programátoři nemají co dělat, a pokud napíšeš něco užitečného z praktického hlediska, určitě se podívají dovnitř.
Hlavní myšlenka, podle mého názoru, je psát kód ve volném čase, protože pak nebude konflikt mezi kvalitou kódu a rychlostí výstupu. Klidně piš svou aplikaci rok. Nebudou na tebe tlačit žádné termíny, technické požadavky, peníze ani šéf. Úplná svoboda a kreativita.
Jen v rámci svobodné kreativity pochopíš a pocítíš, co to znamená skvělý kód, uvidíš krásu programovacích jazyků a technologií, zažiješ kouzlo obchodních úloh. A samozřejmě se naučíš psát kvalitní kód.
Pravda, to si bude vyžadovat tvé osobní časové náklady. Stejně jako jakýkoliv jiný rozvoj. Vnímej to ne jako náklady, ale jako investici – do sebe.
Zdroj: habr.com
