Jak poznáte, že váš kód je kvalitní?
TLDR: Kolik patternů a best practices kód používá, vůbec nesouvisí s tím, jak moc je kód dobrý. Jediným ukazatelem kvality kódu je efektivita programátorů (a množství bugů).
Nedávno jsem narazil na vzdělávací video o programování, které na začátku obsahuje tuto větu:
Design patterns are best practice concepts that we can implement into our code to make it better in some way. Think of them as a guard rails that keep our code safe.Myslím si, že tento výrok krásně vyjadřuje, jakým způsobem spousta programátorů o patternech přemýšlí.
Problém je, že patterny mohou vést i ke zhoršení kódu a neexistuje jednoduchý způsob, jak poznat zlepšení nebo zhoršení, a každý samozřejmě bude tvrdit, že jeho použití je to, které kód zlepšilo.
Otázka je, jak poznat dobrý kód?
Programování jako UX design
Programování má až překvapivě hodně společného s UX designem:
- Cílem UX designéra je udělat aplikaci co nejpřehlednější a nejjednodušší pro uživatele.
- Cílem programátora je napsat (funkční) kód, který je co nejpřehlednější a nejjednodušší pro další programátory.
Jeden blog post krásně ukazuje tuto podobnost:
- Isn’t it frustrating when a screen is absolutely covered in information, yet the one thing you want to find isn’t there and it’s not clear how to get to it? Isn’t it frustrating when an object you want to use has 10 public methods, but only 3 of them are useful and if you call them in the wrong order your program crashes?
- Isn’t it frustrating when you input a bunch of info into an app then an error occurs and it throws it all away? Isn’t it frustrating when your code is super permissive when compiling but then throws tons of runtime errors instead?
- Isn’t it frustrating when an app labels its UI with meaningless buzzwords like “My Solutions”, “Insights”, etc. making it needlessly difficult to learn how to use it? Isn’t it frustrating when you have to maintain code with names like EntityOperationManager and you have absolutely no idea what it is for because each of those words has several different meanings and none of them are specific?
- Isn’t it frustrating when a trivial app takes 10 or 20 seconds to load? Isn’t it frustrating when it takes 10 minutes for your simple app to build so you can test your changes?
Díky této podobnosti se můžeme inspirovat tím, jak svou práci ověřují UX designéři.
Uživatelské testování
Uživatelské testování v UX designu funguje tak, že posadíte před aplikaci reálné lidi a zadáte jim konkrétní úkoly (např. “nakup zboží” nebo “změň si heslo”). Poté už jen mlčky sledujete. Nejde jen o to, jestli úkol splní, ale jak. Kde zaváhají? Hledají tlačítka tam, kde nejsou? Je pro ně ovládání intuitivní, nebo s ním bojují? Zkoumáte každé zadrhnutí, které narušuje plynulost jejich práce.
My jako programátoři se můžeme tímto způsobem testování inspirovat. Můžeme udělat následující:
- Sledovat sami sebe při programování - ztrácím se v kódu často? Hledám některé metody jinde, než kde jsou? Na které části implementace trávím nejvíc času?
- Stejný experiment můžeme dělat i s kolegy, například při párovém programování.
- Ideální situací je nový člen týmu - není zaslepený předchozími zkušenostmi a může kód posoudit z pohledu nového uživatele.
- Externí programátor - zajímavou možností je také přizvat člověka z jiného týmu a pozorovat ho při práci na vašem kódu. Je důležité zmínit, že tímto není myšlen nějaký teoretický audit kódu, ale reálná práce na vašem projektu.
Je jasné, že pro nového programátora bude pracné se v kódu vyznat. Nesmí to být ale výmluva, proč se nesnažit kód zlepšit. UX designéři také sledují lidi, kteří neumí s počítači, a snaží se jim co nejvíce pomoci designem jejich aplikace.
Závěr
Kolik patternů a best practices kód používá, vůbec nesouvisí s tím, jak moc je kód dobrý. Jediným ukazatelem kvality kódu je efektivita práce programátorů (a množství bugů).