Category Archives: Uncategorized

Soustřeďme se na jednu věc

Dneska mi (znovu) došla jedna věc. Tím jak se snažím dělat spoustu věcí najednou, udělám toho mnohem míň. Teď nemluvím o moderní roztěkanosti, o tom, že potřebuji zkontrolovat zprávy na internetu několikrát do hodiny.

Ne. Mluvím o tom, že když něco děláme, neumíme si vybrat co to vlastně bude a proč to děláme. Mám několik příkladů. Dnes jsem se třeba pustil do opravy chyby a zároveň refaktoringu. Nakonec jsem se v tom úžasně zamotal. Proč? Protože jsem se snažil splnit dva odlišné cíle najednou. Naštěstí jsem si to uvědomil už po hodině bloudění, vrátil se na začátek a jen opravil tu chybu. To bylo relativně jednoduché. Refaktoring nás bohužel ještě čeká, ale až ho budeme dělat, nebudeme si muset lámat hlavu s nějakou chybou.

Další příklad je podobný. Měli jsme produkční problém. Na něj jsme nasadili záplatu, která jakž takž drží. Ale protože jsme pečliví, vyrobili jsme si další task, v kterém to chceme opravit pořádně. No jo, ale když už to děláme, tak proč k tomu něco nepřidat, že? Třeba docela velikou architektonickou změnu.

Proč mi to vadí? Vždyť je to jedno, ne? Není. Dokud nemáme jasno v tom proč něco děláme, tak si hrozně komplikujeme život. Je snadné se ztratit v tom, jestli řešíme akutní problém, který musí být vyřešen co nejdřív nebo jestli předěláváme infrastrukturu, což bude potřeba za pár měsíců. Je nemožné určit prioritu. Pokud by to byla oprava produkčního průšvihu, tak by to mělo prioritu velikou. Pokud je to „jen“ příprava na budoucnost, tak by to mohlo třeba chvíli počkat. Pokud to má velkou prioritu, tak si zbytečně přiděláváme práci u něčeho, co musí být hotové rychle. Pokud to může počkat, tak ať to sakra počká.

Zkuste se sami zamyslet, kdy jste naposled zaslechli něco takového: „Jasně, děláme X Ale když už jsme v tom, tak bychom mohli udělat i Y“. Podobným nápadům se snažte zabránit všemi dostupnými prostředky. Jak? Nejjednodušší metoda je to rozfázovat. Udělat nejdřív X a pak Y.

Lidé se zkrátka nedovedou soustředit na víc věcí najednou. Když se snažím dělat X i Y zároveň, tak hrozí že neudělám ani jedno. Navíc se ochuzuji o ten krasný pocit z odškrtnutí dalšího hotového úkolu. Zkrátka, když se snažím dělat moc věcí najednou, tak se to vleče, lidé jsou zmatení, žena s vámi nemluví a má to spoustu dalších negativních důsledků.

Zamysleme se ještě, jaká je vlastně motivace, pro to dělat víc věcí najednou? U mě je to obvykle takový ten pocit, že když už do toho vrtám, tak ať to stojí za to. Jako kdyby rozvrtání kódu byla nějaká výjimečná událost. Občas se také přistihnu při naivní myšlence, že když budu dělat několik věcí najednou, tak to bude rychlejší, než kdybych je dělal postupně. Přiznám se, že netuším, kde se ve mně takové blbosti berou. No a často je to asi také snaha propašovat do kódu to zatrolené Y, které se stále odkládá, protože má nízkou prioritu. Slyšel jsem i o firmách, které mají tak zbytnělé procesy, že je pro programátory lehčí udělat víc věcí najednou za jedno papírování. Ale to snad není váš případ.

