Můj překlad článku What developers do all day?
Pokud jsi programátor, můžeš na konci dne smazat všechno, co jsi napsal a napsat to znovu zhruba za hodinu? Je dost možné, že ano. Proč to tak je? Je to pro to, že programátoři jsou líní přeplácení machírci? Ne. Je to proto, že se tu děje mnohem víc, než je na první pohled vidět. Vědomí toho, čím trávíme nejvíc času a pochopení z toho plynoucích výhod a nevýhod nám může pomoci být v práci efektivnější. Věřím, že nejvíce času trávíme zkoumáním, navrhováním, ověřovaním a (pak až) psaním kódu.
Zkoumání
Dave Moore se jednou zeptal kolegů v 8th Light “Kolik procent času trávíte zkoumáním kódu vs psaní kódu?” Typická odpověď byla, že tak 50-80% času stráví čtením nebo experimentováním s kódem. Je tahle činnost opravdu tak důležitá, aby zabrala tolik času?
K napsání elegantní aplikace je potřeba spousta času a experimentování. Programování je jako skládání puzzle. Jasně, že můžete jednotlivé kousky nějak zbastlit dohromady, ale pak budem mnohem těžší přidat nové kousky. Nakonec strávíte spoustu času nad stavebnicí a hledáním, kam který kousek patří než zakládáním kousků na jejich místa.
Navrhování / Designování
Proces navhrování aplikace může být buď přínosný nebo ztráta času, v závislosti na tom, jak se provádí. Některé společnosti stráví celé týdny nebo měsíce navrhováním aplikace předtím, než napíšou jedinou řádku kódu. Jiné firmy chápou, že zadání a požadavky jsou nestálé a chovají se podle toho. Často to znamená načtrnout nějaký rychlý model, jak by to asi mělo zhruba fungovat a pak s pomocí testů doladit aplikaci.
Přirovnal bych proces navrhování k dlouhodobému vztahu s někým. Na prvním rande taky neplánujete kolik budete mít dětí a kde budete bydlet nebo koho pozvete na svatbu. Seznámíte se a máte hrubou představu o tom, co od toho vztahu čekáte, kterou pak za běhu upravujete a přispůsobujete se.
Testování
Některé společnosti mají celé oddělení QA, aby zajistili, že jejich kód funguje. Ale ať už máte QA nebo ne, je to stejně na vývojářích, aby si ověřili, že jejich kód funguje. Je hodně způsobů, jak toho docílit. Můžete si psát unit testy, integrační testy, akceptační testy nebo jakékoliv jiné. Můžete si to taky všechno ověřovat ručně. Většinou je nejlepší jednotlivé způsoby testování kombinovat.
Pokud se spoléháte vyhrádně na jeden způsob testování, tak si neověřujete funkčnost svého kódu efektivně. Mít na všechno unit testy je super, ale dost možná zapomenete otestovat některé hraniční případy. Integrační testy jsou super, ale bývají pomalé. Ruční procházení svého kódu (s debuggerem) je určitě přínosné, ale časově náročné. Spoléhání se jen na jeden způsob testování je jako mít celou krabici nástrojů, ale používat jen jeden oblíbený (třeba kladivo :))
Psání kódu
Ve většina popisů práce se píše, že jste placení od toho, aby jste psali kód. Takže bychom měli vždycky usilovat o to, psát kód? Už jste asi uhodli, že si to nemyslím. To, že napíšeme nový kód, ještě neznamená, že jsme vytvořili nějakou hodnotu. Někdy je ta hodnota dokonce negativní!
Pokud strávíte dostatek času zkoumáním kódu, navrhováním řešení odolného změnám požadavků a implementujete různé testovací strategie, tak váš kód bude mít nejspíš velkou hodnotu. Bude to tedy efektivně vynaložený čas. Pokud můžete na konci dne všechno smazat a plus mínus během hodiny napsat znovu, tak pracujete efektivně.
Související články
Pokud se vám článek líbil, nezapomeňte ho sdílet na Facebooku, Twitteru či jinak 🙂