Pokud vás na tento blog post nezavál Google při snaze najít informace o jisté formě tělesného kontaktu a patříte naopak mezi standardní čtenáře DevBlogu, určitě jste už slyšeli o jednom z nejprovařenějších návrhových principů, KISS neboli “keep it simple stupid”. Aspoň z mého pohledu je tak ohraný a tisíckrát zopakovaný, že už mi kolikrát ani nestál za zamyšlení, ale tuhle jsem si tak říkal, jak vlastně děláme software, a že tam vlastně něco zajímavého je.
Jak se KISS definuje? Na Wikipedii třeba takto:
The KISS principle states that most systems work best if they are kept simple rather than made complex, therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.
Tato definice, nebo různé variace na ni, zdůrazňují, že by systémy měly být zachovány jednoduché, což evokuje, že systémy jsou v základu jednoduché a my je jen svou prací komplikujeme, pokud si nedáváme pozor.
Nevím, jak to chodí u vás, ale u mě a na projektech, na kterých dělám, je to často úplně naopak – ten nejintuitivnější, “výchozí” design je většinou relativně komplikovaný a k jednoduchosti se dopracovává postupně a nezřídka namáhavě. Platí to skoro pro cokoliv:
- U uživatelských rozhraní je daleko jednodušší naflákat na obrazovku nebo do různých dialogů ovládací prvky pro každou blbost, skutečné umění je udělat rozhraní přehledné a srozumitelné (a to nutně nemusí být ekvivalentní s “jednoduchým” – například GitHub nebo DropBox mi připadají designově jednoduché, ale přesto se mi v nich poměrně špatně orientuje).
- U kódu bývá daleko jednodušší udělat ho složitý a nepřehledný, jednoduchost je něco, k čemu programátor roste a často je to proces na roky nebo i desetiletí života.
- Testovací kód je totéž – nepřehledné a ve výsledku neužitečné testy je daleko jednodušší udělat než ty, které mají skvělý poměr přidané hodnoty a vynaložené práce.
Skutečně mám spíš problém vymyslet příklady toho, kdy by to v našem oboru fungovalo tak, že věci jsou by default jednoduché. Samozřejmě, jsou lidé, kteří mají na jednoduchost čich nebo talent, a je radost mít takové v týmu, ale takových nechodí po světě moc a my ostatní, běžní smrtelníci naopak tíhneme ke komplexním a zbytečně přetechnizovaným řešením.
Dělat věci jednoduché je tedy práce. Tvrdá práce. Proto bychom o tomto principu měli přemýšlet radši jako o MISS – “make it simple stupid”.
Ahoj Borku,
zajímavé téma k zamyšlení.
podle mě se tahle zásada snaží zabránit over-engineeringu a feature hell.
“Keep” je tam zcela legitimně. Vždy začínáš jednoduše – nemáš vůbec nic. A postupně přidáváš a rozšiřuješ, ať už děláš design, OOP kód, algoritmus nebo nedělní palačinky. KISS se snaží říct, že ti požadavek na jednoduchost má pořád viset někde vzadu v hlavě. Pokud necháš systém přebujet, tak pak ti nezbude nic jiného, než jít a prořezávat.
Problém je v tom, že neděláš iterativní design, který začínáš s minimem funkcí. To samé co se dělá v TDD s kódem se dá rozšířit na celou aplikaci/službu. Pak máš KISS a nemusíš řešit MISS. Ale opět narážíme na to, že oba máme nejspíš opačné vnímání světa a přístup k žešení problémů. :)
Jakube, souhlasím a princip KISS nijak nezpochybňuju. Podle mě je dobře, že je formulovaný tak, jak je, a hezky pointu vystihuje tvoje poznámka o tom, že by to stále mělo viset někde vzadu v hlavě. U mnoha projektů je však jednoduchost často výsledkem úsilí než něčím automatickým, proto tento blog post. Je to jen takové malé zamyšlení.
Aleši, jsem moc rád, že si to uvědomuješ, a nejsem moc rád, že máš potřebu mi to neustále opakovat :)
Já na skoro každém projektu, co jsem, bojuji s jeho komplexitou, ne s jeho jednoduchostí (platí i u projektů, které se dělají iterativně a na zelené louce). Není vyloučené, že jsi jedním z lidí, jejichž první nápad na řešení už nejde zjednodušit, ale pro většinu lidí to neplatí. O tom byl ten blog post.
Asi jen těžko bych tě mohl podezírat ze špatné znalosti angličtiny, Borku, ale přijde mi, jako bys tu postavil pěknou myšlenkovou konstrukci na tom, že chápeš “keep” jen v jednom z více významů – tj. jako “udržovat”. Jenže “keep” má taky význam “držet (na uzdě), brzdit, krotit”, příp. “pojmout (co jak)”, který přesně ten význam MISS pokrývá a v němž to rodilí mluvčí (taky) chápou.
Petře, jsem si toho vědom a před psaním jsem ještě pro jistotu koukal do slovníku na všechny možné významy. Proto (a nejen proto) ani nikde nepíšu, že bych s KISS nesouhlasil, místo “znamená” jsem použil “evokuje” apod., přesto jsem to chtěl tuto krátkou úvahu sepsat, protože mnoho lidí (podle mých minulých zkušeností) předpokládá, že když nebudou dělat skopičiny a systémy nebudou vědomě komplikovat, tak zůstanou “simple”. Moje zkušenost je spíš opačná – i pokud se “normální” člověk chová “normálně”, výstupem většinou není jednoduchá, ale nějakým způsobem komplikovaná věc.
wtz. A pokuds to psal s tímhle vědomím, tak jenom dobře. Tohle by se mělo vývojářům (a hlavně projekťákům!) vtloukat do hlav už od mateřinky: mezi komplikovaností vývoje a komplikovaností výsledného produktu platí nepřímá úměra. Čím jednodušší je apliakce pro vývojáře, tím složitější je pri uživatele, a opačně. Ona ta KISS-jednoduchost dá někdy zatraceně spoustu práce.
Myslím, že by bylo dobré se zamyslet nad tím, o čem vlastně píšete, Borku. Podle mého mluvíte víc než o čemkoli jiném o “zobecnění”. Něco jako když se pokoušíte vyjádřit hlavní znaky toho, co je třeba “strom”.
Všichni tak nějak víme, co je to strom a málo kdy se dostaneme do sporu, typu, to už není strom, ale křoví. Ale zkusme se shodnout na tom, jaké vlastně všechny znaky jsou pro strom důležité. Ano asi kmen, větve … ale je to opravdu úplná definiční množina? Není moc malá? Jaké všechny znaky musí být TRUE, aby to byl pro nás strom? Není třeba i více různých variací nad poměrně širokou množinou znaků? Atd. A´t tak nebo tak, na požádání kdykoli nakreslíme útvar ve kterém ostatní poznají, že jde o strom.
Nevím, jestli mi bude rozumět, ale v jistém smyslu tu vidím paralelu. Pokud tvoříte nějakou aplikaci, je to nějaké konkrétní provedení v rámci nějakého tématu. Eshop musíte udělat tak aby to byl eshop a nebyla to wikipedie, i když budou mít mnoho prvků společných. A otázka je, co vlastně dělá eshop eshopem. Lépe řečeno, co vše vlastně dělá eshop eshopem? A to i v rovině UX, GUI atd. … a hlavne, jestli to umíme vyjádřit zkratkou, podobně, jako v případě stromu.
V případě stromu máte výhodu, že napozorováno desítky tisíc variant stromu a se stovkami i tisíci jste byl i v přímé interakci (mj. mnohokrát jste viděl i les v jeho nejrůznějších formách – což také hraje roli).
Podle mého prostě záleží, jak moc už máte úlohu, kterou se snažíte vyjádřit pomocí aplikace, abstrahovanou – zobecněnou. Čím méně, tím více musíte o věci přemýšlet a více hledat co vlastně máte vyjádřit současně s tím jak. Čím více věc máte zobecněnou, tím spíše dokážete udělat aplikaci na první pokus “správně”, protože pak už vlastně jen řešíte jestli to má být malý strom, listnatý strom atd. a nikoli, co vlastně musíte udělat, aby to byl pořád strom. Totiž už to, že poznáte, že je to strom na první pohled, znamená, že jste se jako “divák” či “uživatel” dokázal rychle zorientovat – čili víte pak, kde hledat tu kterou část stromu.