Jsou i legitimní důvody. Třeba pokud máte nákladné testování. Pak se může vyplatit najednou testovat celou rozvrtanou oblast. Ale i to je diskutabilní. Testování jedné přímočaré opravy chyby je obvykle málo náročné. Takže ten refaktoring, který bychom k tomu chtěli přibalit, můžeme otestovat stejně dobře i zvlášť. Navíc se testeři nebudou divit, jak to že se opravou chyby rozbilo tolik věcí. Těžko se vysvětluje, že jsme tam přibalili refaktoring jako bonus. Z takového překvapení má radost málokdo.

Takže si opakujte po agilistech: „Rozsekejte si práci na co nejmenší ještě smysluplné celky a dělejte je postupně.“ Ohromně si tím ulehčíte život. No a já si jdu připravovat argumenty, jak Dagiho přesvědčím, že není dobrý nápad komponentizovat aplikaci a zároveň se učit nový programovací model. Oboje samozřejmě najednou. Však víte, když už do toho vrtáme…

Kurážné vedení projektů

Občas si pořídím knížku o řízení projektů, ale nedočtu ji, protože mě nebaví. Teď jsem narazil na výjimku – Scrappy Project Management od Kimberly Wiefling. Je to relativně krátké, čtivé a hlavně je vidět, že ví o čem mluví.

Samozřejmě, pokud nejste úplní nováčci, nedozvíte se tam nic převratného. Je to člověku připomene to co mu radí selský rozum, ale i přesto to nedělá.

Chtěl jsem tady ty rady zopakovat, ale bez kontextu vypadaly tak evidentně, až to bylo trapné. Takže tu jen ocituji věci, které jsem si u jednotlivých kapitol podtrhl a zbytek textu vám nechám za domácí úkol.

Zákazník? Jaký zákazník?

Každý člen týmu má v představu toho, jak vypadá zákazník. Většinou takovou, že se chová a vypadá jako on sám.

Většina týmů si najde čas na zákazníka, až když je pozdě.

Ptejte se: „Co se zdá být nemožné, ale kdyby to bylo možné, změnilo by to váš obchod k lepšímu?“

Pokud nevíte kam jdete, je jakákoliv cesta dobrá

Když většina týmů uslyší startovní výstřel, začne vymýšlet jak dosáhnout cíle. A to ještě předtím, než pochopí co ten cíl vlastně je.

Tím že jasně nadefinujete úspěch, zvyšuje pravděpodobnost jeho dosažení.

[na začátku projektu potřebujete]

  1. Úplný seznam kritérií úspěchu
  2. Jasný popis každého kritéria
  3. Konkrétní, měřitelný a proveditelný cíl pro každé kritérium
  4. Nejnižší přijatelnou úroveň u každého kritéria
  5. Priority alespoň u tří nejdůležitějších kriterií

Nedostatek cílů je jedna z příčin selhání, které můžeme úplně zabránit.

Komunikace? My musíme dělat opravdickou práci

Největší problém komunikace je iluze, že proběhla. G.B. Shaw

Špatná komunikace je další příčina selhání, které se dá zabránit.

Vedoucí projektu musí vést […] To se nedá dělat zpoza klávesnice.

Na co plánovat? Vrhněme se do toho.

Nedbale plánovaný projekt trvá třikrát tak dlouho, než se čekalo. Pečlivě plánovaný jenom dvakrát. Golubův zákon

Proč je tak těžké vytvořit většinu plánů? Protože má většina projektů zpoždění už na začátku.

  1. Zastav se!
  2. Zamysli se! (alespoň na nanosekundu)
  3. Teprv pak konej

Musíme se ujistit, že všichni sdílejí společnou halucinaci o tom, jak bude úspěch projektu vypadat, znít, chutnat, vonět a cítit.

Rizika? Co by se asi tak mohlo stát?

Největší chyba v řízení projektu je identifikovat rizika, ale nic kolem toho neudělat.

Kde je riziko, tam je možnost úspěchu.

Priority? Všechno je priorita číslo 1!

