pondělí 22. srpna 2011

Technologický dluh vs. Overengineering

Technologický dluh je metafora popisující situaci, kdy vědomě či nevědomě uděláté technické rozhodnutí, které funguje v krátkodobém horizontu, ale z hlediska dlouhodobého vám může způsobit problémy. Příklad: máte kód pro přístup k databázi máte rozlezlý po celé aplikaci namísto, aby byl v jedné vrstvě.

Overengineering je případ kdy pro určití problém zvolíme příliš složité řešení. Příklad: potřebujete na HTTP vystavit XML dokument a nenapadne vás nic lepšího než použít Web Services se WS security dohromady.

Nikdy jsem si to neuvědomil, ale při vývoji jsou to právě tyto dvě kritéria nebo hranice, mezi kterými balancujeme. Zajímavé je, že příčinou tlaku jednoho nebo druhého jsou různé faktory. Product management nás tlačí do toho, abychom doručovali co nejrychleji nové vlastnosti a tedy nepřímo žili na technologický dluh (ten rozumný ví, že to jde jenom z části). Naopak naše inženýrská hrdost nás tlačí ke křišťálově čistým a někdy příliš komplikovaným řešením.

Vybalancování mezi technologickým dluhem a Overengineeringem je něco jako chůze na visutém laně. Jednoduše muže zavrávorat a spadnout na hubu. Nejde jednoduše říci jestli je lepší mít technologický dluh a nebo komplikovaná a překombinivaná řešení.

Důležitým faktorem je v jaké oblasti si technologický dluh a overengineering sekneme. Může to být design, vývoj, kód a deployment. Obecně jsme asi schopni akceptovat technologický dluh v kódu, protože s dodržením zapouzdření dokážeme izolovat problematickou část do jednoho místa a nenechat jej rozlézt jinam. Mnohem horší je to už na úrovni designu, kde se každá chyba násobí každou fází, kterou se projde až k samotnému nasazení.

Nenapadá mě žádná poučka snad kromě: dělejte věci tak jednoduše jak to jde, ale ne jednodušeji.

K tomuhle opravdu krátkému zamyšlení dodám tři odkazy na téma technologický dluh.