Jedna část mé práce na všech projektech od doby, kdy jsem opustil svého prvního zaměstanavatele ve světě Dynamics AX, bylo zlepšit kvalitu softwarových produktů. To není náhoda – je to proto, že chci dělat kvalitní software and pomoci společnostem toho dosáhnout.

Vysoká kvalita je dobrá pro všechny – má očividné výhody pro uživatele, ale je dobrá i pro nás – nemusíme ztrácet tolik času podporou, hledáním chyb, vývojem a nasazováním oprav a tak dále a můžeme se soustředit na vývoj nových vlastností (to je naše skutečná práce, ne?). A samozřejmě, spokojení zákazníci nám spíše svěří další práci a doporučí nás svým obchodním partnerům.

Všechny ty společnosti, pro které jsem pracoval, cítily, že kvalita jejich produktů není příliš vysoká, nebo alespoň že je dobré o kvalitě mluvit. Zda byla kvalita skutečně jejich prioritou by bylo jiné vyprávění, nyní chci poukázat na celková očekávání ohledně zlepšování kvality. Abych citoval jistého manažera:

“Ty chceš měnit proces? My mysleli, že jen změníš něco v kódu.”

Tohle mi výrazně pomohlo pochopit, jak někteří lidé vidí zlepšování kvality softwaru – “kód je špatný, jdi do kódu, oprav kód”.

Zkuste se nad tím chvilku zamyslet. Kvalita našeho softwaru je nízká, protože jsme správně nepochopili požadavky, protože jsme navrhli suboptimální řešení, protože náš kód neřeší mnoho mezních situací, protože naše GUI není intuitivní a podobně. Jistě, všechny tyto věci mohou být opraveny, teoreticky – můžeme nově navrhnout vlastnosti, můžeme změnit technickou architekturu, můžeme přepsat kód. To může být extrémně nákladné a ty činnosti jsou vlastně stejné jako ty, které jsme dělali původně – a selhali jsme.  Bude to nyní lepší? A pokud chceme jen prohlédnout kód a trochu ho změnit, jak opravíme, co náš software dělá by design?

To, co doručujeme zákazníkům, je pouhý výstup procesu vytváření softwaru. Všechny ty analýzy požadavků, design GUI, návrh databáze, objektové modelování atd. definují produkt a jejich kvalita se odrazí v kvalitě produktu. Pokud náš software ignoruje důležité požadavky, nemůže být dobrý. Pokud naši vývojáři neví jak pracovat s výjimkami, celý produkt nebude zpracovávat výjimky správně. A tak dále.

Můžeme jen tak kouknout do kódu a změnit takový software na vysoce kvalitní? To je očividně nemožné. Pohledem do kódu nezjistíme, jaké požadavky jsme opomněli. To vyžaduje nový a lepší sběr požadavků. Stejně tak nemůžeme jednoduše přidat lepší zpracování výjimek – musíme udělat lepší analýzu možných výjimečných situací a jejich řešení. To vše jsme měli udělat lépe napoprvé.

Když lidé říkají, že kvalita jejich softwaru je nízká, automaticky to znamená, že kvalitní nejsou jejich postupy. Jejich process generuje nekvalitní software. Dokud není problematická část opravena, process bude stále generovat podobné výsledky.

Co vývojové týmy skutečně potřebují není někdo, kdo přijde a opraví jejich špatný kód. Potřebují přemýšlet o tom, jak pracují a jestli jsou všechny postupy dostatečně dobré. Potřebují identifikovat problémy a změnit postupy tak, aby se stejný problém neopakoval znovu. Musí si uvědomit, že to není jen o psaní kódu, a myslet také na kvalitu požadavků, návrhu atd. Bez všech těchto věcí nemohou lidé očekávat žádnou skutečnou změnu kvality.

Mimochodem, tohle je jedna z věcí, kde excelují iterativní postupy – v každé iteraci projdete všechny fáze projektu, takže vidíte, zda jsou funkční designy dostatečně dobré pro vývoj, zda je snadné přidávat nové vlastnosti do existujícího kódu, co si lidé myslí o GUI… A pokud něco jde špatně, můžete upravit process a vidět hned v další iteraci, zda došlo ke zlepšení.