Prioritizace není něco co děláme, abychom vytvořili seznam věcí na které se vykašleme. Nutí nás zamyslet se, co je důležité a na co máme zaměřit naše omezené zdroje.

Změny? Co myslíte tím, že se věci změnily?

Jenom pitomec si může setrvávat v bludu, že projekt může být počat, nedefinován, naplánován a proveden beze změn.

Předpoklady jsou matkou katastrofy

Žádosti jsou obvykle zamítnuty pokud jsou podány poprvé. Na školení „Jsem vedoucí“ se lidé učí zamítnout jakoukoliv žádost o jakékoliv zdroje. … Vyhrajete, pokud zažádáte víckrát, než kolikrát oni zamítnou.

Cože to očekáváte?

Tajemství na spokojeného zákazníka je slíbit míň a dodat víc.

Pokud jde o zákazníka, neexistuje požadavek, specifikace nebo dohoda, u které nemůže dojít k nedorozumění.

Nepoučení pro příště

Učte se ze zkušeností. Pokaždé dělejte nové a víc vzrušující chyby.

Selhání kvůli neočekávaným překvapením zklame. Ale selhání kvůli předvídatelným, vyhnutelným a opakovaným chybám vážně podkopává morálku a produktivitu.

Zatrolený CAP

S tím jak se šíří cloudové šílenství, čím dál tím víc lidí naráží do CAP teorému. Mě i mé kolegy nevyjímaje. Tak jsem si řekl, že si to tu vyjasním.

CAP teorém zjednodušeně říká, že distribuovaný systém, nemůže splňovat všechny tři následující vlastnosti:

  1. Consistency – konzistence – všichni klienti vidí stejná data
  2. Availability – dostupnost – každý klient může vždy číst i zapisovat
  3. Partition tolerance – odolnost vůči rozdělení – systém funguje i když se rozpadne na víc nezávislých častí

Jak sami vidíte, není to zrovna moc exaktně definováno. Co to znamená, že systém funguje při rozpadu na víc částí? Čert ví. Často se také liší definice jednotlivých vlastností. Ale nevadí, že je to vágní. I tak je důležité je mít tu větu neustále na mysli, když se pokoušíte o distribuovaný systém.

Pro jednoduchost si představme, že máme dva databázové servery, kterým budeme říkat třeba Anička a Bohouš. Takže máme Aničku a Bohouše a samozřejmě chceme, aby klienti mohli zapisovat a číst přes oba dva. Taky chceme, aby Anička poznala, že se Bohouš rozbil, a vzala to na chvíli místo něj. No a pak jsou tu tak samozřejmé požadavky, že je snad ani nemusíme zmiňovat. Jako třeba, že se nám nesmí ztrácet data. Když něco zapíšeme, chceme, aby to tam zůstalo. A samozřejmě potřebujeme, aby to všechno jelo tak rychle, jak je jen možné. To se snad rozumí samo sebou.

Problém je, že to nejde.

V první řadě nedokážeme zajistit konzistenci, pokud se provádí zápis přes víc serverů. Nebo přesněji, nedokážeme to pokud chceme změny provádět rychle. Kvůli konzistenci musíme totiž zajistit, že nepřijmeme konfliktní zápisy. Jako třeba pokus o současné převedení peněz z jednoho účtu. Pokud to provede zároveň pro různé požadavky Anička i Pepík tak nakonec může účet skončit v mínusu, i když je to zakázané.

Tento problém se obvykle řeší tak, že všechny změny provádí jen jeden server. Ten už si dokáže ohlídat, jestli se někdo nesnaží dostat do mínusu. Nebo musíme dělat něco jako distribuované transakce, což je nejen pomalejší, ale stejně to zatíží všechny servery, takže se to ani nevyplatí.

