Špatných návyků je těžké se zbavit a ještě těžší je, pokud si neuvědomujete, že to, co děláte, podkopává vaši práci. Pokud to víte, ale je vám to jedno – to by bylo nejhorší. Ale jsi tady, ne?“
Jako programátor jsem viděl spoustu špatných praktik, a to nejen kolem kódu, ale také kolem dovedností týmové práce. Sám jsem se provinil praktikováním mnoha z těchto špatných návyků. Zde je mých 35 nejčastějších špatných programátorských návyků, rozdělených do čtyř kategorií: organizace kódu, týmová práce, psaní kódu a testování a údržba.
Organizace kódu
1. Říkání: „Opravím to později“
Zvyk odkládat opravy kódu není jen problém priorit. Organizace sledování problémů může přinést určitý pokrok, ale musíte mít také způsob, jak sledovat menší problémy, které se objeví. Přidávání komentářů „TODO“ je rychlý způsob, jak se ujistit, že vám nic neunikne.
2. Trvání na jednořádkovém řešení
Být posedlý psaním efektivních a elegantních kusů kódu je běžnou vlastností programátorů. Je to jako řešení hádanky – najdete kombinaci funkcí a regulárních výrazů, které z 20 řádků kódu udělají 2 nebo 3 řádky. Bohužel to ne vždy vede k čitelnému kódu, a to je obecně mnohem důležitější výsledek. Nejdřív udělejte kód přístupný, pak teprve chytrý.
3. Provádění nesmyslných optimalizací
Dalším místem, kde často chybujeme, jsou optimalizace. Zní to skvěle, když zmenšíte velikost webu o pár bajtů, ale nevynahradí vám to stejně gzip? A nejsou důležitější požadavky? Optimalizacemi se zabývejte až na konci projektu, protože nejčastěji se požadavky změní a váš čas přijde vniveč.
„Předčasná optimalizace je kořenem všeho zla.“
-Donald Knuth
4. Optimalizace a optimalizace – to je vše. Přesvědčení, že problémy se stylem kódování nejsou tak důležité
Pokud jsem se za léta sledování kódu jiných lidí něco naučil, tak to, že řešení problémů se stylem kódování je věc, kterou vývojáři nejčastěji odkládají. Možná je pro nezkušené programátory těžké pochopit, co dobrého přinese řešení problémů se stylem, ale časem se ukáže, že jakmile kvalita kódu vykolejí, efekt sněhové koule promění jakýkoli projekt v naprostý zmatek. Dbejte přísně na osvědčené postupy, i když se zdají být zanedbatelné. Nastavte si nástroje pro kontrolu kódu a lintování, abyste měli prostor starat se o důležitější věci.
5. Zkontrolujte, zda se vám podařilo vytvořit správný kód. Zametání věcí pod koberec
Buď chytáním a ignorováním výjimek, nebo používáním knihoven, které nehlásí chyby (například jQuery), existuje mnoho způsobů, jak zamést věci pod koberec. Když se však některá z těchto chyb stane prioritou, bude její oprava mnohonásobně náročnější vzhledem k tomu, že nebudete mít tušení, kde začít. Snadným způsobem, jak tomu předejít, je zaznamenávat tyto ignorované chyby, abyste je mohli později prostudovat.
6. V případě, že se vám to nepodaří, můžete se obrátit na správce. Používání názvů, které nepřidávají informace
Pojmenování je těžké, ale existuje snadný způsob, jak se ujistit, že názvy vašich proměnných a funkcí mají alespoň slušnou kvalitu. Pokud názvy přidávají nějakou informaci, kterou zbytek kódu nesděluje, budou mít ostatní vývojáři snazší čtení vašeho kódu. Důvod, proč je pojmenování tak důležité, spočívá v tom, že názvy mohou poskytnout obecnou představu o tom, co kód dělá. Pokud se musíte hrabat ve výpočtech, abyste zjistili, co která část kódu dělá, zabere to více času, ale dobrý název vám pomůže pochopit, co kód dělá, během několika sekund.
7. Ignorování osvědčených osvědčených postupů
Revize kódu, vývoj řízený testy, zajištění kvality, automatizace nasazení – tyto postupy a několik dalších se osvědčily v nesčetných projektech, a proto o nich vývojáři neustále blogují. Skvělou referencí pro tyto osvědčené postupy je kniha Making Software: Co skutečně funguje a proč tomu věříme. Věnujte čas tomu, abyste se naučili, jak je správně provádět, a váš vývojový proces se zlepší ve všech vašich projektech způsobem, který vás překvapí.
Týmová práce
8. Vývojové postupy a jejich aplikace. Příliš brzké opuštění plánů
Zaručeným způsobem, jak učinit váš systém nevyzpytatelným, je nezavázat se k žádnému plánu. Vždy, když je váš kód kritizován, můžete říci, že plán není kompletní. Mít napůl hotové moduly však povede k těsně provázanému kódu, jakmile se pokusíte tyto nedokončené moduly vzájemně zprovoznit. Tento druh komplikací se také objeví, když se změní role ve vedení projektu a noví vedoucí se rozhodnou, že mít to po svém je důležitější než architektonická konzistence.
9. V případě, že se v projektu změní role vedoucího, může se stát, že se v něm objeví další komplikace. Trvání na plánu, který má jen malou šanci fungovat
Stejně jako opuštění plánů může způsobit problémy, tak i lpění na plánu, který nefunguje. Proto byste se měli o své nápady podělit se svým týmem, abyste získali zpětnou vazbu a radu, když se věci začnou komplikovat. Někdy může jiný pohled na věc rozhodnout.
10. Pracujte stále sami na sobě
Měli byste se snažit sdílet své pokroky a nápady s týmem. Někdy si myslíte, že něco budujete správně, ale není tomu tak, takže neustálá komunikace je velmi cenná. I pro ostatní lidi je přínosné, když s nimi spolupracujete. Jejich práce se často zlepší, když s nimi diskutujete o nápadech a mentorujete méně zkušené členy týmu, u kterých je větší pravděpodobnost, že se zaseknou.
11. Zlepšete se, když s nimi budete diskutovat o nápadech. Odmítání psaní špatného kódu
V životě každého vývojáře přijde chvíle, kdy vás termíny donutí napsat příšerný kód, a to je v pořádku. Zkoušeli jste klienta nebo manažera varovat před následky, ale oni trvají na dodržení termínu, takže teď je čas kódovat. Nebo se možná objevila naléhavá chyba, která nemůže počkat, až přijdete s čistým řešením. Proto je důležité být jako programátor všestranný a umět velmi rychle napsat špatný i dobrý kód. Doufejme, že se k tomuto kódu budete moci vrátit a splatit technický dluh.
12. Jaké jsou vaše možnosti? Obviňování ostatních
Není žádným tajemstvím, že arogance je mezi vývojáři a dalšími technickými profesionály až příliš častou vlastností. Přebírání odpovědnosti za své chyby je ctnost, díky které mezi svými kolegy zazáříte. Nebojte se přiznat, že jste udělali chybu. Jakmile se s tím smíříte, budete se moci soustředit na to, abyste se naučili, proč jste tuto chybu udělali a jak se jí vyvarovat. Pokud si chybu nepřiznáte, učení se stane nemožným.
13. Přiznejte si, že jste udělali chybu. Nepodělení se s týmem o to, co jste se naučili
Vaši hodnotu jako vývojáře nemá jen kód, který napíšete, ale také to, co se při jeho psaní naučíte. Podělte se o své zkušenosti, napište k němu komentář, dejte ostatním vědět, proč jsou věci tak, jak jsou, a pomozte jim dozvědět se nové věci o projektu a jeho záludnostech
. 14. Jaké jsou vaše zkušenosti? Příliš pomalé poskytování zpětné vazby manažerům/klientům
Jedna z nejcennějších povahových vlastností každého řemeslníka spočívá v tom, že se snaží, aby všichni byli ohledně práce pokud možno na stejné vlně. Důvodem není to, aby váš manažer mohl plnit tabulky. Je to i pro váš vlastní prospěch: Budete mít méně nejistoty a snížíte nejistotu ohledně životnosti a budoucnosti projektu.
15. V případě, že se vám to podaří, budete mít méně jistoty. Nepoužíváte dostatečně Google
Nejlepším způsobem, jak rychle vyřešit složitý problém, je nemuset ho řešit vůbec. Když máte pochybnosti, vygooglujte si ho. Samozřejmě můžete místo toho obtěžovat inženýra vedle sebe, ale málokdy vám bude schopen odpovědět tak podrobně jako na Stack Overflow, nehledě na to, že tím budete rušit i jeho práci.
16. Zkuste se podívat, co se děje. Přeceňování svého osobního stylu
Vždy se snažte sladit svůj pracovní styl a nastavení prostředí se svým týmem. V ideálním případě by všichni ve vašem týmu měli pracovat v podobných podmínkách a dodržovat stejný styl kódování. Dělat věci po svém může být zábavnější, ale spolupracovníci nemusí být na váš styl kódování zvyklí, a pokud je neobvyklý, bude pro dalšího vývojáře obtížnější pracovat na tom, co jste vytvořili.
17. Jaký je váš styl kódování? Mít ke svému kódu osobní vztah
Když někdo komentuje váš kód, neberte si to osobně. Váš kód by měl stát na pevných základech, to znamená, že byste měli být schopni vysvětlit, proč jste ho napsali právě takto. Pokud potřebuje vylepšit, je to pouze odrazem správnosti kódu, nikoliv vaší osoby.
Psaní kódu
18. V případě, že kód není správně napsán, je to pouze odrazem jeho správnosti. Nevíte, jak optimalizovat
Dobrá optimalizační strategie vyžaduje určité zkušenosti. Vyžaduje zkoumání, analýzu a znalost všech systémů zapojených do procesu. Informujte se o těchto věcech. Zjistěte si něco o složitosti algoritmů, vyhodnocování databázových dotazů, protokolech a obecně o tom, jak měřit výkonnost
. 19. Zjistěte si něco o optimalizaci. Používání nesprávného nástroje pro danou úlohu
Můžete toho vědět jen tolik, ale důvod, proč se musíte neustále učit, je ten, že každý nový problém přináší jiný kontext a vyžaduje jiný nástroj – takový, který je pro danou úlohu použitelnější. Buďte otevřeni novým knihovnám a jazykům. Nerozhodujte se striktně na základě toho, co znáte.
20. Vyzkoušejte si, co umíte. Nezatěžujte se zvládnutím nástrojů a IDE
Každá nová klávesová zkratka, klávesová zkratka nebo parametr, které se naučíte při používání nástrojů, s nimiž denně pracujete, budou mít na rychlost vašeho kódování pozitivnější vliv, než si myslíte. Nejde o to, že použitím klávesové zkratky ušetříte pár vteřin; jde o zkrácení přepínání kontextu. Čím více času strávíte každou drobnou činností, tím méně času budete mít k dispozici na přemýšlení o tom, proč ji provádíte a co bude následovat. Zvládnutí klávesových zkratek uvolní vaši mysl.
21. V případě, že se budete chtít naučit pracovat s klávesovými zkratkami, můžete je použít. Ignorování chybových hlášení
Nepředpokládejte, že víte, co je v kódu špatně, aniž byste si přečetli chybové hlášení, nebo že na to přijdete dostatečně rychle. Mít o problému více informací je vždy lepší a věnovat čas jejich shromáždění vám z dlouhodobého hlediska ušetří více času.
22. Zjistěte, co se děje s chybovými hlášeními. Romantizace sady vývojářských nástrojů
Někdy není váš preferovaný editor nebo nástroj příkazového řádku tím nejlepším nástrojem pro danou práci. Visual Studio je skvělé pro psaní IDE, Sublime je skvělý pro dynamické jazyky, Eclipse je skvělý pro Javu atd. Možná máte rádi vim nebo emacs, ale to neznamená, že je to ten správný nástroj pro každou práci.
23. Vim nebo emacs můžete mít rádi. Kódování hodnot natvrdo místo jejich konfigurovatelnosti
Vždy myslete na to, jaké změny mohou přijít a jak se s nimi vypořádat. Technický dluh poroste obludným tempem, pokud neoddělíte pohyblivé části od zbytku práce. Tam, kde je to vhodné, používejte konstanty a konfigurační soubory.
24. Neustálé vynalézání kola
Nepište kód, který nepotřebujete. Možná už někdo jiný strávil nad vaším problémem spoustu času a možná má dobře otestované řešení, které můžete znovu použít.
25. Ušetřete si práci. Slepé kopírování/vkládání kódu
Než kód znovu použijete, porozumějte mu. Někdy si na první pohled hned nevšimnete, co všechno kód dělá. Více se o problému dozvíte také tehdy, když věnujete čas podrobnému přečtení kódu.
26. Zkuste si kód přečíst podrobněji. Nevěnujete čas tomu, abyste se dozvěděli, jak věci skutečně fungují
Vždy využijte příležitosti rozšířit své znalosti tím, že budete přemýšlet o tom, jak věci fungují, a přečtete si o jejich základních problémech. Možná ušetříte čas tím, že se tím teď nebudete zabývat, ale to, co se na projektu naučíte, bude z dlouhodobého hlediska důležitější než jeho skutečná realizace.
27. Nebudete-li se snažit o to, abyste se naučili, jak se věci mají. Přílišná důvěra ve vlastní kód
Je nebezpečné předpokládat, že jen proto, že jste něco napsali, to musí být skvělé. Při práci na nových věcech a získávání zkušeností se o programování dozvídáte více, proto se čas od času podívejte na svůj starý kód a zamyslete se nad tím, jak jste pokročili.
28. Jak se vám daří programovat? Nepřemýšlíte o kompromisech každého návrhu, řešení nebo knihovny
Každý produkt má své jemné stránky, které poznáte až při jeho používání a analýze. Když uvidíte několik příkladů použití nějaké knihovny, neudělá to z vás jejího mistra, ani to neznamená, že je ideální pro každou situaci, která ve vašem projektu nastane. Buďte neustále kritičtí ke všemu, co používáte.
29. Kterou knihovnu používáte? Nevyhledání pomoci, když se zaseknete
Udržování krátké zpětné vazby pro vás bude vždy méně bolestivé. Požádat o pomoc neznamená, že jste neschopní. Správní lidé budou vaši snahu a přiznání neznalosti chápat jako snahu učit se, a to je velká ctnost.
Testování a údržba
30. Jak se naučit něco nového? Psaní testů tak, aby prošly
Psaní testů, o kterých víte, že projdou, je nezbytné. Díky nim bude refaktorizace a reorganizace projektu mnohem bezpečnější. Na druhou stranu je třeba psát i testy, o kterých víte, že neprojdou. Jsou nezbytné k tomu, abyste projekt posunuli dál a měli přehled o problémech.
31. Jaký je váš názor? Opomíjení výkonnostních testů pro kritické případy
Přibližně v polovině procesu vývoje projektu si připravte automatické nastavení výkonnostních testů, abyste se mohli ujistit, že nebudete mít eskalující problémy s výkonem.
32. V případě, že se vám nepodaří vyřešit kritické případy, můžete si připravit automatické nastavení výkonnostních testů. Nekontrolujete, zda sestavení funguje
Málokdy se stane, že sestavení projde, ale ve skutečnosti nefunguje, ale může se to stát, a čím déle budete čekat, než se na problém podíváte, tím nepříjemnější může být jeho odstranění. Rychlé otestování každého sestavení je důležitým návykem.
33. V případě, že sestavení nefunguje, je potřeba ho rychle otestovat. Prosazování velkých změn pozdě nebo odchod po provedení velkých změn
Tady vás dostane přílišná sebedůvěra a může trvat, než se několikrát spálíte, abyste se naučili, proč byste to neměli dělat, takže se teď řiďte mou radou a ujistěte se, že jste vždy u toho, když se vaše sestavení nakonec rozbije.
34. V případě, že se vaše sestavení rozbije, je třeba, abyste to udělali. Zřeknutí se kódu, který jste napsali
Buďte ochotni podporovat kód, který jste napsali. Jste nejvhodnější osobou pro to, abyste ho pomohli pochopit ostatním. Měli byste usilovat o to, aby váš kód zůstal čitelný pro vás i pro ostatní i za mnoho let.
35. Zkuste se podívat na to, co jste udělali. Ignorování nefunkčních požadavků
Když se snažíte něco dodat, může být snadné zapomenout na některé důležité oblasti, jako je výkon a bezpečnost. Pro ty si veďte kontrolní seznam. Nechcete přece, aby vám zničily večírek, protože jste sestavili termíny, aniž byste mysleli na tyto nefunkční záležitosti.
Jaké jsou vaše nejhorší programátorské návyky?
Jak se často říká, jsme tvorové zvyku. Zlepšení způsobu práce pomocí návyků je skvělý způsob, jak se vyhnout tomu, abyste museli nad každou jednotlivou situací příliš přemýšlet. Jakmile si osvojíte dobrý způsob, jak něco dělat, stane se to bezproblémovým.