Tím pádem můžeme zjednodušeně říci, že pokud vyžadujeme konzistenci, všechny zápisy musí jít přes jeden server. Třeba přes Aničku. Stačí to aby se zajistila konzistence? Přijde na to. Pokud klienti čtou z Bohouše, tak mohou vidět stará data. Pokud se jedná o milisekundy, tak se vždycky můžeme vymlouvat, že ten zápis proběhl až potom, co začali číst. Potíže nastanou, když je zpoždění větší nebo když něco zapíšu na jednom serveru a pak to na tom druhém ještě nevidím. Oboje jsou to řešitelné problémy. Třeba tak, že Bohouš pozná, že má stará data, a v takovém případě přepošle požadavky na Aničku.

Skvělé, takže jsem vyřešili konzistenci, co ostatní požadavky? Dostupnost? Brnkačka. Bohouš pozná, že Anička odpadla a vezme práci za ní. Tak to obvykle řeší klasické relační databáze. Tak v čem je problém?

Samozřejmě, že v té odolnosti vůči rozdělení. Když se nám rozpadne spojení mezi oběma servery, můžou si oba myslet, že je ten druhý spinká a začnou přijímat zápisy. Což nám rozbije konzistenci. Tento problém se před pár lety nemusel řešit. Oba servery obvykle byly spojeny superrychlým superspolehlivým spojením, takže byl rozpad clusteru nepravděpodobný. Dnes ale žijeme v době superlevného superšitoidního cloudu, takže se sít rozpadne několikrát za týden.

Co s tím? Třeba MongoDB to řeší tak, že nás nutí mít lichý počet serverů. Přijímat zápisy pak může jenom ten, co vidí většinu nodů v clusteru. Takže Anička s Bohoušem musí pozvat Cecilku a zapisovat bude jen ten, co vidí alespoň jednoho dalšího. Pokud se síť rozpadne, servery se rozhlédnou a pokud vidí alespoň jeden jiný server, tak se s ním dohodnou, kdo z nich bude zapisovat.

Skvělé, to vypadá, jako kdybychom měli splněné všechny tři podmínky. Ha, hloupá CAP věta vyvrácena. Nebo ne? Bohužel ne. Tím, že jsme si zajistili odolnost vůči rozpadnutí jsme se připravili o dostupnost. Pokud totiž žádný server nevidí většinu clusteru nebude zapisovat nikdo z nich. Sakra.

Pokud máme nespolehlivou síť, tak si prostě musíme vybrat mezi případnou nekonzistencí, která hrozí třeba u MySQL nebo nedostupností, která hrozí u MongoDB. Prostě a zkrátka, pokud se spolu servery nemůžou domluvit, tak jich buď může zapisovat víc nebo žádný.

Zajímavá varianta je, rovnou se vzdát konzistence. To dělá třeba CouchDB. Pokud dojde v konfliktu v datech, tak to jednoduše uloží jako různé verze jednoho dokumentu a řešení hodí na někoho jiného. Buď na aplikaci nebo rovnou na uživatele. Tím pádem nemají problém v tom zajistit dostupnost a odolnost vůči síťovým problémům. Takže třeba můžou mít offline kopii, která se po připojení do online režimu automaticky sesynchronizuje.

Mám dojem, že jsem vyčerpal nejen vás, ale i všechny možnosti. Nebo jsem na něco zapomněl? Nezmínil jsem sharding. Ale sharding nám v podstatě jenom zajistí rozpad jednoho distribuvaného systému na víc nezávislých. Tím si sice rozložíme zátěž, ale CAP teorém nám to neobejde. Na ten budeme nadále narážet v rámci jednotlivých shardů. Hmm, už mě nic nenapadá, tak vás jen poprosím. Nepokoušejte se psát systémy, které jsou konzistentní, stále dostupné a vydrží rozpad sítě. Opravdu to nejde.

Odkazy:

Jak si MongDB replica set volí mastera

Pěkné přirovnání na CAP teorém

Obrazový průvodce NoSQL systémy

Vyvrácení CAP teorému