Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Ahoj,
// omlouvám se za umístění do této kategorie, ale lepší mě nenapadla
mým dlouhodobým úkolem je usnadnění cca 5ti vývojářům práci na jednom webovém projektu.
Cíle jsou celkem jednoduché - zvýšit efektivitu práce, snížit chybovost a minimalizovat chyby způsobené přepisovaním souborů na ftp.
Nad servery máme plnou moc, čili je možné nasadit jakékoliv řešení.
Současná verze: používáme SVN, každý commit se projeví na webu -> velmi rychle rostou revize a případný návrat k určité revizi je komplikovaný.
Úkol: Začít používat SVNku tak, jak se má, čili 1 commit = balík změn.
Kluci teď k vývoji používají Windows + Eclipse a Zend Studio. Problém je, že se mi nepovedlo spárovat SVN projekt s remote Workspacem, čili jsem se vydal na cestu hledání synchonizace lokálního adresáře se serverem (popř. přimoutěnýho adresáře).
Nalezená řešení:
Putuji správnou cestou nebo jsem uplne mimo? Jak řešíte takovýto vývoj vy?
Díky
Jarda
12.2.2011 11:17
Saljack | skóre: 28
| blog: Saljack
| Praha
13.2.2011 13:42
Saljack | skóre: 28
| blog: Saljack
| Praha
To jsou kecy a garantuju ti, že po jednom dnu jsi git dobře používat neuměl. Pro lidi, kteří s žádným verzovacím systémem ještě nepřišli do styku, to nemusí být takový problém, ale pro lidi, kteří jsou zvyklí na SVN, je to docela slušný kulturní šok, tam se doba učení počítá nejmíň na týdny.Nesouhlasím, základní použití mi trvalo opravdu chvíli. Horší je, že pro lidi přecházející ze svn/cvs nejsou zvyklí používat větve. To je v podstatě to hlavní, co je třeba se naučit. Ditribuovanost samotná není problém. Tedy mrknout na Git - SVN Crash Course a prolétnout knihu "PRO GIT" od SCOTT CHACON (knihy.nic.cz/ je k dostání pdf zdarma.
16.2.2011 20:18
pavlix | skóre: 54
| blog: pavlix
K tomu se chceme dopracovat. Nicmene nekteri vyvojari maji problemy s chapanim, takze vysvetlit jim fungovani gitu je opravdu problem.Zase takový problém to není, Git pochopí i podprůměrný webový programátor.
On uz byl problem jim vysvetlit, ze vyvoj nebudou delat produkcni verzi, ale nekde stranou.Jo, jestli je to nějaký projekt, kde se programátorům dává 80-100 na hodinu, pak chápu, že je těžké je namotivovat ke správnému způsobu práce. Pokud ne, hledal bych chybu ve vedení projektu, někdo to vést musí, ne?
Predpokladam, ze vy mate vsichni lokalne nainstalovany webserver a vyvoj si delate lokalne?To je ideální způsob, ale technicky to lze i centralizovat. Ale je potřeba přestat projekt fušovat a začít ho vyvýjet. Pak postupovat podle reálných potřeb. Můžu nabídnout malou osobní konzultaci, pokud se dokážem sejít na jednom místě :). Kontakt v profilu.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
23.2.2011 11:26
svn diff, abych tam hned poznal, že je tam to co tam být má a že jsem omylem třeba někde něco nepřepsal. Pro oddělený vývoj nové funkcionality, který by vyžadoval více commitů a/nebo kód by byl mezitím byl ve stavu, kdy je lepší ho nenasazovat do produkce, slouží větve. SVN umí větve, umí je i mergovat (raději ale používejte nějakou novější verzi SVN klienta), případně se podívejte ještě na git, ten umí větve a hlavně mergování a další věci ještě lépe.
Pokud commit do SVN sám "proteče" až na produkční server, nebo pokud šéf chce, aby commit byl vypiplaný a obsahoval jednu celou ucelenou změnu, zbytečně to vývojáře stresuje. Commitování pak vyžaduje hodně pozornosti, soustředění, a tedy času. Normální je commitovat skoro každou chvíli, kdežto v téhle situaci bych se nedivil, kdyby se commitování stalo otravnou činností, ke které se někdo donutí tak jednou za týden, což je opravdu špatně. Commit není release (vydání nové verze). Na release jsou větve. (To, že si pletete commit a release, odvozuji i z "každý commit se projeví na webu".)
Teď k tomu zbytku - kdo není schopen intuitivně používat SVN (nebo jiný SCM), nemůže si říkat programátor/vývojář, je to jedna z úplně nejzákladnějších věcí. Obecně z vašeho příspěvku mám pocit, že "kluci" budou asi jen nějací brigádníci nebo klikači tak něco. Od vývojáře očekávám, že svůj operační systém, editor, IDE a ostatní nástroje dokáže ovládat natolik, že mu v ničem nebudou překážet. A vůbec, jste na abclinuxu.cz, takže rada je jasná - zahoďte ty vidle a nainstalujte Linux, spousta problémů se vyřeší sama :) Pak si webovku můžou vyvíjet u sebe a nemusí se šaškovat se serverem, nebo aspoň jak už jednou budete na Linuxu, máte mnohem více možností vytvořit/upravit/naskriptovat si vhodné nástroje. Už jenom třeba rsync by vám mohl pomoci, nebo sshfs. Já sshfs používám přesně k tomuhle - k vývoji na serveru z notebooku. Vlastně to ani nemusí být Linux, OS X je poslední dobou u webařů celkem v oblibě a je to také UNIX. A pokud opravdu chcete zůstat na Windows, nabízí se ještě cygwin.
V příspěvku výše někdo zmínil testování a CI - to je dobré, ale začít bude lepší od začátku :)
git log, git diff, git blame, git bisect... je pak tisícrát rychlejší než v SVN. Případně prosím upřesněte vaše problémy s SVN, mohly by být zajímavé.
Osobně bych se podíval po možnosti, zda by vámi používaný editor/IDE nemohl pracovat vzdáleně na serveru, místo toho, aby editované soubory musely být umístěny přímo na počítači, kde je editor spuštěn. Píšete, že se vám "nepovedlo spárovat SVN projekt s remote Workspacem" - remote workspace zní podezřele, takže jste to asi už zkoušel :) Jako další bych zkusil Sambu.
Putuji správnou cestou nebo jsem uplne mimo? Jak řešíte takovýto vývoj vy?IMHO mimo. Mám dojem že váš problém není technický ale procesní. Řešit to nějakým samba-ssh hackem možná zalepí nějaké symptomy, ale ne příčiny. Nedovedu si představit jak je možné, že máte 300k commitů v produkčním SVN. Kdybych commitoval každou půl hodinu tak to vychází na cca 3000 commitů na vývojáře a rok. Tipl bych si, že máte tyhle neduhy: 1) vývojáři dělají svoji práci tak, že commitnou jeden znak, nechají to probublat na ostrej (nebo integrační) server, pak se tam podívají, a tohle opakují dokud nejsou spokojeni - to by vysvětlovalo těch 300k ... 2) vývojáři často odevzdávají práci nedodělanou a/nebo jejich změny pokazí již existující funkcionalitu - proto máte velkou potřebu něco "dohledávat v historii" ... 3) nevím co má znamenat "minimalizovat chyby způsobené přepisovaním souborů na ftp" ale chápu to tak že krom SVN se ještě část projektu publikuje přes FTP Doporučil bych 1) aby každý vývojář měl na svém PC celé prostředí (web server, databázi s nějakými daty, ...) aby mohl udělat celý svůj úkol lokálně, a commit udělal až když má hotovo 2) strukturovat práci tak aby "hotovo" bylo 1-2x denně, tj. aby každej provedl jeden/dva commity a update za den 3) pracovat s testy - od zadavatele k vývojáři, aby odevzdaná práce byla jasně ověřitelná a unit testy aby se omezil počet chyb a regresí 4) rozchodit funkční IDE s připojením na SCM u každého bez dalších hacků - to je základ, není na tom co vymýšlet 5) pokud existuje něco jako FTP kam se ještě něco musí donahrávat tak to zrušit a držet vše jen v SCM ... samozřejmě co se týče nástrojů tak git je daleko výkonnější než svn, ale pokud budete dodržovat pravidlo 2, tak na meze svn hned tak nenarazíte (případně lze použít git-svn) ... redmine je sice populární, ale systém tužka+papír vám pomůže vypilovat ten proces, pak ho můžete upgradovat technicky.
Jenom si myslím, že v 5+ lidech se už bez větví těžko funguje.Častý neduh týmů je že neumí udržovat jeden společný trunk a přispívat do něj pravidelně malými funkčními přírůstky. Franta už měsíc dělá na svém písečku feature A, Pepa dělá už dva měsíce B. Instinktivní řešení je zavést větve, ale tím jen přilejete olej do ohně, protože zjednodušíte divergenci kódu. Pokud naopak budete práci plánovat tak, že každej provede dvakrát denně update s trunkem a commit funkčního příspěvku do trunku, tak tyhle (a další) problémy rázem odpadnou. Větve jsou dobré na spoustu věcí, ale ne na to aby lidi spolupracovali.
Proč divergence?Divergence proto, že mergujete master do větve, ale ne naopak. Kód proudí jen jedním směrem a tvoří divergující větve.
Některé větve pro složitější věci žijou u několik měsíců a opravdu nelze jejich kód od začátku pouštět do trunku, ze kterého se po testování odvíjí stable větev pro produkční nasazení.Většinou to jde, pokud se to dobře naplánuje, ale to by chtělo vidět konkrétní příklad. Pokud se vydáte cestou oddělení větve na několik měsíců, tak budete zbytečně řešit extra noční build té větve a po těch několika měsících budete integrovat až se z vás bude kouřit.
Jenže ta větev se od masteru liší jen svými změnami, ne změnami, které se průběžně dostávají do masteru. A to je přesně cílem. Stále staví na AKTUÁLNÍM masteru. Případné konflikty s masterem se řeší průběžně, každých pár dnů, jak je potřeba, ne až megakonflikt na konci. To je zásadní rozdíl.Jenže tím řešíte konflikty s masterem, kterej se téměř nehýbe, protože větší změny probíhají ve větvích. Lepší je pravidelně řešit konflikty mezi těmi větvemi napříč, a to tak, že změny z větve putují pravidelně do masteru. Jinak se může stát, že Franta změní funkci X nějak, Pepa nějak jinak, a přijdete na to až za ten měsíc.
Ale všechny se ve finále v pohodě mergnuly do masteru, bez toho, aby se z nás kouřilo :)Pokud nemergujete změny do masteru, tak je to možné jen tak, že během vývoje ve větvi berete kód z masteru jako něco neměnného a přibalujete jen věci navíc. Pokud zjistíte, že kvůli feature Y byste potřebovali změnit architekturu kódu X, kterej je převzatej z masteru, tak to řešíte jak? Hádám, že velmi opatrně, s rozvahou, a pokud možno vůbec. Jinak se totiž vystavujete tomu megakonfliktu za ten měsíc.
Změny z větve do masteru také někdy putují, právě proto, aby se ostatní v masteru i v jiných větvích dostali k nějakým klíčovým změnám. A původní větev žije dál, když to není dodělané. Prostě jak je potřeba.IMHO když tenhle způsob dotáhnete ještě o kousíček dál, tak zjistíte, že v té větvi není moc co hromadit.
Proto jsem psal, že SVN pro více lidí díky absenci pořádné podpory větví moc nestačí.SVN hlavně neumí pořádně mergovat, což by měl bejt primární důvod k opuštění SVN. Merge je totiž potřeba i při update, i když žádné větve nemám.
Když každej provede dvakrát denně update s trunkem a commit, docílíte akorát toho, že se nefunkční kód úspěšně šíří ke všem, takže místo jednoho vývojáře, který na něm dělá a snaží se ho opravit, komplikuje práci (nebo ji rovnou zastaví) i všem ostatním.Zkuste se na to dívat jinak. Když dneska commitnu nefunkční kód, tak nejpozději zítra se zjistí, že je nefunkční. Když se navíc ten kód budou snažit použít všichni, tak se případná chyba odhalí s podstatně větší pravděpodobností. Jelikož ten commit obsahuje práci za půlden, je dost jednoduché ho buď opravit, nebo revertnout a jede se dál. Čím kratší je doba na zjištění problému a čím menší je commit kterej ho mohl způsobit, tím jednodušší je jeho odstranění. Ve finále je to tak, že ty commity většinou fungují, protože těsně před commitem uděláte update a skontrolujete že vše funguje; tj. váš kód je funkční nad posledním stavem trunku. Když si naopak něco budu šulit měsíc u sebe a všichni ostatní taky, tak pak při společné integraci z toho bude jeden velký třesk.
Když dneska commitnu nefunkční kód, často vím, že je nefunkční. A nebo to přinejhorším zjistím zítra sám – není potřeba, aby to zjistili všichni, všichni to řešili nebo všichni čekali na opravu. Pokud musím commitovat jen ucelené funkční změny, vede to k tomu, že si u sebe na disku syslím rozpracovaný necommitovaný kód. Z hlediska mergování na konci je to tedy stejné, ale ztrácím možnost průběžných commitů po jednotlivých částech, ztrácím možnost spolupráce s ostatními.Tohle nějak nechápu - commitovat nefunkční kód je samozřejmě blbost. Idea je taková že se commituje funkční kód. A moje práce je směřována k tomu, abych za ten půl až den ten funkční kód měl. Ten čas na to stačí. Pokud budu mít rozpracovanou práci déle, vystavuju se výše popsaným problémům. Ta spolupráce je právě o tom, že se commituje. Syslení není spolupráce.
Za prvé by se nemělo běžně stávat, že si budou vývojáři navzájem přepisovat nějaké společné funkce. To by měla řešit modularita a zodpovědnost za jednotlivé moduly. Ty konfliktní změny si pak každý vyřeší sám, kdy mu to nejlépe vyhovuje.Rozdělení zodpovědnosti za části kódu vede obecně k malé pružnosti kódu. Je lepší to mít tak, že pokud nějakej kus kódu nevyhovuje mým požadavkům tak si to tam prostě dopíšu. Když někde vidím chybu, tak ji prostě opravím. Když se mi to někde zdá nečitelné, tak refactoruju. Takovouhle změnu je pak samozřejmě potřeba co nejdříve vypropagovat směrem k ostatním. Výhoda je, že pak všichni pracují stálým tempem, místo stylu "čekám na frantu, až do svého kódu napíše X, zatím to musím obejít a stojí mě to 5x víc času než kdybych to tam dopsal sám".
Takže např. dodělám práci, a teprve pak řeším případné konflikty. Varianta, kdy mám rozpracovanou svoji práci a do toho musím ještě řešit konflikty (a pak mám jeden commit, který řeší oboje), není dobrá. Navíc se ten případný konflikt řeší jednou při změně funkcionality – nemusí se řešit za ten měsíc třeba čtyřikrát podle toho, jak se ta změna postupně vyvíjí.Podle mě je lepší, když do svého půldenního snažení zakomponuju kompatibilitu s půldenním snažením ostatních, místo toho, abych pracoval s měsíc starou verzí trunku a pak nezbylo než svoji mesíční práci přepsat, protože merge už nikdo nedá. (To je extrém, ale za prvé jsem to už několikrát zažil a za druhé to dobře ilustruje ten rozdíl ve stylu práce.) Pokud někdo za 2 dny čtyřikrát něco kompletně překope a commitne, tak to asi taky nemá v hlavě úplně dobře.
A moje práce je směřována k tomu, abych za ten půl až den ten funkční kód měl. Ten čas na to stačí.My tady ale píšeme obecně i o větších projektech, kde vám rozhodně půl den nestačí na napsání, odladění a otestování nějaké nové funkce.
Ta spolupráce je právě o tom, že se commituje.Ano. Jenže spolupráce je také to, že nerozbíjím program ostatním pod rukama. Takže commituju pravidelně, ale do společné repository dám až funkční výsledek.
Rozdělení zodpovědnosti za části kódu vede obecně k malé pružnosti kódu. Je lepší to mít tak, že pokud nějakej kus kódu nevyhovuje mým požadavkům tak si to tam prostě dopíšu. Když někde vidím chybu, tak ji prostě opravím. Když se mi to někde zdá nečitelné, tak refactoruju.To může fungovat tak ve skupině do 5 vývojářů. Větší projekt už je potřeba modularizovat a není možné, aby si každý měnil rozhraní, jak se mu zachce.
Takovouhle změnu je pak samozřejmě potřeba co nejdříve vypropagovat směrem k ostatním.Není. Změnu je potřeba dostat k těm, kteří na ní závisejí. Ostatní naopak zdržuje uprostřed vývojového cyklu a do kódu, který mají sami rozvrtaný, integrovat ještě nějaké cizí změny.
Podle mě je lepší, když do svého půldenního snažení zakomponuju kompatibilitu s půldenním snažením ostatních, místo toho, abych pracoval s měsíc starou verzí trunku a pak nezbylo než svoji mesíční práci přepsat, protože merge už nikdo nedá.To máte nějaký divný postup práce, kdy se vám pořád mění většina kódu. Podle mne je normální, že se změny v rozhraních mezi moduly dělají nárazově a po dohodě autora i uživatele rozhraní. Takže se nemůže stát, že bych něco musel složitě a zdlouhavě přepisovat. Nevím, proč bych si měl průběžně integrovat všechny postupné změny – než refaktorovat nějaký kód čtyřikrát podle toho, jak se mění rozhraní nějaké funkce, raději ho zrefaktoruji jen jednou, až je to rozhraní hotové. Navíc ten váš postup míchá do jednoho commitu nesouvisející změny. Když se pak ukáže, že moje úprava byla špatně a musím ji vrátit, vrátím i změny vyvolané mergem s jinou větví. Takže ty změny musím provést znova.
Pokud někdo za 2 dny čtyřikrát něco kompletně překope a commitne, tak to asi taky nemá v hlavě úplně dobře.Podívejte se na vývoj linuxového jádra. Kolikrát se tam mění kód, který znamená jednu novou funkcionalitu. A vy byste po vývojářích chtěl, aby to, co se tam probírá několik dní nebo i týdnů či měsíců, napsali rovnou na čisto za půl dne.
My tady ale píšeme obecně i o větších projektech, kde vám rozhodně půl den nestačí na napsání, odladění a otestování nějaké nové funkce.Asi jsem se nevyjádřil přesně. Vývoj funkce může trvat déle, ale doba, po kterou je kód technicky nefunkční (nejde přeložit, nefungují testy), může být podstatně kratší. Další věc je, že práci lze řídit ne přes feature ale přes čas. Místo "až to bude hotový tak to commitnu" můžu jet stylem "commitnu to, co budu mít za den práce" - samozřejmě s tím, že to je technicky v pořádku.
Ano. Jenže spolupráce je také to, že nerozbíjím program ostatním pod rukama. Takže commituju pravidelně, ale do společné repository dám až funkční výsledek.Přesně tak, a tenhle cyklus netrvá déle než jeden den. To je taková empiricky stanovená doba, za kterou se dá udělat kus práce, který má aspoň nějaký význam. Pro ilustraci například když mám udělat GUI kde bude "Save" a "Save As", tak můžu za jeden den stihnout udělat to "Save" a commitnout, druhý den udělat "Save As" a commitnout. Třetí den můžu do obou dialogů dodělat tlačítko "Make new directory" atd. Nemusím dělat 3 dny v koutě a pak najednou commitnout všechny 3 změny. Takhle se to dá naplánovat vždycky.
To může fungovat tak ve skupině do 5 vývojářů. Větší projekt už je potřeba modularizovat a není možné, aby si každý měnil rozhraní, jak se mu zachce.No, běžně a bezproblémově to lze natáhnout na 10-15 lidí. Což pokrývá spoustu týmů. Pokud uděláte tu "modularizaci", tak efektivně dělíte projekt na víc podprojektů se vším co k tomu patří.
To máte nějaký divný postup práce, kdy se vám pořád mění většina kódu. Podle mne je normální, že se změny v rozhraních mezi moduly dělají nárazově a po dohodě autora i uživatele rozhraní. Takže se nemůže stát, že bych něco musel složitě a zdlouhavě přepisovat.V praxi to není většina kódu a zdlouhavé přepisování. Počet konfliktů není velký, právě protože ten půlden. Pojem "autor kódu" je dost přeceňovaný. Pokud potřebuju autora kódu, tak buď to znamená, že kódu nerozumím, tudíž to autor v první řadě neudělal dost čitelně, nebo to znamená, že se bojím do toho hrabat, tudíž tam autor kódu neudělal dost testů. Komunikaci od autora k uživatelům je nejlépe dělat přes ten kód, tak, aby každý kdo k tomu přijde, už pak autora nepotřeboval.
Nevím, proč bych si měl průběžně integrovat všechny postupné změny – než refaktorovat nějaký kód čtyřikrát podle toho, jak se mění rozhraní nějaké funkce, raději ho zrefaktoruji jen jednou, až je to rozhraní hotové.Ten čtyřnásobný příklad mi nějak nesedí. Dejme tomu, že v 8:00 ráno je rozhraní ve stavu A, franta si ho stáhne, a převede ho do stavu B a ve 12:00 pushne. Mezitím v 9:00 přijde pepa, stáhne si verzi s rozhraním A, udělá nad ním funkcionalitu X, a ve 13:00 bude chtít pushovat. Nejprv udělá pull, kterej mu vytvoří lokální konflikt, kterej vyřeší a ve 13:30 pushne. Mezitím franta převede rozhraní do stavu C a v 15:00 bude chtít pushnout, takže udělá pull, zjistí že přibyl jeden uživatel rozhraní B (pepa), kterého převede na rozhraní C, ale to už pepu nezajímá. Franta si pak může klidně dělat verze D, E, F, ... a akorát pokaždé změní všechny uživatele vč. pepy. Když k tomu druhej den pepa přijde, udělá si pull, tak zjistí, že jeho kód používá rozhraní F, a svůj další den začne prostě s tímhle stavem.
Navíc ten váš postup míchá do jednoho commitu nesouvisející změny. Když se pak ukáže, že moje úprava byla špatně a musím ji vrátit, vrátím i změny vyvolané mergem s jinou větví. Takže ty změny musím provést znova.Tak na to jsou ty DVCS, že si můžu oddělit commity svojí práce s commitem integračním (a nebo dělat rebase, jako kdyby ty změny z upstreamu tam už byly když jsem k tomu přišel).
Podívejte se na vývoj linuxového jádra. Kolikrát se tam mění kód, který znamená jednu novou funkcionalitu. A vy byste po vývojářích chtěl, aby to, co se tam probírá několik dní nebo i týdnů či měsíců, napsali rovnou na čisto za půl dne.Kernel je trochu jiná dimenze, ale i tam lze nalézt analogie. Mají jasně stanovený časový plán, kterým se vývoj řídí (merge window, atd.), mají integrační větev next, mají systém "první příspěvek projde bez konfliktů a ostatní mergujou", atd. Na druhou stranu taky mají milion regresí (i bezpečnostních), protože testy žádné a kontrola očima nestačí.
Když potřebuješ něco zásadnějšího, tak to za den ani náhodou nedostaneš do funkčního stavu, abys mohl komitovat do masteru.Ne, ne, ne a ne. Je to jen o pořadí činností, navrhnout to tak, aby v každém kroku projekt stál oběma nohama na zemi. Vidět znamená věřit, takže příklad. Zásadní změna - přechod na jinou db. Dělali jsme to měsíc (výzkum) a dva týdny (realizace). Ani jeden den nebyl na konci dne kód ve stavu, kdy by technicky nefungoval. Dělali jsme to v branchi, to přiznávám, ale ne proto, že by to byť jeden den nefungovalo. Požadavek vznikl jako reakce na problém kde jsme optimalizovali rychlost dotazů. To byl ten měsíc. Měli jsme kopii db, udělali jsme si nový DAO objekt a nový modul který jen pustil tu query a vypsal čas dotazu na sysout. Žádná změna, kvůli které by master nefungoval (DAO objekt šel vždy aspoň přeložit). Měsíc jsme jen laborovali s tou query. Na konci snažení jsme to DAO vyčistili a ze sysout programu udělali normální test s assertama. Ani jedno z toho neovlivnilo funkci ostatního kódu v master branch. Když už jsme měli tu query vypiplanou, tak jsme museli přejít na jinou db. Nejprv jsem v build skriptech udělal to, aby se nová db do instalačního procesu balila současně se starou. Žádná regrese. Pak jsem nechal novou db spouštět se starou. Žádná regrese. Pak jsem kód částečně nasměroval na nové DAO a ve starém jsem změnil adresu databáze. Žádná regrese. Pak jsem napsal dokument a pár malých skriptů pro migraci dat. (Automatická migrace nebyla v plánu, ale dala by se udělat stejným způsobem.) Žádná regrese. Pak jsem odstranil z build skriptů starou db. Konec. V každém kroku byl systém funkční, byť třeba neoptimálně (např. že v systému byly spuštěny najednou dvě db). Ale nemyslete, ještě před rokem bych tuhle změnu dělal stylem: den 1, nevratná výměna staré db za novou. Další dva týdny - rozcházení nefunkčního kódu proti nové db. To by samozřejmě potřebovalo branch, a navíc bych byl pod tlakem udělat to co nejdříve, protože na tu změnu by jistě čekalo spousta jiných změn.
Navíc jak řešíš situace, kdy máš něco většího rozdělaného a přijde požadavek na urychlené vyřešení něčeho jiného, třeba do hodiny. To bez větví vůbec nejde.Obvykle to nehoří natolik aby se to nedalo naplánovat až na zítra, kde začíná nové kolečko - ostatní tasky se tím odsunou, ale žádný nezůstane nedodělaný. Pokud je to fakt potřeba udělat teď hned tak holt nezbejvá než činnost přerušit - lokálně si změny schovat do stashe, resetnout se na poslední bod v upstreamu a začít pracovat na té opravě. Druhý den se k tomu stashi vrátit. Může se dokonce i stát, že pak už nezbyde čas dodělat tu původní věc, pak je nejlepší ten stash vyhodit, protože s přibývajícím časem přestane být aktuální.
Zda vidí či nevidí změny, na tom nezáleží.Já mám za to, že když řeknu, že je něco základní podmínka, tak na tom záleží.
Nemusím s commitem čekat půl dne, ale můžu commitovat třeba každou půlhodinu.Však já taky na commit nečekám. Normálně commituju třeba každých 5 minut, jakmile mám zelenou na rychlých testech. To, co se dělá jednou za pár hodin je push, a to proto, že se pak čeká, až se to přebuilduje načisto na integračním serveru. Zatím se jde na záchod a na kafe.
Pro mne ale takový „čas na odevzdání“ nastává někdy taky až za několik dní.To je na Vás jak si to řídíte. Vy jste pánem svého času a můžete si strukturovat práci po dnech nebo po týdnech. Ale pro mě "několik dní" právě není dostatečně rychlá zpětná vazba. Respektive je na hranici únosnosti, a "několik týdnů" už je za hranicí. Někdy to ale zkuste s těmi půldny, když to nebude vyhovovat tak se můžete vrátit do starých kolejí.
Vývoj funkce může trvat déle, ale doba, po kterou je kód technicky nefunkční (nejde přeložit, nefungují testy), může být podstatně kratší.Může být kratší, ale také nemusí, někdy může oprava trvat opravdu několik dní. Ale nejde jen o technickou nefunkčnost. Představte si třeba e-shop – někdo upraví funkcionalitu přidávání do košíku. Kód jde přeložit a nepadají testy, ale nejde věci přidávat do košíku (protože se celá funkcionalita mění a znamená to několik dní či týdnů práce). Ostatní členové týmu, kteří dělají na zobrazení obsahu košíku, sestavení objednávky, fakturaci, expedici apod. mohou během té doby sice psát kód a testy, kompilovat s zkoušet testy, ale nemohou si to naživo vyzkoušet, protože s prázdným košíkem nemohou pokračovat – neuvidí, jak se s tím asi bude pracovat uživateli, jestli se to dobře ovládá, jestli se to chová logicky, jestli uživatel nemůže zadat nějaký neočekávaný vstup. S tím vším musí čekat, až tým, který mění košík, dodělá svou práci. Ale proč, je ty změny vůbec nezajímají.
Takhle se to dá naplánovat vždycky.Je vidět, že jste nikdy nepracoval na větším projektu.
Počet konfliktů není velký, právě protože ten půlden.Jeden konflikt za půlden mi dává 40 konfliktů za měsíc. Jeden konflikt za čtrnáct dní mi dává 2 konflikty za měsíc. Co je míň?
Ten čtyřnásobný příklad mi nějak nesedí.Co vám na něm nesedí? Mám nějaké rozhraní, třeba metodu. Vyvíjím novou funkci, předpokládám, že tam budu potřebovat dva další parametry navíc. Přidám je do rozhraní, všichni refaktorují. Za pár dní zjistím, že se jeden parametr vůbec nepoužívá, tak ho vyhodím. Všichni refaktorují. Po nějaké době zjistím, že mi nestačí předat id objektu (ten nový parametr), ale že je kvůli optimalizaci lepší předávat celý objekt. Opět všichni refaktorují. Pak zjistím, že se ta funkce většinou volá s nulovým novým parametrem, takže do rozhraní přidám zpátky i tu původní funkci, která bude volat interně tu novou. Všichni se vrací zpátky ke kódu, který měli na začátku. Kdybych je průběžným tlačením nehotového kódu do společné repository nenutil reagovat na každou moji změnu, nemuseli dělat vůbec nic (nebo jeden refaktoring, pokud bych neudělal poslední krok). Místo toho jsem je nutil k průběžným úpravám, které je odvádějí od jejich práce. Navíc je mi k ničemu historie práce v VCS, protože jsou tam zmatlané dohromady změny funkcionalit a merge.
Kernel je trochu jiná dimenze, ale i tam lze nalézt analogie. Mají jasně stanovený časový plán, kterým se vývoj řídí (merge window, atd.), mají integrační větev next, mají systém "první příspěvek projde bez konfliktů a ostatní mergujou", atd. Na druhou stranu taky mají milion regresí (i bezpečnostních), protože testy žádné a kontrola očima nestačí.Ale ten časový plán nepočítá s tím, že se ucelené změny v kódu zvládnou během půl dne. Naopak, vývoj jádra je postaven na tom, že se pracuje paralelně ve spoustě větví, a do master větve se kód dává až po funkčních celcích. A že by Linus musel neustále řešit nějaké hrozné konflikty při mergování, to se mi nezdá.
Kód jde přeložit a nepadají testy, ale nejde věci přidávat do košíku (protože se celá funkcionalita mění a znamená to několik dní či týdnů práce).To je špatně. Pokud šlo do košíku přidávat před tím, musí tam jít přidávat i po tom, jinak nebudou fungovat testy na přidávání do košíku. Zkuste ten příklad naformulovat jinak, takhle se totiž vracíme k systému práce franta si 2 týdny pižlá košík nemluvte na něj.
Je vidět, že jste nikdy nepracoval na větším projektu.Co je to podle vás větší projekt? Uveďte konkrétní příklad a zkušenosti...
Jeden konflikt za půlden mi dává 40 konfliktů za měsíc. Jeden konflikt za čtrnáct dní mi dává 2 konflikty za měsíc. Co je míň?Jeden konflikt za půlden, kterej řeším 5 minut, mi dá 40*5 minut (=asi 3,5 hod) měsíčně. Pokud nechám těch 28 konfliktních změn za 14 dnů řešit jen jednou za 14 dnů, tak to budu řešit minimálně den, takže celkem 2 dny měsíčně. Je to proto, že velikost změny + stáří změny a čas strávený její diagnózou nejsou v přímé úměře. Příkladně, když vím že před 5 minutama všechny testy chodily, a teď nechodí, tak stačí, když budu řešit posledních 5 minut změn, což mám ještě v hlavě a bude mi leckdy stačit se podívat na chybovou hlášku. Pokud budu pracovat celý den a na konci dne mi něco nepůjde, tak budu debugovat a hledat a strávím tím spoustu času navíc. Myslím že každý z nás už tuhle zkušenost prodělal.
Vyvíjím novou funkci, předpokládám, že tam budu potřebovat dva další parametry navíc. Přidám je do rozhraní, všichni refaktorují. Za pár dní zjistím, že se jeden parametr vůbec nepoužívá, tak ho vyhodím. Všichni refaktorují...Ten příklad jak jsem ho popsal já se ale liší v podstatné věci. Než vyhodím parametr, tak už budu mít k dispozici kód od "všichni", a refaktoruju ho já. "Všichni" se tím nemusí vůbec zabývat. A to je důležité. A je to možné jen tehdy, když "všichni" publikují svůj kód pravidelně a často.
Ale ten časový plán nepočítá s tím, že se ucelené změny v kódu zvládnou během půl dne. Naopak, vývoj jádra je postaven na tom, že se pracuje paralelně ve spoustě větví, a do master větve se kód dává až po funkčních celcích.Pokud vím, tak linux-next se merguje z branchí vývojářů podsystémů každej den. Jak často tam oni publikují, to je jejich věc. Každopádně pochopte, že i když kernel má třeba release cyklus jednou za 3 měsíce, tak prostě přes to vlak nejede, a co se za 3 měsíce nestihne, tak musí až do další verze. Takže to není tak, že kernel čeká až bude hotové cosi velkého, ale naopak že přispěvatelé si kouskují práci tak, aby do každého okna něco přicmrndli. Tenhle princip lze aplikovat na libovolný časový úsek.
A že by Linus musel neustále řešit nějaké hrozné konflikty při mergování, to se mi nezdá.Ne, to samozřejmě neřeší, řeší to ti přispěvatelé. Proto pravidlo, první patch se aplikuje čistě a ostatní mergují proti tomu. Opět lze praktikovat v libovolné frekvenci.
To je špatně. Pokud šlo do košíku přidávat před tím, musí tam jít přidávat i po tom, jinak nebudou fungovat testy na přidávání do košíku.Testy fungují, jsou upravené pro nový kód. Jenom na ten nový kód není napojeno GUI. Například.
Zkuste ten příklad naformulovat jinak, takhle se totiž vracíme k systému práce franta si 2 týdny pižlá košík nemluvte na něj.Já na tom systému práce nevidím nic špatného. Dělám svoji část, a nechci, aby mne rušily změny v jiných částech. Představte si to na externí knihovně. Synchronizujete si zdrojáky externí knihovny každý půl den a zapracováváte všechny změny, nebo si prostě počkáte na release té knihovny? Já to řeším druhým způsobem a snažím se o to, abych stejně mohl řešit maximům závislostí, tedy i ostatní součásti mého projektu.
Je to proto, že velikost změny + stáří změny a čas strávený její diagnózou nejsou v přímé úměře.Nejsou. Konflikt řešený každý půl den budete řešit pět minut, a konflikt řešený jednou za měsíc také pět minut.
Příkladně, když vím že před 5 minutama všechny testy chodily, a teď nechodí, tak stačí, když budu řešit posledních 5 minut změn, což mám ještě v hlavě a bude mi leckdy stačit se podívat na chybovou hlášku. Pokud budu pracovat celý den a na konci dne mi něco nepůjde, tak budu debugovat a hledat a strávím tím spoustu času navíc. Myslím že každý z nás už tuhle zkušenost prodělal.Pokud vám někdo jiný rozbil vaše testy, máte divně organizovanou práci. Pokud jste si je rozbil sám, poznáte to hned, ne až po té, co dáte kód do VCS.
Ten příklad jak jsem ho popsal já se ale liší v podstatné věci. Než vyhodím parametr, tak už budu mít k dispozici kód od "všichni", a refaktoruju ho já. "Všichni" se tím nemusí vůbec zabývat. A to je důležité. A je to možné jen tehdy, když "všichni" publikují svůj kód pravidelně a často.Všichni se tím musí zabývat. Musí vám dát kód, který je hotový a funkční. Takže když vy jim oznámíte, že budete něco refaktorovat, musí honem nějak vyřešit to, co mají rozdělané, dostat do repository kód, který se týká refaktoringu – a pak čekat, až vy refaktoring provedete.
Pokud vím, tak linux-next se merguje z branchí vývojářů podsystémů každej den. Jak často tam oni publikují, to je jejich věc. Každopádně pochopte, že i když kernel má třeba release cyklus jednou za 3 měsíce, tak prostě přes to vlak nejede, a co se za 3 měsíce nestihne, tak musí až do další verze. Takže to není tak, že kernel čeká až bude hotové cosi velkého, ale naopak že přispěvatelé si kouskují práci tak, aby do každého okna něco přicmrndli. Tenhle princip lze aplikovat na libovolný časový úsek.Nikoli. Přispěvatelé dělají na svém kódu nezávisle na ostatních větvích, a když mají svou funkcionalitu hotovou, dají ji do společného stromu.
Testy fungují, jsou upravené pro nový kód. Jenom na ten nový kód není napojeno GUI. Například.No, a ten problém nastává kde?
Představte si to na externí knihovně.Spolupráce mezi projektovými týmy a uvnitř týmu je něco jiného. Není důvod, aby když franta udělá dialog Save, aby ho ostatní vnímali jako dodavatele externí knihovny...
Synchronizujete si zdrojáky externí knihovny každý půl den a zapracováváte všechny změny, nebo si prostě počkáte na release té knihovny?Dost záleží na disciplíně toho druhého týmu, ale jsou projekty kde není problém odebírat trunk a updatovat každý den. Pokud se něco podělá, můžete jim okamžitě dát vědět. A zase: změna bude pravděpodobně v kódu který ze změnil za jeden den, takže oprava nebude stát miliony.
Konflikt řešený každý půl den budete řešit pět minut, a konflikt řešený jednou za měsíc také pět minut.Samozřejmě to můžete dělat tak, že za měsíc uděláte minimum změn, takže konflikty nevzniknou. Tím ale zamrazíte vývoj a záskáte nepružný kus softwaru, kde půlka věcí "nejde" a musí se to obcházet. Já mluvím o případu, kdy se celý software pružně předělává tak aby poskytoval ideální (nebo téměř) architekturu pro neustále nové požadavky. V tomhle režimu si nemůžete dovolit měsíc něco někde mít bokem, protože měsíc změn v architektuře budete integrovat další týden, jestli vůbec. Historky lidí i moje osobní zkušenosti v tomhle hovoří jasně. Buď má software denní integraci a nebo hnije.
Takže když vy jim oznámíte, že budete něco refaktorovat, musí honem nějak vyřešit to, co mají rozdělané, dostat do repository kód, který se týká refaktoringu – a pak čekat, až vy refaktoring provedete.Já nevím, ale už to píšu potřetí - když udělám refactoring, tak automaticky refactoruju i všechno kolem, aby to pak fungovalo. Nikdo na nikoho nečeká.
Přispěvatelé dělají na svém kódu nezávisle na ostatních větvích, a když mají svou funkcionalitu hotovou, dají ji do společného stromu.A to se bije s tím co říkám jak?
No, a ten problém nastává kde?V tom, že se nedá testovat velká část funkcionality aplikace.
Spolupráce mezi projektovými týmy a uvnitř týmu je něco jiného.Proto je dobré, když každý tým může mít svou větev kódu a není ovlivňován ostatními týmy.
Dost záleží na disciplíně toho druhého týmu, ale jsou projekty kde není problém odebírat trunk a updatovat každý den.Ale proč se mají vývojáři omezovat, když to není nutné?
Pokud se něco podělá, můžete jim okamžitě dát vědět.Já jsem radši, když se taková věc ke mně vůbec nedostane. A když už ta chyba probublá až ke mně, nechci kvůli ní zastavit práci a čekat, až ji opraví. Chci zatím pracovat na něčem jiném.
Samozřejmě to můžete dělat tak, že za měsíc uděláte minimum změn, takže konflikty nevzniknou. Tím ale zamrazíte vývoj a záskáte nepružný kus softwaru, kde půlka věcí "nejde" a musí se to obcházet. Já mluvím o případu, kdy se celý software pružně předělává tak aby poskytoval ideální (nebo téměř) architekturu pro neustále nové požadavky. V tomhle režimu si nemůžete dovolit měsíc něco někde mít bokem, protože měsíc změn v architektuře budete integrovat další týden, jestli vůbec.Mé řešení je ale jiné. Konflikty se řeší jenom mezi těmi částmi, kde ten konflikt vznikl – ostatní to nezajímá. Takže není nutné brzdit vývoj, jenom se prostě nenabalí celý projekt na jedno místo, kam všichni přihazují, ale rozdělí se na malé části, mezi kterými jsou definovaná rozhraní.
Historky lidí i moje osobní zkušenosti v tomhle hovoří jasně. Buď má software denní integraci a nebo hnije.Vám připadá, že linuxové jádro hnije?
Já nevím, ale už to píšu potřetí - když udělám refactoring, tak automaticky refactoruju i všechno kolem, aby to pak fungovalo. Nikdo na nikoho nečeká.Mám rozpracovaný kód. Vy v tom kódu uděláte nějaký refactoring. Já chci kód poskytnout dalšímu týmu, který ho bude používat, ale nemůžu, nejdřív jej musím zmergovat s vašimi změnami. Takže ten další tým počká, než udělám merge. Pak se taky může ukázat, že ta vaše změna nefunguje a brání nám využívat náš kód – tak si počkáme, než to opravíte.
A to se bije s tím co říkám jak?Vy říkáte, že mají tu funkcionalitu dávat do společného stromu pokaždé, když to jde přeložit a projdou testy. Nezávisle na tom, zda se tím třeba nerozbije jiná část programu.
V tom, že se nedá testovat velká část funkcionality aplikace.Proč? Můžete mi to prosím nějak sepsat od A do Z do jednoho odstavce - já se v tom totiž ztrácím. Zatím vím, že jsem udělal změnu v košíku, která není v GUI. Abych si to představil, tak dejme tomu, že kromě zboží lze do košíku vložit přání (jako k dárku). Funkci už mám, akorát k tomu není formulář na webu. A co dál? Proč by se ta funkce nebo "velká část funkcionality aplikace" (jaká?) nedala testovat?
Já jsem radši, když se taková věc ke mně vůbec nedostane. A když už ta chyba probublá až ke mně, nechci kvůli ní zastavit práci a čekat, až ji opraví. Chci zatím pracovat na něčem jiném.Tak to jsme radši všichni. Já nehlásám odevzdávání nekvalitní práce. Naopak chci abych dostával práci co nejkvalitnější a prostředkem k tomu je co nejrychlejší zpětná vazba. Když už ta chyba probublá ke mně, tak můžu vždycky použít verzi N-1. Nemusím na nic čekat.
Takže není nutné brzdit vývoj, jenom se prostě nenabalí celý projekt na jedno místo, kam všichni přihazují, ale rozdělí se na malé části, mezi kterými jsou definovaná rozhraní.Já mám dojem, že dáváte na rovnost rozhraní v kódu (technické) a rozhraní procesní (mezi lidmi). Kód může být modulární a dobře strukturovaný, a zapouzdřený atd - a měl by být, tím se samozřejmě brutálně usnadňuje jeho používání, omezují chyby atd. Ale to neznamená, že je kód politicky rozparcelovaný na frantovo, pepovo a jindrovo, a když chci změnit frantovo, tak musím posílat kolkovanou žádost. Naopak, když je kód udělaný technicky dobře, tak franta může jet spokojeně na dovolenou a ostatní to zvládnou i bez něj.
Vám připadá, že linuxové jádro hnije?Linuxové jádro má jednak denní integraci (linux-next) a v tom nextu je často dost konfliktů které se systematicky řeší. Dále má poměrně dlouhé období na řešení regresí v poměru k merge oknu. Takže nějaký mechanizmus tam funguje, a funguje docela dobře, jinak by se vývoj rozpadl. Všimněte si např. že už se jádro nedělí na lichou vývojovou a sudou stabilní verzi, a všimněte si, že když se ta změna udělala tak se hodně lidí bouřilo, že se jim najednou v každé verzi mění API pod rukama. Jinak to ale dělat nejde. Buď se dělají změny volně a nebo program začne kostnanět. Jestli ten mechanizmus lze zlepšit procesně to se necítím povolaný soudit protože ten projekt je dost unikátní jak svým zaměřením tak svým rozměrem. Co si ale myslím že by pomohlo určitě, kdyby nějaké testy měli a neřešili stabilitu jen tak, že pokud se do 1 měsíce od RC neozve nikdo s problémem tak je asi vše v pořádku.
Vy říkáte, že mají tu funkcionalitu dávat do společného stromu pokaždé, když to jde přeložit a projdou testy. Nezávisle na tom, zda se tím třeba nerozbije jiná část programu."Projdou testy" a "rozbije část programu" nejde dohromady.
Proč? Můžete mi to prosím nějak sepsat od A do Z do jednoho odstavce - já se v tom totiž ztrácím. Zatím vím, že jsem udělal změnu v košíku, která není v GUI. Abych si to představil, tak dejme tomu, že kromě zboží lze do košíku vložit přání (jako k dárku). Funkci už mám, akorát k tomu není formulář na webu. A co dál? Proč by se ta funkce nebo "velká část funkcionality aplikace" (jaká?) nedala testovat?Má funkci vložení položky do košíku. Funguje, používá se, paráda. Pak se udělá nějaká nekompatibilní změna v logice aplikace (tu udělá programátor). Změnu dá do repository, aby s ní mohl pracovat autor HTML šablony. Změna je nekompatibilní, takže do změny šablony se místo přidání položky do košíku zobrazí chybová zpráva. Kdokoli, kdo si teď stáhne aktuální verzi z repository, má smůlu, protože v tom e-shopu nepřidá do košíku žádný produkt, tím pádem nemůže vytvořit objednávku, vyfakturovat, expedovat. Jiný autor šablony, který má vyřešit problém s přetékající tabulkou rekapitulace objednávky více než 5 kusů zboží v MSIE 8 zatím půjde na kafe a počká, až bude v repository kód, který mu dovolí si takovou stránku vůbec zobrazit.
Naopak chci abych dostával práci co nejkvalitnější a prostředkem k tomu je co nejrychlejší zpětná vazba.Vy odvádíte nejkvalitnější práci, když jste pod tlakem a spěchá se na vás? To jste asi výjimka.
Když už ta chyba probublá ke mně, tak můžu vždycky použít verzi N-1. Nemusím na nic čekat.Jenže vy potřebujete navázat na kód někoho jiného, který je ve verzi N+1.
Já mám dojem, že dáváte na rovnost rozhraní v kódu (technické) a rozhraní procesní (mezi lidmi).O procesním rozhraní jsem tady nenapsal ani čárku.
Linuxové jádro má jednak denní integraci (linux-next) a v tom nextu je často dost konfliktů které se systematicky řeší.Ale do té denní integrace se nedostává kód,který vznikl za ten den, ale který vznikal dny nebo týdny v jiných větvích. To je ten drobný detail.
Takže nějaký mechanizmus tam funguje, a funguje docela dobře, jinak by se vývoj rozpadl.Přičemž tento mechanismus stojí mimo jiném na decentralizovaném vývoji v mnoha paralelních větvích. Přechod na BitKeeper umožnil další rozvoj jádra v době, kdy už se objevovaly obavy, že tehdejší model vývoj není dál udržitelný.
"Projdou testy" a "rozbije část programu" nejde dohromady.Pro mne program funguje tehdy, když dělá to, co má, ne když projdou testy.
Změna je nekompatibilní, takže do změny šablony se místo přidání položky do košíku zobrazí chybová zpráva.To je ovšem chyba - kód nefunguje. Tam už jsme byli.
Jiný autor šablony, který má vyřešit problém s přetékající tabulkou rekapitulace objednávky více než 5 kusů zboží v MSIE 8 zatím půjde na kafe a počká, až bude v repository kód, který mu dovolí si takovou stránku vůbec zobrazit.A nebo ten commit prostě revertne a bude pracovat dál. Jít na kafe a čekat je sice pohodlné, ale to bych takhle mohl dělat se vším. Třeba nic nedělat čekat že mi spadnou z nebe peníze na účet. Jak by se situace změnila, pokud by chybová hláška místo košíku byla v nějaké branchi 2 týdny a přišlo by se na to až při "velkém merge"? Místo záležitosti na 2 minuty - "revert a běž si to spravit" - by se nejdřív hodinu hledalo kdo a kdy a jakou chybu udělal.
Vy odvádíte nejkvalitnější práci, když jste pod tlakem a spěchá se na vás? To jste asi výjimka.Já jsem o tlaku a spěchu nic nepsal. Mnou popisovaný způsob práce naopak tlak a spěch úspěšně neutralizuje. Tlak a spěch vzniká v případě že stojíte před nedefinovaným množstvím práce a/nebo se nemůžete spolehnout na práci která již byla odvedena. Já mám vždy za sebou funkční celek, který je hotový (nic nezůstalo "na někdy") a před sebou tolik práce, kolik stihnu udělat za cca půl dne (jejímž výsledkem je opět hotový a fungující celek). Nevím co by měla být větší pohoda.
Jenže vy potřebujete navázat na kód někoho jiného, který je ve verzi N+1.To máte smůlu, protože N+1 je chybná verze. Zachrání vás jen to, když kód který potřebujete je N+1, a kód způsobující chybu je N+2 (nebo naopak). Čili opět systém malých častých změn.
Ale do té denní integrace se nedostává kód,který vznikl za ten den, ale který vznikal dny nebo týdny v jiných větvích. To je ten drobný detail.A co se tam dostávalo ty týdny před tím?
Pro mne program funguje tehdy, když dělá to, co má, ne když projdou testy.A to co má dělat se nejlépe popisuje testy. Klidně i postupy pro člověka - klikni sem, objeví se tamto, ale musí to být jasně popsáno. Jinak si to každý vyloží po svém. Samozřejmě manuální testy jsou drahé.
To je ovšem chyba - kód nefunguje. Tam už jsme byli.No aplikační logika funguje, a oprava webové šablony není práce pro programátora té logiky. Pokud se má vývoj pohnout dopředu, zak to holt bude muset projít tímto stavem. A nebo si programátor s autorem šablony domluví rozhraní mimo VCS (proč?), pak se upraví šablona, aby fungovala s oběma verzemi (práce navíc), pak se změní logika a na závěr se změní šablona na definitivní variantu.
A nebo ten commit prostě revertne a bude pracovat dál.To bude prima práce, když každou změnu v kódu vzápětí někdo revertne.
Jak by se situace změnila, pokud by chybová hláška místo košíku byla v nějaké branchi 2 týdny a přišlo by se na to až při "velkém merge"?Změnila by se podstatně. Ty dva týdny ve větvi by se pracovalo na odstranění té chyby, a do hlavní větve by se přetáhl až opravený, odladěný a otestovaný kód.
Já mám vždy za sebou funkční celek, který je hotový (nic nezůstalo "na někdy") a před sebou tolik práce, kolik stihnu udělat za cca půl dne (jejímž výsledkem je opět hotový a fungující celek). Nevím co by měla být větší pohoda.Větší pohoda je, když můžu na nějaké funkci dělat do té doby, než ji považuji za hotovou, a netiká mi budík, že ji musím comitnout do hodiny za každou cenu.
To máte smůlu, protože N+1 je chybná verze. Zachrání vás jen to, když kód který potřebujete je N+1, a kód způsobující chybu je N+2 (nebo naopak). Čili opět systém malých častých změn.Ve verzi N někdo comitnul změnu s chybou, vzápětí jiný comitne verzi N+1 s kódem, na který mám navázat. Pak se zjistí, že v N je chyba, udělá se revert na verzi N-1 – a když to dobře půjde, může autor verze N+1 své změny comitnou podruhé.
A co se tam dostávalo ty týdny před tím?Kód, který zase v jiné větvi vznikal dny nebo týdny.
A to co má dělat se nejlépe popisuje testy. Klidně i postupy pro člověka - klikni sem, objeví se tamto, ale musí to být jasně popsáno. Jinak si to každý vyloží po svém. Samozřejmě manuální testy jsou drahé.To by mne zajímalo, jak ty komplet testy (včetně manuálních) zvládáte během toho půl dne, co máte na vývoj. Abyste stihl udělat změnu, zmergovat ji, udělat komplet testy a takhle ověřený kód vnutit ostatním.
Pokud se má vývoj pohnout dopředu, zak to holt bude muset projít tímto stavem.Už se v tom zas ztrácím, ale jsem si jistý, že vývoj dopředu nevede přes chybovou hlášku místo košíku, rozhodně ne mimo lokální PC vývojáře
A nebo si programátor s autorem šablony domluví rozhraní mimo VCS (proč?), pak se upraví šablona, aby fungovala s oběma verzemi (práce navíc), pak se změní logika a na závěr se změní šablona na definitivní variantu.Tomuhle taky nerozumím, ale mimo VCS jít nic nemusí. Pokud funguje aplikační logika nového košíku, tak se na něj může udělat webová tvář, aniž by to ovlivňovalo starý košík. Pokud to stihnete za jeden den, tak to můžete vyměnit, pokud je to na dýl tak to musíte měnit per partes. Pak budete mít po jistou dobu kombinaci nového a starého košíku, fungovat ale bude vše. Zkuste dát nějaký příklad, kde se má něco změnit, a vznikne problém, ale ten problém není chybová hláška v trunku, protože to už jsme vyčerpali.
To bude prima práce, když každou změnu v kódu vzápětí někdo revertne.To asi není moc prima když je každá změna v kódu tak špatná že nezbejvá než ji revertovat.
Změnila by se podstatně. Ty dva týdny ve větvi by se pracovalo na odstranění té chyby, a do hlavní větve by se přetáhl až opravený, odladěný a otestovaný kód.To skoro zní jako byste předpokládal, že když si nevšimnu chybu před commitem do trunku, tak si ji zaručeně všimnu před commitem do větve. Mnohem pravděpodobnější je, že si tu chybu nikdo nevšimne, až dokud se větev nebude zavírat.
Větší pohoda je, když můžu na nějaké funkci dělat do té doby, než ji považuji za hotovou, a netiká mi budík, že ji musím comitnout do hodiny za každou cenu.No tak vám tiká budík na 2 týdny. Odhad práce na 2 týdny bude z definice méně přesný než odhad práce na několik hodin. Proto se ty věci sekají po hodinách a ne týdnech. Nebo vám netiká budík a pak to bude možná zejtra a možná za rok. Takhle se dá pracovat při opravě chyby v KDE, ne při zaměstnání.
Ve verzi N někdo comitnul změnu s chybou, vzápětí jiný comitne verzi N+1 s kódem, na který mám navázat. Pak se zjistí, že v N je chyba, udělá se revert na verzi N-1 – a když to dobře půjde, může autor verze N+1 své změny comitnou podruhé.Ve všech normálních VCS jde oddělat commit N tak, aby tam N+1 zůstal.
To by mne zajímalo, jak ty komplet testy (včetně manuálních) zvládáte během toho půl dne, co máte na vývoj. Abyste stihl udělat změnu, zmergovat ji, udělat komplet testy a takhle ověřený kód vnutit ostatním.Naplánuju si množství změn tak, abych to za tu dobu měl. Já nevím, ale za půl dne se dá napsat spousta kódu. Spousta věcí netrvá ani tolik. A jiné zas trvají celý den, ale rozhodně ne týden. Samozřejmě že za tu dobu nemusí být něco funkčně hotové, ale je to hotové technicky, a to třeba do té míry, že zítra si to může stáhnout někdo jiný a pokračovat. Viz třeba ta výměna databáze. Jak dlouho Vám trvá upravit skript kterej balí RPMko, aby do něj přibalil dalších 5 souborů, a ověřit že to dělá? A jak dlouho pak trvá napsat skript kterej spustí databázi jako službu? Je to každé snad práce na týden? Takže asi tak.
Pokud funguje aplikační logika nového košíku, tak se na něj může udělat webová tvář, aniž by to ovlivňovalo starý košík.Nemůže, pokud nechcete zbytečně udržovat dvě verze vedle sebe v jedné větvi kódu.
Pokud to stihnete za jeden den, tak to můžete vyměnit, pokud je to na dýl tak to musíte měnit per partes.Proč musím? Nemusím a nechci. Nejefektivnější je udělat to bez nějakého rozptylování jinými změnami za pár dní, a já nechci, aby mne organizace práce s VCS nutila dělat to neefektivně po menších částech dýl.
Zkuste dát nějaký příklad, kde se má něco změnit, a vznikne problém, ale ten problém není chybová hláška v trunku, protože to už jsme vyčerpali.Ten problém, že se kvůli chybě nebo rozpracované práci v trunku zastaví vývoj všech, je podle mne velmi závažný. Žádný jiný příklad nemám, všechno ostatní jsou proti tomuhle prkotiny.
To skoro zní jako byste předpokládal, že když si nevšimnu chybu před commitem do trunku, tak si ji zaručeně všimnu před commitem do větve.Ne. Akorát vím, že jedna funkcionalita se ne pokaždé zvládne jedním commitem jednoho vývojáře. Takže vývojář to do větve dá s tím, že ví, že to není hotové, ale dává to tam, aby na tom mohli pracovat další. Když se na tom postupně vystřídá několik lidí a dodělají to, otestuje se to, a pak se to teprve jako hotová a otestovaná věc přetahne do hlavní větve.
Ve všech normálních VCS jde oddělat commit N tak, aby tam N+1 zůstal.jenže v commitu N+1 jsou už zmergované změny s N, takže po odstranění commitu N vám zbyde nepřeložitelný kód.
Samozřejmě že za tu dobu nemusí být něco funkčně hotové, ale je to hotové technicky, a to třeba do té míry, že zítra si to může stáhnout někdo jiný a pokračovat.To je ten lepší případ. Mně se ovšem nelíbí to, že příliš často nastane také druhý případ, že si to druhý den všichni stáhnou, a všem to přestane fungovat. A místo aby to řešili jeden dva lidé, kterých se ten problém týká, musí se tím zabývat všichni.
Nejefektivnější je udělat to bez nějakého rozptylování jinými změnami za pár dní, a já nechci, aby mne organizace práce s VCS nutila dělat to neefektivně po menších částech dýl.To je za předpokladu, že po těch pár dnech nebudete mít integrační peklo. Po pár dnech asi ne, ale po pár týdnech/měsících "nerušeného" vývoje to přichází celkem pravidelně. Tam pak naskakují dny práce a čas strávený integrací po měsíci daleko převyšuje jakýkoliv jiný overhead. Pokud jste tohle nezažil tak se to blbě vysvětluje.
Ten problém, že se kvůli chybě nebo rozpracované práci v trunku zastaví vývoj všech, je podle mne velmi závažný. Žádný jiný příklad nemám, všechno ostatní jsou proti tomuhle prkotiny. ...Ano je to závažný problém, stejně závažný jako když odejde disk na serveru, kde je ten kód, atd...
... Mně se ovšem nelíbí to, že příliš často nastane také druhý případ, že si to druhý den všichni stáhnou, a všem to přestane fungovat.... a pokud se vám to stává příliš často, tak je problém v těch lidech co posílají nefunkční kód, nebo v nedostatečném pokrytí testy, ale rozhodně ne v tom, že integrujete příliš často. Odstraňujte příčiny, ne následky.
jenže v commitu N+1 jsou už zmergované změny s N, takže po odstranění commitu N vám zbyde nepřeložitelný kód.Tak to je blbé. To pak musíte opravit N, a případně i N+1. Ale bude to ještě horší, pokud to se to nebude týkat jen N+1, ale i N+2..N+100 ve 3 větvích.
To je ten lepší případ.Ale já mluvím o tom lepším případu. Tahle metodika funguje, pokud se dodržuje jako celek. Nelze z ní vyndat náhodně 2 věci a ve jménu toho pracovat nezodpovědně.
Vzhledem k tomu, že s ní máte špatné zkušenosti jenom vyZaměňujete "v této diskusi o tom hovoříte jen vy" a "v celém vesmíru o tom hovoříte jen vy". Vylezte z diskuse, zajděte na google, dejte si tam integration hell, continuous integration, nebo prostě klikněte na odkazy které jsem poskytl - např tým chromia popisuje problémy s tímto fenoménem. Já vám totiž popisuju jen věci které jsou obecně známé už přes 10 let.
Při normálním vývoji podle mne vývojáři pracují na nějaké funkcionalitě, takže jejich zásahy se omezují na kód, který s tím souvisí.To je špatný předpoklad - který setrvale prezentujete - vývojář pro svou funkcionalitu potřebuje mít možnost zasahovat do celého kódu. Pokud zaženete programátory každý na svůj píseček tak sice předejdete konfliktům ale v kódu se bude kupit hack za hackem, berlička za berličkou, až z toho bude víte co.
Takže ona bájná integrace znamená jenom přetáhnout patche z jedné větve, a máte hotovo – jedním příkazem.Ona bájná integrace zahrnuje přetažení z třeba 20 větví. Vždyť ostatně i o tom je ten linux-next. Konflikty jsou na denním pořádku a vývojáři je neustále opravují. A taky často minimálně jedna konfigurace nejde vůbec přeložit.
vývojář pro svou funkcionalitu potřebuje mít možnost zasahovat do celého kóduTakového vývojáře bych hnal. To jako vývojář, který má upravit makro v OO.org, si má změnit pár řádek v kernelu, trochu v glibc, nějaký kód v gcc, trochu v OO.org a na závěr pár řádek v tom makru? Jenom proto, že má pocit, že takhle to bude lepší? Pro něj možná, ale on není jediným uživatelem všeho toho kódu.
Pokud zaženete programátory každý na svůj píseček tak sice předejdete konfliktům ale v kódu se bude kupit hack za hackem, berlička za berličkou, až z toho bude víte co.S tím jsem se nesetkal. Asi mám štěstí na programátory, kteří respektují, že kód není jen jejich, a neupravují každý řádek k obrazu svému.
Konflikty jsou na denním pořádku a vývojáři je neustále opravují.Takže se to bez problémů zvládá. Jediný rozdíl oproti tomu vašemu řešení je, že se řeší konflikty až hotového kódu a ne všech meziverzí, takže celkově je těch konfliktů méně.
To jako vývojář, který má upravit makro v OO.org, si má změnit pár řádek v kernelu, trochu v glibc, nějaký kód v gcc, trochu v OO.org a na závěr pár řádek v tom makru?Máte neuvěřitelnou schopnost stavět věci úplně mimo kontext. Vemte si klasický příklad - chci dostat na web stránku další report, takže na to musím udělat zásah do všech vrstev přes UI až po databázi. Možná zjistím, že v business vrstvě se mi bude něco dělat líp jinak, takže udělám změny algoritmů, trochu refactoruju, možná zjistím, že v data vrstvě mám kus hodně podobného kódu, takže zavedu nějakou abstrakci, atd. Možná taky zjistím, že současná implementace db ten dotaz nezvládá takže kvůli implementaci toho reportu dokonce musím vyměnit celou db...
Pro něj možná, ale on není jediným uživatelem všeho toho kóduTím implikujete možný vznik regresí? To se právě hlídá tím testováním.
S tím jsem se nesetkal. Asi mám štěstí na programátory, kteří respektují, že kód není jen jejich, a neupravují každý řádek k obrazu svémuJá nevím co a jak vyvíjíte, ale myslím si, že to, s čím jste se setkal, není z větší části o programátorech, ale o parametrech a potřebách toho projektu.
takže celkově je těch konfliktů méně.To mi připomíná ten vtip: nejlepší je jíst jen jednou denně - od rána do večera. Takže nejlepší je dělat jen jeden merge a pak mít jen jeden konflikt takový, že je červené úplně všechno.
Vemte si klasický příklad - chci dostat na web stránku další report, takže na to musím udělat zásah do všech vrstev přes UI až po databázi.To je sice zásah přes několik vrstev, ale do jedné funkcionality. Pokud do té samé funkcionality bude dělat zásah jiný vývojář, měl bych o tom vědět.
Možná zjistím, že v business vrstvě se mi bude něco dělat líp jinak, takže udělám změny algoritmů, trochu refactoruju, možná zjistím, že v data vrstvě mám kus hodně podobného kódu, takže zavedu nějakou abstrakci, atd.To ale přece pořád neznamená, že na tom samém kusu kódu budou dělat vývojáři, kteří o sobě nevědí. Snad je za ten kód někdo zodpovědný a ten rozhodne, jaká úprava se udělá, v jakém pořadí se udělají nebo aspoň řekne, děláte na tom dva, domluvte se.
Možná taky zjistím, že současná implementace db ten dotaz nezvládá takže kvůli implementaci toho reportu dokonce musím vyměnit celou db...Opět, snad se vám nestane, že se dva vývojáři jen tak rozhodnou, že změní databázi, a ostatním o tom neřeknou.
Tím implikujete možný vznik regresí? To se právě hlídá tím testováním.Pokud je ten kód tak perfektně pokrytý testy, změny, o kterých píšete, mohou být jen změny implementace. A na těch se nic složitě neintegruje, to se prostě nahradí jeden vnitřní kód za jiný.
Já nevím co a jak vyvíjíte, ale myslím si, že to, s čím jste se setkal, není z větší části o programátorech, ale o parametrech a potřebách toho projektu.Jestli má nějaký projekt potřebu, že tam programátoři náhodně přepisují každý kus kódu, na který narazí, aniž by znali souvislosti, nesouvisí vaše problémy s integrací s ničím jiným, než s touto podivuhodnou potřebou.
Takže nejlepší je dělat jen jeden merge a pak mít jen jeden konflikt takový, že je červené úplně všechno.Konflikty vznikají vaším specifickým přístupem k programování, vizte předchozí bod. Já nepotřebuju, aby se takovéhle konflikty rychle odhalily – já potřebuje, aby takovýchhle konfliktů nebylo víc než jeden za několik měsíců, a i pak je ten konflikt vyřešen za pár minut.
Snad je za ten kód někdo zodpovědný a ten rozhodne, jaká úprava se udělá, v jakém pořadí se udělají nebo aspoň řekne, děláte na tom dva, domluvte se.Ano a to domluvte se je nejlépe ve stylu "až bude změna hotová tak to hned commitni ať můžou ostatní pokračovat na novém kódu".
Opět, snad se vám nestane, že se dva vývojáři jen tak rozhodnou, že změní databázi, a ostatním o tom neřeknou.Řeknou, ale taky tu změnu udělají nezávisle na tom původním úkolu a pushnou ji do trunku hned, aby na nové db jel celý tým co nejdřív a né až za další 2 týdny, až se kromě změny db dodělá ještě ten formulář.
Konflikty vznikají vaším specifickým přístupem k programování, vizte předchozí bod.Není to můj specifický přístup. Přečtěte si o tom něco. Třeba tu prezentaci o vývoji google chrome. Pokud budete zavírat oči před obecně známými věcmi a dál si mlít tu svou, tak nemá smysl v debatě pokračovat.
pushnou ji do trunku hned, aby na nové db jel celý tým co nejdřív„Co nejdřív“ je pro vás asi univerzálně platné zaklínadlo. Proč kód taky nedodáváte „co nejdřív“ hned po commitnutí du trunku uživateli, bez zdržování se testováním? Úplně nejlepší by bylo uživateli tu aplikaci vyměnit pod rukama, měl by rozepsaný dopis, a vyběhlo by na něj okýnko: „Právě vám byla nainstalována nová verze aplikace. Přináší spoustu nových možností, které je ale nejprve nutné nastavit. Než budete pokračovat v práci, projděte prosím následujícím průvodcem nastavení. Nastavení nebude trvat déle, než tři hodiny.“ To by se vám líbilo? Mně ne, podle mne nemají vývojáři od kolegů dostávat hned čerstvě napsaný kód plný chyb, ale až kód, který už je nějak otestován. A o okamžiku přechodu na ten nový kód by si měli rozhodnout sami – je opravdu báječné, když člověk hledá nějakou svou chybu, a do toho se mu natlačí deset dalších chyb od ostatních.
„Co nejdřív“ je pro vás asi univerzálně platné zaklínadlo.Zato u Vás se mi zdá, že si myslíte, že když necháte novou verzi/program někde půl roku uležet, tak se sám magicky otestuje. Na to, aby se to otestovalo, tak to někdo musí mít nainstalované/dostupné/atd. Což nikdo neudělá, pokud budete tvrdit, že "nová verze není otestovaná, raději používejte tu starou". To je takový začarovaný kruh.
Proč kód taky nedodáváte „co nejdřív“ hned po commitnutí du trunku uživateli, bez zdržování se testováním?Protože to je nezodpovědné. Já tomu dám před releasem maximum péče, a to maximum se snažím skomprimovat do automatických testů, které netrvají týden.
Píšu jenom o tom, že se uživatelům (i interním) dává až po otestování.A jaký postup na to otestování používáte?
Proč je nezodpovědné dávat neotestovaný kód externím uživatelům, ale je zodpovědné jej dávat interním uživatelům? Automatizované testování je jen tak dobré, jak dobré máte testy a jak dobře je jimi pokryta funkcionalitu programu.Interním i externím se dává to samé - kód který prošel testy, externím navíc takový, který má N+1 funkcionalitu (jinak nemají důvod upgradovat)... a ano, pokrytí testy musí být tak dobré, jak to potřebujete.
A jaký postup na to otestování používáte?Nejrůznější postupy, kterými se dá ověřit funkčnost dané části programu – kompilace a sestavení, jednotkové testy, automatizované testy funkcionality a manuální testy funkcionality.
Interním i externím se dává to samé - kód který prošel testy, externím navíc takový, který má N+1 funkcionalitu (jinak nemají důvod upgradovat)... a ano, pokrytí testy musí být tak dobré, jak to potřebujete.Asi si pořád nerozumíme v tom, co je „kód, který prošel testy“ nebo „pokrytí testy“. Já si pod tím pořád představuji rychlé automatické testy (jednotkové, možná integrační), a to podle mne rozhodně není dostatečné otestování pro to, abych danou věc pokládal za otestovanou a dával ji dál.
Já si pod tím pořád představuji rychlé automatické testy (jednotkové, možná integrační), a to podle mne rozhodně není dostatečné otestování pro to, abych danou věc pokládal za otestovanou a dával ji dál.Unit/integrační testy obvykle vychytají velkou část bugů a problémů - zejména stabilitu, robustnost, krajní případy, zkrátka vše na co by se naivní programátor vykašlal - takže když tyhle projdou a pokrytí testy máte dobré, tak se můžete spolehnout že revize je technicky v pořádku. Kromě toho se používají akceptační testy nebo testy chování, kde automatizujete to, co byste musel normálně otestovat z pohledu zákazníka ručně. Ty testují, že program obsahuje funkčnost kterou chce zákazník a IMHO nemáte šanci donutit zákazníka aby takový test prováděl ručně pro všechny feature na každé branchi. Pokud prochází jednotkové i akceptační testy tak máte dost dobrou nápovědu, že produkt můžete vydat - nemusíte na nic čekat. Pokud do procesu testování chcete zapojit manuální práci, je lépe ji použít k tomu, aby se nacházely nové třídy chyb a testů, nikoliv, aby se hledaly pouze nové chyby ke kterým jen chybí testy, nebo nedej bože aby se hledaly chyby v tom, co před tím fungovalo, protože k tomu rovněž chybí testy.
Unit/integrační testy obvykle vychytají velkou část bugů a problémů - zejména stabilitu, robustnost, krajní případy, zkrátka vše na co by se naivní programátor vykašlal - takže když tyhle projdou a pokrytí testy máte dobré, tak se můžete spolehnout že revize je technicky v pořádku.Opravdu vám testy píší ti nejlepší programátoři, a vlastní kód pak ti podprůměrní, kteří navíc nevidí zdrojáky testů? Nebo ve skutečnosti jeden programátor píše kód i odpovídající test, takže pokud zapomene ošetřit krajní případy v kódu, neošetří je ani v testu?
Kromě toho se používají akceptační testy nebo testy chování, kde automatizujete to, co byste musel normálně otestovat z pohledu zákazníka ručně. Ty testují, že program obsahuje funkčnost kterou chce zákazník a IMHO nemáte šanci donutit zákazníka aby takový test prováděl ručně pro všechny feature na každé branchi.IBM se tady dělá s nějakým Watsonem, a přitom už se tady dávno daleko lepší umělá inteligence používá na testování programů. Ano, takovéhle testy se mohou používat a mohou otestovat třeba 1 promile (ano, přeháním) funkčnosti programu, tedy pár nejzákladnějších věcí. Jak asi náročné a komplexní by takové testy musely být jenom pro nějaké jednoúčelové unixové utility?
Pokud prochází jednotkové i akceptační testy tak máte dost dobrou nápovědu, že produkt můžete vydat - nemusíte na nic čekat.Pořád ale je rozdíl mezi vydáním produktu a okamžitým vnucením produktu.
Pokud do procesu testování chcete zapojit manuální práci, je lépe ji použít k tomu, aby se nacházely nové třídy chyb a testů, nikoliv, aby se hledaly pouze nové chyby ke kterým jen chybí testy, nebo nedej bože aby se hledaly chyby v tom, co před tím fungovalo, protože k tomu rovněž chybí testy.Jak ty vaše testy objeví takovou trivialitu, jako je třeba překlep v textu UI? Používáte nějaké OSS knihovny? Nemohl byste zveřejnit ta kvanta testů, která na ně používáte? OSS komunitě by to jistě prospělo a pomohlo by to zlepšit kvalitu těch knihoven. Slovem „testy“ myslíte pořád ještě testy, nebo už je to zaklínadlo?
Opravdu vám testy píší ti nejlepší programátoři, a vlastní kód pak ti podprůměrní, kteří navíc nevidí zdrojáky testů?To nezní moc dobře, pracovat s testem o kterém nevím co assertuje
Pro unit testy normálně píše test a kód jeden, nebo dva najednou. Pokud chtějí nejlepší něco učit ty méně zkušené, tak je nejlepší si sednout spolu a projít si celý cyklus, nebo případně dělat každý na svém ale několikrát denně udělat kontrolu toho co dělá ten vyučovaný.
pokud zapomene ošetřit krajní případy v kódu, neošetří je ani v testu?Ano a tam se zhodnotí pak ta kontrola méně zkušeného nebo manuální práce testera který hledá nové třídy (ne instance) problémů.
Jak asi náročné a komplexní by takové testy musely být jenom pro nějaké jednoúčelové unixové utility?Já v tom nevidím nic světoborného. Např. když si vemu man cat,
Concatenate FILE(s), or standard input, to standard output.Tak udělám
cat 1.txt 2.txt 3.txt > actual.txt assertEquals actual.txt 1-and-2-and-3.txtNebo
echo "nazdar" | cat > actual.txt assertEquals actual.txt nazdar.txtPak tam mám
-A, --show-all
equivalent to -vET
Tak udělám
param_actual = parseParameters("-A")
param_expected = parseParameters("-vET")
assertEquals param_actual param_expected
Pak mám
-b, --number-nonblank
number nonempty output lines
Takže
cat file-with-blank-and-nonblank-lines.txt > actual.txt assertEquals actual.txt file-with-numbered-nonblank-lines.txtA dál už to je to samé v bledě modrém. Když budu chtít tak ten man a odpovídající testy dám vedle sebe, aby se to snadno kontrolovalo. Každopádně myslím že za den práce mám cat otestovaný na 100% toho co říká man, žádný superpočítač nepotřebuji.
Pořád ale je rozdíl mezi vydáním produktu a okamžitým vnucením produktu.Já v tom nějaký velký rozdíl nevidím, pokud nemá být "vnucení" o nějakém násilí na uživateli.
Jak ty vaše testy objeví takovou trivialitu, jako je třeba překlep v textu UI?Mám případ, kde záleží na přesném znění a pořadí slov stringu který se generuje, tak na to mám jednoduchý test. U hlášek v UI, které jsou někde zašité jako konstanty, není moc pravděpodobné že by někdo nechtěně zavedl regresi, takže nemám potřebu nad tím dělat opičárny.
Používáte nějaké OSS knihovny? Nemohl byste zveřejnit ta kvanta testů, která na ně používáte? OSS komunitě by to jistě prospělo a pomohlo by to zlepšit kvalitu těch knihoven.Kdybych v tom měl volnou ruku a vůli, tak bych to jistě napsal a zveřejnil, ale ani jedno momentálně nemám.
Slovem „testy“ myslíte pořád ještě testy, nebo už je to zaklínadlo?Test je test, abrakadabra je zaklínadlo.
To nezní moc dobře, pracovat s testem o kterém nevím co assertujePokud vím, co test kontroluje, je snadné napsat kód tak, aby testu vyhověl, a jinak dělal hlouposti.
Já v tom nevidím nic světoborného. Např. když si vemu man cat, …Aha. Takže píšete o akceptačních testech, které vám ve skutečnosti nezkontrolují prakticky vůbec nic. Pak je ale nesmysl na takové testy spoléhat.
Každopádně myslím že za den práce mám cat otestovaný na 100% toho co říká man, žádný superpočítač nepotřebuji.Ano, můžete mít za den otestováno 100 % toho, co říká man, tzn. možná 1 promile funkcionality programu. O tom, zda ten program funguje, tedy nebudete vědět nic.
Já v tom nějaký velký rozdíl nevidímJe v tom zásadní rozdíl – buď uživatel přejde na novou verzi tehdy, když se to jemu hodí, a když mu to přinese nejmenší problémy. A nebo na ni musí přejít okamžitě, a vedle svých problémů musí řešit ještě problémy s přechodem na novou verzi.
Mám případ, kde záleží na přesném znění a pořadí slov stringu který se generuje, tak na to mám jednoduchý test. U hlášek v UI, které jsou někde zašité jako konstanty, není moc pravděpodobné že by někdo nechtěně zavedl regresi, takže nemám potřebu nad tím dělat opičárny.Pak také máte případ, že se text hlášky změní nebo se přidá nová hláška. Což ty vaše testy vůbec nepokrývají. Stejně tak nastávají případy, kdy se mění nebo přidává funkcionalita – opět to nemáte pokryté testy. Ještě pořád věříte tomu, automatickými testy dokážete pokrýt alespoň významnou část funkcionality programu?
Kdybych v tom měl volnou ruku a vůli, tak bych to jistě napsal a zveřejnil, ale ani jedno momentálně nemám.Jak napsal? Podle toho, co píšete, už to musíte mít dávno napsané. Nebo je to další oblast, ve které spoléháte na testy, které nemáte?
Test je test, abrakadabra je zaklínadlo.No jo, jenže ve vašem případě testy něco testují, i když neexistují, v testech nemůže být chyba… Připomíná to spíš to zaklínadlo.
Pokud vím, co test kontroluje, je snadné napsat kód tak, aby testu vyhověl, a jinak dělal hlouposti.A to se chcete místo toho náhodně strefovat do testu o kterém nevíte co testuje? Samozřejmě že když znám test, tak je jednoduché k němu napsat kód - o tom je celá pointa test driven programování.
Ano, můžete mít za den otestováno 100 % toho, co říká man, tzn. možná 1 promile funkcionality programu. O tom, zda ten program funguje, tedy nebudete vědět nic.Akceptační test ověřuje zdokumentované chování z hlediska uživatele, 100% pokrytí mi nepřijde jako "nic" nebo "1 promile".
Je v tom zásadní rozdíl – buď uživatel přejde na novou verzi tehdy, když se to jemu hodí, a když mu to přinese nejmenší problémy. A nebo na ni musí přejít okamžitě, a vedle svých problémů musí řešit ještě problémy s přechodem na novou verzi.Za prvé uživatel je svéprávný člověk a upgradovat si může až bude chtít a za druhé a především celá metodologie vede k tomu aby problémů s přechodem na novou verzi byl odproštěn.
Pak také máte případ, že se text hlášky změní nebo se přidá nová hláška. Což ty vaše testy vůbec nepokrývají.To ňák nechápu - text se změní nebo přidá - a co (a jak) na tom chcete testovat? Jakému durchfallu tím testem chcete předejít?
Jak napsal? Podle toho, co píšete, už to musíte mít dávno napsané. Nebo je to další oblast, ve které spoléháte na testy, které nemáte?Nevím kde jsem napsal že mám něco dávno napsané. Sice existuje praktika zvaná API testy ale já ji nepoužívám dokud to není nezbytně potřeba. Preferuju knihovny/komponenty kde není takový bordel, abych si sám musel hlídat regrese ve funkcionalitě.
No jo, jenže ve vašem případě testy něco testují, i když neexistují, v testech nemůže být chyba… Připomíná to spíš to zaklínadlo.Koukám, že můj případ znáte lépe než já, a to navzdory tomu že jsem informace v tomhle smyslu ze sebe nikdy nevydával.
Ještě pořád věříte tomu, automatickými testy dokážete pokrýt alespoň významnou část funkcionality programu?Pokud bych tomu přestal věřit, tak se propadnu technologicky i myšlenkově o 20 let dozadu. Máte nějakou lepší metodiku?
A to se chcete místo toho náhodně strefovat do testu o kterém nevíte co testuje?Ne. Já chci napsat aplikaci, která dělá to, co se od ní čeká.
Akceptační test ověřuje zdokumentované chování z hlediska uživatele, 100% pokrytí mi nepřijde jako "nic" nebo "1 promile".Jenže to zdokumentované chování představuje 1 promile toho, co uživatel používá a očekává. Takže tím 100% pokrytím dokumentovaného chování dostanete to promilové pokrytí využívaného a očekávaného chování.
Za prvé uživatel je svéprávný člověk a upgradovat si může až bude chtítTakže programátor/uživatel si nemusí každý půl den přebírat práci jiných vývojářů, ale může si ji převzít, až bude chtít – to tady propaguju celou dobu.
To ňák nechápu - text se změní nebo přidá - a co (a jak) na tom chcete testovat? Jakému durchfallu tím testem chcete předejít?Pořád jste psal o tom, jak automatizované testy zajistí správné fungování aplikace. Změněný nebo přidaný text je příklad, který automatizované testy nedokážou postihnout.
Nevím kde jsem napsal že mám něco dávno napsané.Pořád jste se tvářil, že to, že projdou automatizované testy, pro vás znamená, že aplikace je funkční. Jak dokážete poznat, že jsou funkční knihovny, na kterých ta aplikace závisí, když na ně nemáte testy?
Pokud bych tomu přestal věřit, tak se propadnu technologicky i myšlenkově o 20 let dozadu. Máte nějakou lepší metodiku?Ano, mám. Nevěřit slepě tomu, že automatizovanými testy lze otestovat významnou část aplikace (zvlášť pokud je to aplikace založená na silné interakci s uživatelem). Připustit si, že značná část funkcionality aplikace se nedá ověřit jinak, než používáním té aplikace. A to nějakou dobu trvá. Proto v době vývoje nechám programátory, aby používali svou novou část, ale ostatní části aby měli pokud možno nezměněné. Teprve pokud se prokáže, že alespoň základní funkcionalita je použitelná, šíří se k dalším vývojářům. Tím se předchází tomu, aby jedna rozbitá funkcionalita bránila ve vývoji a testování ostatním.
Ne. Já chci napsat aplikaci, která dělá to, co se od ní čeká.A víte že to je "jen" to nejtěžší co se dá v softwarové branži chtít? ;) Vážně - co je podle Vás to co se od aplikace čeká? Jak to máte podchycené, jak s tím pracujete? Jsou to ty testy, nebo to jsou psané specifikace, nebo to je jen nějaká obecná pravda?
Jenže to zdokumentované chování představuje 1 promile toho, co uživatel používá a očekává.Bavili jsme se o aplikaci cat a já cat používám tak, že mu dám soubory na vstup a dostanu je na výstupu spojené. (Ty různé přepínače ani nepoužívám). Pokud to je jedno promile, co je těch dalších 999 případů?
Takže programátor/uživatel si nemusí každý půl den přebírat práci jiných vývojářů, ale může si ji převzít, až bude chtít – to tady propaguju celou dobu.A já nic nepropaguju, jen mám zkušenost, že je lepší když si to chce převzít/předat po půl dni.
Pořád jste psal o tom, jak automatizované testy zajistí správné fungování aplikace. Změněný nebo přidaný text je příklad, který automatizované testy nedokážou postihnout.Tenhle příklad není kompletní, protože nevystihuje, kdy je co dobře a kdy ne. Pokud to dokážete vystihnout, tak to za vás může ověřit počítač automatickým testem. Pokud to nejde vystihnout, tak to musíte kontrolovat sám. Většina věcí nějak vystihnout jde.
Jak dokážete poznat, že jsou funkční knihovny, na kterých ta aplikace závisí, když na ně nemáte testy?No, tohle je otázka na samostatnou debatu. Jak jsem psal, lze si samozřejmě napsat testovací baterii na každou funkci kterou použiju, ale to se nevyplácí. Já používám kombinaci různých přístupů.
Nevěřit slepě tomu, že automatizovanými testy lze otestovat významnou část aplikace (zvlášť pokud je to aplikace založená na silné interakci s uživatelem).Dobrá víra a slepá víra je rozdíl. Nástroje na automatické testování interakce existují.
Připustit si, že značná část funkcionality aplikace se nedá ověřit jinak, než používáním té aplikace.Taková část jistě existuje, ale z mých zkušeností rozhodně není značná. Opět jestli máte jiné zkušenosti tak si velmi rád rozšířím obzory.
Proto v době vývoje nechám programátory, aby používali svou novou část, ale ostatní části aby měli pokud možno nezměněné. Teprve pokud se prokáže, že alespoň základní funkcionalita je použitelná, šíří se k dalším vývojářům. Tím se předchází tomu, aby jedna rozbitá funkcionalita bránila ve vývoji a testování ostatním.Nemám ponětí na čem pracujete, takže si to řiďte jak chcete. Nicméně moje skromné 2 centy říkají že pokud si koncepty z naší debaty dohledáte, nastudujete a adaptujete na svůj projekt tak na tom neproděláte, a možná, za nějakou dobu, se nad tím svým původním přístupem dost podivíte.
Vážně - co je podle Vás to co se od aplikace čeká? Jak to máte podchycené, jak s tím pracujete? Jsou to ty testy, nebo to jsou psané specifikace, nebo to je jen nějaká obecná pravda?Psané specifikace, zákony, obecně známé věci, dohody… Testy jsou jen interní pomůcka pro vývoj a rozhodně nepokrývají většinu funkcionality aplikace.
Bavili jsme se o aplikaci cat a já cat používám tak, že mu dám soubory na vstup a dostanu je na výstupu spojené. (Ty různé přepínače ani nepoužívám). Pokud to je jedno promile, co je těch dalších 999 případů?Neexistující vstupní soubor, chyba při čtení nebo zápisu, změny ve vstupním souboru v průběhu čtení… To všechno jsou věci, které nejsou v dokumentaci popsané, a při tom spoléháte na to, že se nějak budou chovat. Nemusíte zrovna čekat, že při neexistujícím souboru to skončí s chybovým kódem 354, ale nejspíš očekáváte, že se to bude chovat nějak „rozumně“ a třeba to v takovém případě nesmaže všechny soubory, které smazat může. Přestože by takové chování nebylo v rozporu s manuálem.
Tenhle příklad není kompletní, protože nevystihuje, kdy je co dobře a kdy ne. Pokud to dokážete vystihnout, tak to za vás může ověřit počítač automatickým testem. Pokud to nejde vystihnout, tak to musíte kontrolovat sám. Většina věcí nějak vystihnout jde.Dobře je to tehdy, pokud je ten text správně česky, je srozumitelný a vyjadřuje tu správnou informaci. Automaticky to kontrolovat nejde, můžete jenom testovat, zda se ten text shoduje se vzorem – jenže to jste problém vytvoření správného textu jenom přesunul z hlavního programu do testu.
Jak jsem psal, lze si samozřejmě napsat testovací baterii na každou funkci kterou použiju, ale to se nevyplácí.No sláva. Takže už jsme snad dospěli k tomu, že spoustu věcí rozumně automaticky testovat nejde nebo se to nevyplatí. Takže automatizované testy pokrývají pouze část funkcionality (zpravidla menší). Takže to, že nějaký kód prošel automatizovanými testy, ještě vůbec neznamená, že je výsledek funkční.
Nástroje na automatické testování interakce existují.Existují, ale vytvoření a údržba příslušných testů rozhodně není zadarmo. Takže se používají maximálně na ověření klíčových funkcí, ne na pokrytí celé aplikace.
Taková část jistě existuje, ale z mých zkušeností rozhodně není značná. Opět jestli máte jiné zkušenosti tak si velmi rád rozšířím obzory.U aplikace, která je postavená především na interakci s uživatelem, je to značná část. Protože živého člověka se nám zatím moc nedaří simulovat.
Nicméně moje skromné 2 centy říkají že pokud si koncepty z naší debaty dohledáte, nastudujete a adaptujete na svůj projekt tak na tom neproděláte, a možná, za nějakou dobu, se nad tím svým původním přístupem dost podivíte.Koncept, který nutí celý vývojářský tým zabývat se chybou jednoho programátora a odložit kvůli ní svou práci, evidentně zdržuje spoustu lidí od jejich práce. Koncept, který neumožňuje programátorovi soustředit se na jednu změnu, ale neustále ho vyrušuje spoustou dalších změn, také zpomaluje práci a zvyšuje pravděpodobnost chyb. Nevidím tam však nic, co by tyhle dvě zásadní nevýhody mohlo převážit.
Psané specifikace, zákony, obecně známé věci, dohody…A jak ošetříte situace, kdy si programátor vyloží špatně neco v psané specifikaci nebo zákoně, v obecně známé věci se plete, nebo se k němu dohoda dostane zkresleně?
Neexistující vstupní soubor, chyba při čtení nebo zápisu, změny ve vstupním souboru v průběhu čtení… To všechno jsou věci, které nejsou v dokumentaci popsané, a při tom spoléháte na to, že se nějak budou chovat. Nemusíte zrovna čekat, že při neexistujícím souboru to skončí s chybovým kódem 354, ale nejspíš očekáváte, že se to bude chovat nějak „rozumně“ a třeba to v takovém případě nesmaže všechny soubory, které smazat může. Přestože by takové chování nebylo v rozporu s manuálem.A to "rozumně" si právě může každý vykládat po svém. (Pojďme se dohadovat, jestli když neexistuje 5 souborů z 100, tak to má okamžitě zařvat a umřít, nebo je tiše přeskočit.) Co je horší, to nezdokumentované chování může být nekonzistentní v různých modulech aplikace, nebo se i náhodně měnit po dobu života té aplikace, podle toho kdo to zrovna programoval. Proto je dobré zdokumentovat i chování při chybách a následně ho můžete jednoduše podpořit nějakým testem. Není to ale 999 případů, je to jeden případ a leckdy i jedna věta v manuálu. Můžete třeba jít po té nejjednodušší variantě, a napsat, že když je chyba, tak konec. Jako test použijete např. neexistující soubor. Tím akceptační testování končí. To, že se chyby nikde nezatloukají a všechny interní funkce je buď zpracují nebo propagují dál, je už věc unit testů, které uživatel nemusí řešit.
No sláva. Takže už jsme snad dospěli k tomu, že spoustu věcí rozumně automaticky testovat nejde nebo se to nevyplatí.Špatně jste si to vyložil. Mně se nevyplatí psát testy za někoho jiného (tj. dodavatele knihovny), ne že se nevyplatí mít testy vůbec.
Takže automatizované testy pokrývají pouze část funkcionality (zpravidla menší).Menší co? Počet řádků v kódu? Záleží co na nich je. Nebo méně důležité funkce? Proč bych dělal testy na ně a ne na ty důležitější?
Takže to, že nějaký kód prošel automatizovanými testy, ještě vůbec neznamená, že je výsledek funkční.To ne. Ale pokud kód testy neprošel, tak výsledek funkční není. (Buď je chyba ve funkci nebo její specifikaci - testech.)
U aplikace, která je postavená především na interakci s uživatelem, je to značná část. Protože živého člověka se nám zatím moc nedaří simulovat.Pořád si neumím představit, o čem mluvíte, tak mi dejte nějaký příklad. Pokud možno prosím z praxe.
Koncept, který nutí celý vývojářský tým zabývat se chybou jednoho programátora a odložit kvůli ní svou práci, evidentně zdržuje spoustu lidí od jejich práce. Koncept, který neumožňuje programátorovi soustředit se na jednu změnu, ale neustále ho vyrušuje spoustou dalších změn, také zpomaluje práci a zvyšuje pravděpodobnost chyb. Nevidím tam však nic, co by tyhle dvě zásadní nevýhody mohlo převážit.Vnímáte to špatně, proto jsem doporučoval si to dohledat a nastudovat.
A jak ošetříte situace, kdy si programátor vyloží špatně neco v psané specifikaci nebo zákoně, v obecně známé věci se plete, nebo se k němu dohoda dostane zkresleně?Tak, že na specifikaci dělá víc lidí, když je něco nejasné, domlouvají se na tom, po napsání se to testuje.
Není to ale 999 případů, je to jeden případ a leckdy i jedna věta v manuálu.I na tom jednoduchém příkladu s
catem bylo vidět, že těch případů nepopsaných v manuálu je víc, než těch, které jsou v něm popsané. A z toho, co je popsané v manuálu, jste také testoval jen zlomek.
Mně se nevyplatí psát testy za někoho jiného (tj. dodavatele knihovny), ne že se nevyplatí mít testy vůbec.Jaký je rozdíl v tom, když je dodavatelem knihovny nějaká třetí strana, když je to jiný tým ve vaší firmě a nebo jste to vy sám?
Menší část funkcionality.Takže automatizované testy pokrývají pouze část funkcionality (zpravidla menší).Menší co?
Ale pokud kód testy neprošel, tak výsledek funkční není.Ovšem tenhle případ tady neřešíme. Vy jste neustále dělal dalekosáhlé záběry z toho, že kód automatizovanými testy prošel.
Pořád si neumím představit, o čem mluvíte, tak mi dejte nějaký příklad. Pokud možno prosím z praxe.Příklad z praxe: e-shop. Potřebujete otestovat, že se stránky zobrazují správně v různých prohlížečích, při různých rozlišeních, velikostech písma a velikostech okna. Že se při nějaké kombinaci prvky na stránce nepřeskupí tak, že stránka přestane být srozumitelná nebo ovladatelná.
Vnímáte to špatně, proto jsem doporučoval si to dohledat a nastudovat.Vnímám to, co popisujete vy. Způsob práce, který jste popsal, vede k mnou zmíněným problémům, výhodu jste žádnou nepopsal.
Dobře je to tehdy, pokud je ten text správně česky, je srozumitelný a vyjadřuje tu správnou informaci. Automaticky to kontrolovat nejde, můžete jenom testovat, zda se ten text shoduje se vzorem – jenže to jste problém vytvoření správného textu jenom přesunul z hlavního programu do testu.... což nemusí být špatně, pokud ten test je ve formě, kde může zákazník snadno zkontrolovat znění textu. Tahle metoda se používá a to tam, kde jde např. o přesnou terminologii, které programátor a priori nerozumí.
Tak, že na specifikaci dělá víc lidí, když je něco nejasné, domlouvají se na tom, po napsání se to testuje.Pokud "víc lidí" zahrnuje vaše programátory a zákazníka, tak jsme právě objevili akceptační testy.
I na tom jednoduchém příkladu s catem bylo vidět, že těch případů nepopsaných v manuálu je víc, než těch, které jsou v něm popsané.Ano, bylo vidět, že jakmile se začneme zabývat spustitelným manuálem, tak se objevují věci na které jsme před tím nepomysleli. To je dobře. Ve výsledku bude manuál přesnější.
A z toho, co je popsané v manuálu, jste také testoval jen zlomek.Napsal jsem, že testy na zbylé switche se dají dle navozeného příkladu jednoduše dodělat.
Jaký je rozdíl v tom, když je dodavatelem knihovny nějaká třetí strana, když je to jiný tým ve vaší firmě a nebo jste to vy sám?V tom kolik to stojí peněz? Nebo kam míří ta otázka?
Příklad z praxe: e-shop. Potřebujete otestovat, že se stránky zobrazují správně v různých prohlížečích, při různých rozlišeních, velikostech písma a velikostech okna. Že se při nějaké kombinaci prvky na stránce nepřeskupí tak, že stránka přestane být srozumitelná nebo ovladatelná.Zobrazování se obecně testuje špatně, protože počítač neumí rozlišit jestli je nějaký design přitažlivý natož funkční. Na druhou stranu je to jen to a nic víc - jestli se ta stránka vyrenderuje graficky dobře. Všechny funkce pod tou stránkou už podchytit testy lze. Už nemusíte manuálně testovat co se stane když někam kliknete.
Způsob práce, který jste popsal, vede k mnou zmíněným problémům, výhodu jste žádnou nepopsal.Já myslím, že jo, a že jste to jen poslal do /dev/null, ale to není podstatné. Pokud Vás to skutečně zajímá tak si můžete kdykoliv dohledat spoustu knih, diskusních skupin a blogů kde se tomu věnují do hloubky.
Jaký je v tom rozdíl z pohledu testování? Nejprve jste tvrdil, že to, že program projde automatizovaným testem, bohatě stačí jako ověření funkčnosti. Teď se postupně dozvídáme, že knihovny netestujete prakticky vůbec a spoustu dalších věcí také ne – mně z toho vychází, že automatizované testy vám pomáhají odhalit nějaké chyby, ale to, že automatizované testy projdou, ještě zdaleka neznamená, že je program funkční.Jaký je rozdíl v tom, když je dodavatelem knihovny nějaká třetí strana, když je to jiný tým ve vaší firmě a nebo jste to vy sám?V tom kolik to stojí peněz? Nebo kam míří ta otázka?
Zobrazování se obecně testuje špatně, protože počítač neumí rozlišit jestli je nějaký design přitažlivý natož funkční. Na druhou stranu je to jen to a nic víc - jestli se ta stránka vyrenderuje graficky dobře. Všechny funkce pod tou stránkou už podchytit testy lze. Už nemusíte manuálně testovat co se stane když někam kliknete.Pokud potřebný odkaz nebo tlačítko ve stránce je, ale nezobrazí se, je všem lidem houby platné, že automatizovaný test, který prolézá jenom HTML, na to kliknout umí.
Já myslím, že jo, a že jste to jen poslal do /dev/null, ale to není podstatné.Pokud jsem to přehlédl, tak se omlouvám. Ale opravdu si nepamatuji, že bych od vás zaznamenal popis toho, jakou výhodu váš systém přináší.
Pokud Vás to skutečně zajímá tak si můžete kdykoliv dohledat spoustu knih, diskusních skupin a blogů kde se tomu věnují do hloubky.Nemohl byste uvést nějaký konkrétní odkaz? Ani mne nenapadá, co bych měl hledat. Zřejmě se jedná o nějaký derivát průběžné/kontinuální integrace, já bych to nazval třeba absolutní kontinuální integrace nebo extrémní kontinuální integrace, ale přepdokládám, že to bude mít nějaký „oficiální“ název.
... knihovny netestujete prakticky vůbec ...Testy se dělají a priori na věci s největším rizikem chybovosti. Knihovna která má 1) svoje testy 2) jednoduché použití a 3) spoustu spokojených uživatelů, není na seznamu priorit. Je lepší se soustředit na testování mého kódu který tu knihovnu používá. Samozřejmě jsme se už několikrát spálili, a tam pak mělo smysl dopsat test, že něco funguje tak jak chceme my. Dívat se na to absolutisticky jsou podle mě zbytečně vyhozené peníze.
a spoustu dalších věcí také ne – mně z toho vychází, že automatizované testy vám pomáhají odhalit nějaké chyby, ale to, že automatizované testy projdou, ještě zdaleka neznamená, že je program funkční.Co je u Vás spousta dalších věcí? Dobře udělané automatické testy odhalí ne nějaké chyby, ale většinu chyb, které očekáváte nebo jste v minulosti evidovali. Samozřejmě 100% jistotu nikdy nezískáte ale oproti stavu bez testů máte šance výrazně ve prospěch funkčního programu. A to výrazně natolik že se řada týmů nebojí udělat potenciální release z každého zeleného buildu. A ne, tohle není slepá a bezmezná víra v zelené světýlko, je to jen velmi důkladné přehazování zátěže z lidí na stroje.
Pokud potřebný odkaz nebo tlačítko ve stránce je, ale nezobrazí se,... tak na to přijde ten kdo kontroluje tu vizuální podobu?
Nemohl byste uvést nějaký konkrétní odkaz? Ani mne nenapadá, co bych měl hledat. Zřejmě se jedná o nějaký derivát průběžné/kontinuální integrace, já bych to nazval třeba absolutní kontinuální integrace nebo extrémní kontinuální integrace, ale přepdokládám, že to bude mít nějaký „oficiální“ název.To co popisuju je prostě normální kontinuální integrace (CI). Je to součást agilního vývoje. Doporučuju si nastudovat i ostatní koncepty (nejlépe z extrémního programování, které je IMO nejdál), protože pak ty koncepty prostě do sebe zapadnou a fungujou. Pokud si náhodně vyberete jeden koncept (např. CI), tak se skutečně může stát, to co popisujete, tj., že to bude jen zdržovat. Na druhou stranu vrátit se k původní metodice se lze vždy.
Dobře udělané automatické testy odhalí ne nějaké chyby, ale většinu chyb, které očekáváte nebo jste v minulosti evidovali.Nejhorší jsou ovšem ty chyby, které neočekáváte. Příkladů chyb, které automatizované testy neodhalí, máte v této diskusi spoustu.
A to výrazně natolik že se řada týmů nebojí udělat potenciální release z každého zeleného buildu.Co znamená „potenciální release“?
A ne, tohle není slepá a bezmezná víra v zelené světýlko, je to jen velmi důkladné přehazování zátěže z lidí na stroje.Nikdo tady nerozporuje, že se mají dělat automatizované testy tam, kde to jde. Jenže takové testy otestují menší část funkcionality běžného programu, na zbytek automatizované testy prostě udělat nejdou (protože by to bylo řádově složitější, než napsat ten samotný program). Řešením není na zbytek testování se vykašlat.
... tak na to přijde ten kdo kontroluje tu vizuální podobu?Pokud to někdo dělá. Ale „ten“ asi nebude automat a nebude součástí kontinuální integrace.
To co popisuju je prostě normální kontinuální integrace (CI).Ne, to není. Kontinuální integrace dnes znamená, že se průběžně překládají a testují ucelené změny v kódu. Nikde tam není řečeno, že se má testovat každá dílčí změna (právě naopak, jako metrika se používá to, zda projde build a test, takže propagovat dílčí změnu, která něco z toho rozbije, je chyba). Zároveň nikde není řečeno, že má být jen jedna vývojová větev a že všechny změny se musí hned propagovat ostatním vývojářům. Naopak, snad každý popis CI popisuje, jak změny v kódu postupně probublávají do vyšších a vyšších repository, takže se postupně, s tím jak jsou víc a víc testovány, dostávají k širšímu okruhu vývojářů.
Co znamená „potenciální release“?To je to, že aby z toho byl skutečný release je už jen formalita (např. změna čísla verze nebo nahrání na web).
Jenže takové testy otestují menší část funkcionality běžného programu, na zbytek automatizované testy prostě udělat nejdou (protože by to bylo řádově složitější, než napsat ten samotný program)Klíčová je architektura programu. Programy napsané bez testů se obecně testují podstatně hůř. Ale i tam se vyplatí postupně zavést testy a tím zároveň prospět té architektuře. Programy vyvíjené paralelně s testy žádným řádovým rozdílem ve složitosti netrpí.
Ne, to není. Kontinuální integrace dnes znamená, že se průběžně překládají a testují ucelené změny v kódu. Nikde tam není řečeno, že se má testovat každá dílčí změna (právě naopak, jako metrika se používá to, zda projde build a test, takže propagovat dílčí změnu, která něco z toho rozbije, je chyba). Zároveň nikde není řečeno, že má být jen jedna vývojová větev a že všechny změny se musí hned propagovat ostatním vývojářům. Naopak, snad každý popis CI popisuje, jak změny v kódu postupně probublávají do vyšších a vyšších repository, takže se postupně, s tím jak jsou víc a víc testovány, dostávají k širšímu okruhu vývojářů.Kde jste takový popis vyhrabal? Když si dám do googlu continuous integration, tak 1. odkaz vede na stránku Fowlera, který ten koncept vymyslel. A tam se píše mimo jiné: Practices of Continuous Integration: Everyone Commits To the Mainline Every Day. (A ano, to jsou ucelené změny v kódu, které nic nerozbijou.)
To je to, že aby z toho byl skutečný release je už jen formalita (např. změna čísla verze nebo nahrání na web).To vysvětluje ty programy, u kterých jsem měl pocit, že je nikdy nikdo nezkusil spustit, protože v nich nefunguje ta základní funkcionalita.
Programy vyvíjené paralelně s testy žádným řádovým rozdílem ve složitosti netrpí.Jenže vy tady popisujete testy, které by byly řádově složitější, než samotný testovaný kód.
Kde jste takový popis vyhrabal? Když si dám do googlu continuous integration, tak 1. odkaz vede na stránku Fowlera, který ten koncept vymyslel.Podívejte se také na rok. Když se vymezuje proti způsobům práce, kde se vůbec nepoužívá VCS nebo se nepoužívá ke každodenní správě kódu, jako nejnovější hit vyzdvihuje SVN, samozřejmě píše s určitými akcenty, které ale nemůžete bezmyšlenkovitě aplikovat na dnešní odlišné technologie.
To vysvětluje ty programy, u kterých jsem měl pocit, že je nikdy nikdo nezkusil spustit, protože v nich nefunguje ta základní funkcionalita.Ty jsou na opačném konci spektra.
Jenže vy tady popisujete testy, které by byly řádově složitější, než samotný testovaný kód.Který konkrétně?
Podívejte se také na rok. Když se vymezuje proti způsobům práce, kde se vůbec nepoužívá VCS nebo se nepoužívá ke každodenní správě kódu, jako nejnovější hit vyzdvihuje SVN, samozřejmě píše s určitými akcenty, které ale nemůžete bezmyšlenkovitě aplikovat na dnešní odlišné technologie.Technologie je jen nástroj, Git neudělá za vás kvalitní software. Je mnoho diskusí a článků, včetně od téhož autora, které adresují změnu technologie, ale závěr je všude stejný. CI funguje krásně i s DVCS (navíc si můžete vzít bonusy jako lokální commity, interaktivní rebase, lepší sledování historie atp.) a převyšuje hodnotu používání DVCS bez CI. Je to jen obměna starého známého faktu, že dokonalejší metodika je na tom řádově lépe než dokonalejší technologie.
Ale když DVCS odstraní některé nedostatky, jako je obtížné vytváření a slučování větví, není důvod tyhle nedostatky dál zachovávat administrativním opatřením.Jenže CI neodstraňuje problémy spojené s aktem vytváření a slučování větví (typu: hehehe, SVN neumí dělat xyz) ale problémy spojené s odděleným vývojem ve větvích. DVCS zjednodušuje maximálně technické nároky na vytvoření a sloučení větve a zmenšuje počet konfliktů ve zdrojovém textu. Zbylé problémy, které jsou mnohem závažnější a hůře řešitelné, zůstávají i u distribuovaných větví.
Mimochodem, když nebudete Martina Fowlera číst doslova, když popisuje, jak se něco má dělat, ale budete přemýšlet nad tím, proč se to tak má dělat...To je vtipné... opravdu.
Je to takové vymezení proti způsobu z dřívějších dob, kdy byl strojový čas mnohem dražší, a když programátor odevzdával práci, mělo to být celé hotové, nepočítalo se, že se to ještě nějak bude testovat atd.Ne, je to vymezení proti způsobu z dřívějších dob, kdy se počítalo s tím, že po odevzdání se to bude ještě nespecifikovaně dlouho integrovat a testovat. Což je choroba projektů s oddělenými větvemi a očividně ne moc dobrý obchodní model.
A přesně v tomhle směru dál pokračují DVCS – můžete s ostatními klidně sdílet kód, který ani nejde přeložit, můžete snadno něco zkusit a pak to vrátit zpět, nebo si tu změnu odložit stranou, můžete si něco napsat a nechat si to sbuildovat se zbytkem aplikace a nasadit na server, a přitom vůbec nemusíte mít strach, že tím ovlivníte někoho jiného, přerušíte jeho práci. Nemusíte se bát sdílet kód, protože víte, že nasdílením kód nikomu nenutíte, jenom jej nabízíte.Všechny tyhle věci jdou dělat i v SVN, nebo dalších centrálních VCS. A já, ač používám Git každý den, nemám potřebu ani jedno z toho dělat.
Jenže CI neodstraňuje problémy spojené s aktem vytváření a slučování větví (typu: hehehe, SVN neumí dělat xyz) ale problémy spojené s odděleným vývojem ve větvích.Neodstraňuje. Pomůckou vám budiž to, že vývoj ve větvích, jak jej známe díky DVCS dnes, v době, kdy text Martin Fowler psal, neexistoval – takže těžko mohl formulovat, jak odstranit problémy z něj plynoucí. Dnes už sice vývoj s DVCS známe, ale vámi popisované problémy neexistují ani tak.
Zbylé problémy, které jsou mnohem závažnější a hůře řešitelné, zůstávají i u distribuovaných větví.Zbylé problémy jsou ovšem váš specifický případ, nikdo jiný se s nimi nikdy nesetkal.
Ne, je to vymezení proti způsobu z dřívějších dob, kdy se počítalo s tím, že po odevzdání se to bude ještě nespecifikovaně dlouho integrovat a testovatKdyž jste měl na sálovém počítači jasně vymezené svoje okénko, musel jste mít sadu děrných štítků integrovanou a otestovanou před jeho začátkem. Když tam byla chyba, měl jste prostě smůlu a přidělený čas nijak nevyužil. Od té doby cena za chybu během vývoje neustále zlevňuje, tj. jsou stále nižší požadavky na to, aby kód byl bezchybný v libovolném stadiu vývoje. Vy ale vycházíte z toho, že minima ceny už se dosáhlo a směr se obrátil – kdy k tomu podle vás došlo?
Což je choroba projektů s oddělenými větvemiChoroba, která si nijak negativně neprojevuje, mi vůbec nevadí.
Všechny tyhle věci jdou dělat i v SVN, nebo dalších centrálních VCS.Jde, ale pracně. Fowler ale psal o tom, že si máte připravit takové vývojové prostředí, aby vám tohle šlo snadno, aby se toho nikdo nebál a tím pádem aby se to hodně používalo. Protože to přispívá k rychlejšímu vývoji a kvalitnějšímu výsledku.
A já, ač používám Git každý den, nemám potřebu ani jedno z toho dělat.Spousta lidí nemá potřebu psát testy, jasně oddělit moduly nebo dokumentovat rozhraní. To ale ještě neznamená, že je to tak správně.
To je špatný předpoklad - který setrvale prezentujete - vývojář pro svou funkcionalitu potřebuje mít možnost zasahovat do celého kódu.To máš teda docela zajímavý kód. Když už tady používáme jako příklad jádro, nedovedu si představit důvod, proč by vývojář filesystému potřeboval možnost zasahovat do kódu zvukových karet.
Když už tady používáme jako příklad jádroJá ho nepoužívám, protože je to dost jiný projekt, než kterými se zabývám já.
nedovedu si představit důvod, proč by vývojář filesystému potřeboval možnost zasahovat do kódu zvukových karetNapř. změna kódu, která vyrábí soubory v /dev (/dev/dsp, ...).
Např. změna kódu, která vyrábí soubory v /dev (/dev/dsp, ...).Řekl jsem filesystémů, ne pseudofilesystémů...
No, pokud se do toho gitu JetBrains opravdu podíváte, tak zjistíte, že tam mergují o sto šestJá se dívám na 1. stranu logu community.git a nějaké divoké merge tam fakt nevidím.
Jo a k Chromiu, nepoužívat vůbec větve bylo asi tak jediné rozumné rozhodnutí, které mohli ohledně větví udělat, když používají SVNJednak tam IMHO spousta lidí používá gitsvn, a jednak proces určuje technické nástroje a né naopak. Tj. kdyby měli urgentní tlak používat hodně větvení, tak určitě po nějakém DVCS sáhnou.
v community.git je klidně i několik mergů z git@git.labs.intellij.net denně.Ano, to jsou merge mezi produkty. A fakt že je jich několik denně napovídá že tým používá systém malých změn které se často propagují.
A stránka na wiki popisující, jak na vývoj Chromia s gitem, mluví o tradičních tématických větvích. Abych citoval: The first step to contributing a patch is to write it. Create a branch and make your changes. Takže asi tak.Je rozdíl mezi procesem, který platí uvnitř vývojářského týmu a který platí pro náhodné přispěvatele. Pokud se mi snažíte vnutit myšlenku, že tyhle týmy používají interně dlouho se táhnoucí větve které mergují jednou za někdy, tak nemáte šanci uspět, protože je obecně známo, že to tak není.
protože je obecně známo, že to tak neníTady si to můžete narazit na čumák: https://docs.google.com/present/view?id=dg63dpc6_4d7vkk6ch
Na otázku Podívejte se do svn chromium, nebo do gitu jetbrains. Mají tam nějaké větve? není ne zdaleka tak jednoznačná odpověď, jak prezentujete.Tak jsem to špatně napsal no. Na otázku "používají na vývoj větve kde se něco peče dokud to není hotové nebo místo toho přispívají do často trunku ", což tady celou dobu probíráme, dává jednoznačnou odpověď např. ta prezentace.
A co se tam dostávalo ty týdny před tím?FYI: do linux-next se skládají větve, o kterých se předpokládá, že jsou připravené k začlenění do hlavní řady. Rozhodně se tam nestrkají věci, které jsou zrovna ve vývoji.
tvůj úžasný přístupJasně, můj. Jděte s tím už někam.
Chceš říct, že za tebe celou diskuzi mluvil někdo jiný?Ne, ale už jsem vypíchl rozdíl mezi tím, když se jen já o něčem se zmíním v této diskuzi a když se o něčem zmíním jen já v celém vesmíru. Vylezte z diskuze na webový vyhledávač a porozhlídněte se, jak to ve světě chodí.
Takže budou všichni čekat, až to autor opraví.No a nebo to prostě opraví ten kdo na to přijde. Závislost na tom, že frantův kód může opravovat jen franta je taky na palici. Nicméně - pokud do trunku někdo pošle něco nefunkčního tak by měl druhej den všem platit oběd nebo tak něco. Prostě s dobrou baterií testů a systémem malých změn a častých integrací se vám hned tak něco rozbít nepovede. Na to to je. Výhoda proti větvím? Jeden integrační server, každej den funkční SW, každej tejden viditelnej přírůstek funkcionality. Release je nudná událost (technicky), teoreticky můžete pak vydávat každej tejden.
Větve používáme velice intenzivně a s tebou popisovanými problémy se prostě nesetkáváme. Asi to chce jak psal ládíček skutečné programátory, kteří u své práce přemýšlí a společně chtějí mít výsledky :)Samozřejmě inteligentní lidi jsou základ a samozřejmě každej tým si najde cestu, jak netrpět, ať už používají jakoukoliv metodiku. Já si jen myslím, že noční build / demo instalaci na každou rozdělanou větev nemáte.
Právě díky větvím lze předvádět na testovacích instalacích nové věci bez toho, aby se motaly v produkčním kódu. Třeba i klientům vně firmy.
Nedovedu si představit, že by se rozdělané věci komitovaly do masteru a procházely standardních testováním pro release.Já si to dovedu představit, protože to tak dělám
a věřte že to jde, je to jen o změně pořadí jakou se ta feature vyvíjí.
Automatický build i kontrolu kódu pro každou sdílenou větev děláme v TeamCity, každý komit projde buildem i kontrolami (kontrola nových komitů přes všechny větve každých 5 minut).To máte dobré, ale IMHO zbytečně pálíte ten integrační počítač...
Spouštění, kontroly výkonnostních regresí, run testy v seleniu, generování webshotů klíčových stránek v různých prohlížečích děláme jen na masteru a stablu (opět v intervalu 5 minut).... no a tady si rejpnu, když franta v branchi provede nějakou feature, přidělá k ní pár testů, tak ty testy se pak mimo jeho osobní iniciativu na lokálním PC nikde jinde nespouští?
Právě díky větvím lze předvádět na testovacích instalacích nové věci bez toho, aby se motaly v produkčním kódu. Třeba i klientům vně firmy.No, to taky znám, ale zase - pokud se ta větev zase rychle nezavře tak je to akorát dobrej způsob jak instantně zdvojnásobit velikost podporovaného kódu.
a věřte že to jde, je to jen o změně pořadí jakou se ta feature vyvíjí.
A kolik vás na té jedné změně dělá? Jak předá javista novou featuru webaři k ostylování a doladění html bez sdílené větve a bez toho, aby se rozpracovaná věc nedostala do masteru, ze kterého se odvíjí třeba druhý den stable? Takové věci se do masteru v našem workflow NESMÍ dostávat, jinak nelze master pořádně otestovat a překlopit na stable pro produkční nasazení.
To máte dobré, ale IMHO zbytečně pálíte ten integrační počítač...
Zbytečné to není. Bohužel občas se stává, že komit není buildovatelý, obsahuje nedovolené věci (v našem případě např. UTFkové BOMko v šabloně). Taková věc se během několika minut projeví a nikoho jiného to neovlivní, protože je to ve větvi. Může se i stát, že vývojář komitne a jde domů. Druhý den ráno si to opraví a nikoho tím nezdržuje.
když franta v branchi provede nějakou feature, přidělá k ní pár testů, tak ty testy se pak mimo jeho osobní iniciativu na lokálním PC nikde jinde nespouští?
junit testy jsou součástí zdrojáků, tedy té větve a normálně se mergnou do masteru. Seleniové testy ve větvích - to zatím řešíme,ale nepředpokládám žádné problémy.
pokud se ta větev zase rychle nezavře tak je to akorát dobrej způsob jak instantně zdvojnásobit velikost podporovaného kódu.
?? Rozdíl jsou jenom ty komity ve větvi, které se liší od headu masteru. A větve samozřejmě zavíráme ihned jakmile jsou hotové. Každý týden tým otevírá i zavírá několik větví.
A kolik vás na té jedné změně dělá?Na změně může klidně dělat celej spolek (i když to se ještě nestalo - máme hodně diverzní zaměření lidí), podstatné ale je že na jedom úkolu dělá jeden až dva lidi (když dva tak spolu u PC). Ty úkoly jsou dílčí část "změny" a jejich stanovení a pořadí je právě ta "magie" jak mít každej den doděláno a v trunku všechno co se za ten den udělalo.
Bohužel občas se stává, že komit není buildovatelý, obsahuje nedovolené věci (v našem případě např. UTFkové BOMko v šabloně). Taková věc se během několika minut projeví a nikoho jiného to neovlivní, protože je to ve větvi. Může se i stát, že vývojář komitne a jde domů. Druhý den ráno si to opraví a nikoho tím nezdržuje.Tohle by právě měl vychytat, než commitne a odejde. Pokud commitne a všem to rozbije tak nastává varianta viz výše. Konkrétně já nejprv dělám pull/rebase, pak spouštím fast testy u sebe, pak commitnu, pak odkliknu Run v teamcity, kde to trvá asi 20 minut (s tím ještě něco uděláme), takže můžu jít na kafe, počkám na zelenou a až pak jdu na další úkol nebo domů. Samozřejmě už se párkrát stalo, že místo zelené je červená, pak holt musím řešit nebo revertovat.
Jak předá javista novou featuru webaři k ostylování a doladění html bez sdílené větve a bez toho, aby se rozpracovaná věc nedostala do masteru, ze kterého se odvíjí třeba druhý den stable? Takové věci se do masteru v našem workflow NESMÍ dostávat, jinak nelze master pořádně otestovat a překlopit na stable pro produkční nasazení.V HTML se udělá šablona, na kterou se navěsí prázdná implementace. Např. na stránce měl být obrázek, tak se nejprv udělala stránka ve správném stylu a obrázek byl mock. Pak se udělal obrázek dynamicky generovaný. Webař a javista dokonce můžou pracovat paralelně, pokud se dohodnou na tom rozhraní. U nás to byl ten samý člověk, ale i tak dodržením tohoto postupu se daly jednotlivé věci řešit a hodnotit zvlášť. Mě by spíš zajímalo proč váš workflow zakazuje poslat něco takového do masteru, protože jinak ho nelze pořádně otestovat. Spíš mi přijde, že když některé testy máte jen nad masterem, tak se spíš otestuje všechno nové, když to přijde do masteru co nejdřív.
A větve samozřejmě zavíráme ihned jakmile jsou hotové. Každý týden tým otevírá i zavírá několik větví.No to je fajn... nejste ani jeden extrém - ani patologický případ půlročních větví ani nejdete bezkompromisně po efektivitě procesu - nějak vám to funguje tak ať se daří :)
V HTML se udělá šablona, na kterou se navěsí prázdná implementace. Např. na stránce měl být obrázek, tak se nejprv udělala stránka ve správném stylu a obrázek byl mock.
Pokud tohle commitnete, tak jste do masteru zamerne dostal nefukcni kod, ktery tam nema co delat. Pak si to nekdo pretahne k sobe (nebo nedejboze preklopi do ostreho provozu) a bude dumat nad tim, proc ten obrazek neukazuje to, co by mel ukazovat, a proc to tlacitko "Odeslat" po kliknuti neudela lautr nic, pripadne vyhodi chybu.
Pokud tohle commitnete, tak jste do masteru zamerne dostal nefukcni kod, ktery tam nema co delat.Myslím že jste nečetl těch 50+ příspěvků nahoře, tak vám to zrekapituluju: kód může být funkcionálně nekompletní, ale musí být technicky v pořádku. Ten mock je technicky v pořádku a tím, že je v masteru co nejdřív, tak s ním můžou další lidi pracovat dál (např. už na jeho místo nepřeteče tabulka kterou dělá někdo jiný atd.) Pokud se do nejbližší release stihne obrázek funkcionálně dokončit, tak se nic neděje, pokud ne, může se buď ta stránka znepřístupnit (např. na ni nevede link), nebo se může prezentovat jako pre view a získat zpětnou vazbu od zákazníka.
bude dumat nad tim, proc ten obrazek neukazuje to, co by mel ukazovat, a proc to tlacitko "Odeslat" po kliknuti neudela lautr nic, pripadne vyhodi chybu.Myslím že na hlášce "tato funkce není zatím implementována" nebo na jasném nadpisu "mock" přes obrázek není nic, nad čím by se dalo dlouze dumat.
Ale cetl a vas problem je, ze jste tak dlouho prchal pred jednim extremem, az jste spadl do druheho. Do masteru se davaji funkcionalne kompletni celky, ty jak vy rikate technologicky v poradku (aka jde to zkompilovat / nehazi to parse error) musi jit do samostatne vetve dokud funkcionalne kompletni celek nevytvori.
Vasim ukolem je rozdelit praci na tak male funkcni celky, ze se daji nakodovat do tech dvou dnu (s tim, ze cas od casu to proste za min jak tyden neudelate). Pokud nutite programatory tlacit do mastru nedodelky, ke kterym, jako prace navic, je nutne dobastlit docasne workaroundy aby to nepadalo pri kazdem kliknuti, a skutecne funkcni vysledek bez mocku a obrazovek s napisem "na tom tedkonc dela franta, nesahat!!!" mate az za ctrnact dni, tak to delate spatne.
Ale cetl a vas problem je, ze jste tak dlouho prchal pred jednim extremem, az jste spadl do druheho.Stát si za svým názorem (pořád tím samým) a odporovat neutichajícímu proudu argumentů, může sice být považováno za extrémní, ale v tom případě jsem rád, že jsem extrémní. Na druhou stranu na tom co prezentuju nic extrémního není.
Do masteru se davaji funkcionalne kompletni celky, ty jak vy rikate technologicky v poradku (aka jde to zkompilovat / nehazi to parse error) musi jit do samostatne vetve dokud funkcionalne kompletni celek nevytvori.Tohle je právě názor, který do té metodiky nepatří.
obrazovek s napisem "na tom tedkonc dela franta, nesahat!!!"To taky ne, protože to vede k uzamčení feature u franty na neomezenou dobu. Je to přesně naopak - dneska na tom udělá něco franta a zejtra může další kus dodělat honza.
dobastlit docasne workaroundy aby to nepadalo pri kazdem kliknuti,A alternativa je co, program který padá při každém kliknutí až dokud není hotový za dva týdny? To je metoda všechno nebo nic.
Je to přesně naopak - dneska na tom udělá něco franta a zejtra může další kus dodělat honza.na to by se nádherně hodila ta větev, kde můžou franta s honzou tvořit nerušeně, nezabijou půl pracovní doby řešením toho, aby se na stránku nedalo prokliknout a aby mohla bejt nasazená už dnes. Já si nedovedu přestavit jak to řešíte (a ano, četl jsem celou diskuzi). To je pak produkční kód zaplevelenej věcma jako if(frantovo_stroj) then novy_kosik.php else stary_kosik.php ?
na to by se nádherně hodila ta větev, kde můžou franta s honzou tvořit nerušeně, nezabijou půl pracovní doby řešením toho, aby se na stránku nedalo prokliknout a aby mohla bejt nasazená už dnes. Já si nedovedu přestavit jak to řešíte (a ano, četl jsem celou diskuzi).Značně zkreslujete proporce diskutované věci. Naplánovat si práci na dnes tak, aby po mě večer zbyl funkční blok, ke kterému se nemusím vracet (v rámci nejlepšího vědomí/svědomí které mám o řešeném problému), to nestojí víc než 10 minut zamyšlení nad pořadím činnosti, které provedete třeba cestou do práce, nebo nad papírem jako prvních 10 minut v práci.
To je pak produkční kód zaplevelenej věcma jako if(frantovo_stroj) then novy_kosik.php else stary_kosik.phpTo samozřejmě ne, ... na PC vývojáře by program neměl záviset. Řešení tohohle se může lišit podle toho co se děje za změny, jak dlouho vyvíjíte nový košík, komu ho chcete ukazovat atd. Pokud do košíku přidáváte něco malého co stihnete pravděpodobně dokódovat do nejbližší release, tak prostě nejdřív přidáte třeba GUI elementy, a pak dokódujete aplikační logiku. Dělá se to v tomto pořadí, protože potřebujete GUI přizpůsobit uživateli a pak logiku přizpůsobit GUI, nikoliv uživatele přizpůsobovat vnitřní architektuře systému. Na začátku v tom GUI může bejt mock, nebo prázdná implementace, to přece nestojí víc než těch pár minut. Pokud se ta feature dělá déle a chcete to mít systémem všechno nebo nic (což leckdy není nutné) tak tam dáte if(nabidni_novou_feature) then ... s tím, že defaultně to máte zaplé a při výrobě releasu kde to nechcete se to vypne. Pokud něco přepisujete z gruntu, tak můžete uživatelům nabízet obě verze - "vyzkoušejte novou verzi košíku"... a nebo to řešit tím ifem. Každopádně když se nad tím zamyslíte tak ani jedno nějak extra technicky náročné není, je to jen o pohledu na věc.
Naplánovat si práci na dnes tak, aby po mě večer zbyl funkční blok, ke kterému se nemusím vracet (v rámci nejlepšího vědomí/svědomí které mám o řešeném problému), to nestojí víc než 10 minut zamyšlení nad pořadím činnosti, které provedete třeba cestou do práce, nebo nad papírem jako prvních 10 minut v práci.Mohl byste nám všem tady ukázat na čem děláte? Já si nedovedu představit, že dělám na něčem větším ,než je změna obrázků a tlačítek, jak pořád zmiňujete, a dovedu to dokončit tentýž den. Zásahy v datovém modelu, architektuře, ale i značné přepsání starého kódu se za den udělat nedá.
Pokud se ta feature dělá déle a chcete to mít systémem všechno nebo nic (což leckdy není nutné) tak tam dáte if(nabidni_novou_feature) then ... s tím, že defaultně to máte zaplé a při výrobě releasu kde to nechcete se to vypne.Aha, takže kód je zkutečně zaplevelený ifama. Co Vám na to říkají kolegové, když se prokopávají tunou ifů a hledají kudy zrovna ten program běží? Co když děláte dva vývojáři na dvou nezávislých věcech v tomtýž kódu? To tam pak máte ty ify vnořené?
Pokud něco přepisujete z gruntu, tak můžete uživatelům nabízet obě verze - "vyzkoušejte novou verzi košíku"... a nebo to řešit tím ifem.Kdybych uživatelům pořád někde zobrazoval "vyzkoušejte naší novou a velmi nestabilní verzi", tak bych byl asi brzo bez uživatelů. A dost možná i bez práce...
Zásahy v datovém modelu, architektuře, ale i značné přepsání starého kódu se za den udělat nedá.Ne, ale vždy si můžete naplánovat práci tak, že každý den něco doděláte tak, že už se k tomu nemusíte vracet. Místo toho, že se na 2 týdny zašijete někam do kouta a přepíšete vše z gruntu, tak se dá udělat to, že přepisujete věci po jednodenních kvantech. Viz můj příklad s přechodem na jinou db.
Aha, takže kód je zkutečně zaplevelený ifama. Co Vám na to říkají kolegové, když se prokopávají tunou ifů a hledají kudy zrovna ten program běží? Co když děláte dva vývojáři na dvou nezávislých věcech v tomtýž kódu? To tam pak máte ty ify vnořené?Co Vám mám na to říct? Vzal jste nějaký krajní případ a ten jste přetáhl ad absurdum. Vždyť Vám musí být jasné, že to je ptákovina, a po chvíli uvažování správným směrem se lze dopátrat i řešení které funguje.
"vyzkoušejte naší novou a velmi nestabilní verzi"A opět -- nikdy jsem neřekl, že nová verze je nestabilní, spíš právě naopak.
a nevidím žádný důvod, proč bych si tím měl přidělávat práci... protože A) té práce tolik není (nenaplánoval jste si to dobře, pokud je) a B) tím že na tom teď ušetříte X času, tak někdy v budoucnu někdo další (nebo i Vy) bude mít o Y>>X práce navíc (což ale teď nevidíte, takže si myslíte, že odebráním X šetříte).
... větev. Od toho jsouTady je docela pěkný článek který pojednává o výhodách a nevýhodách větví v různých situacích.
Asi něco musíme dělat hodně špatně :)Což je ...ehm... "krajně nepravděpodobné"? Tomu říkám sebereflexe. :) A teď vážně. Pouze používáte metodiku které větve nevadí. Ta metodika není špatná, ale pro týmy Vaší velikosti je obvykle málo efektivní.
Ne, je to vymezení proti způsobu z dřívějších dob, kdy se počítalo s tím, že po odevzdání se to bude ještě nespecifikovaně dlouho integrovat a testovat. Což je choroba projektů s oddělenými větvemi a očividně ne moc dobrý obchodní model.Normální přístup s DVCS: několik lidí něco vyvíjí po dobu T1 (každý svoje, zpřístupní to ostatním, ale nenutí jim to tlačením do master větve.) Pak mají hotovo, tak se to spojí a čas T2 se tráví integrací a testováním. Tvůj úžasný přístup (a tvůj proto, že ho tady nikdo jiný nehájí): vyvíjíš, ejhle, bude polovina pracovní doby, honem začleňovat. Strávíš tedy čas integrací (+ testováním), začleníš, následně kolegové tráví čas reakcí na tvoje změny. Odpoledne přijdeš na to, že je v tom ranním kódu potřeba něco více či méně překopat. Čas trávený intergrací a testováním dopoledne je přinejmenším zčásti ztracený - jak tvůj, tak tvých kolegů, všichni jste pracovali kvůli kódu, který ve výsledném SW vůbec nebude. Opravdu si myslíš, že i s takovým vyhazováním času z okna budeš schopen dodat funkční výsledek za dobu menší než T1 + T2? To sotva. O tom, že master větev bude vypadat, jako by na ní pracovala banda prasopsů, ani nemluvím. Jen tak mimochodem, pochlubíš se nám, která firma se užíví takto úžasným způsobem práce?
.ds_odsazeni { min-width: 35em; background-color: #fff; }
Reakce na #143 (už mě ten štrůdl nahoře nebaví)Tak já sem tedy přestěhuji i odpověď na komentář FJ. Ono je to obsahově více méně to samé.
vámi popisované problémy neexistují / nikdo jiný se s nimi nikdy nesetkalPokud to neznáte vy, tak je to vaše věc, ale při tvrzení, že nikdo a nikdy a neexistuje si myslím že jste trochu ujel.
Když jste měl na sálovém počítači jasně vymezené svoje okénko, musel jste mít sadu děrných štítků integrovanou a otestovanou před jeho začátkem. Když tam byla chyba, měl jste prostě smůlu a přidělený čas nijak nevyužil. Od té doby cena za chybu během vývoje neustále zlevňuje, tj. jsou stále nižší požadavky na to, aby kód byl bezchybný v libovolném stadiu vývoje. Vy ale vycházíte z toho, že minima ceny už se dosáhlo a směr se obrátil – kdy k tomu podle vás došlo?Cena za chybu se nezlevňuje. Cena za chybu je funkce silně závislá na čase mezi jejím vyrobením a opravením. A s tím časem lze pracovat. V dobách štítků to bylo dlouho pro ty důvody které popisujete. A ještě dnes je např. rozdíl mezi tím, když si spustíte kompilaci z příkazové řádky a čekáte na zapomenuté středníky, a tím když to IDE automaticky podtrhne červeně. Programátor pracující s IDE opraví syntaktickou chybu rychleji než programátor pracující s editorem a překladačem. Aplikací stejného principu týmy pracující s CI opraví chyby v programu rychleji než týmy pracující s feature větvemi.
Tvůj úžasný přístup (a tvůj proto, že ho tady nikdo jiný nehájí)Což mě nepřekvapuje a nevadí mi to.
Normální přístup s DVCS: několik lidí něco vyvíjí po dobu T1 (každý svoje, zpřístupní to ostatním, ale nenutí jim to tlačením do master větve.) Pak mají hotovo, tak se to spojí a čas T2 se tráví integrací a testováním.Rozdělit čas na T1 vývoj a T2 testování znamená že do konce T2 nebudu vědět jestli práce v T1 za něco stojí. Co když na začátku T1 udělám chybný předpoklad a na tom postavím celou další práci? To je extrémní případ, ale ukazuje, jak je důležité odhalit co nejvíc problémů co nejdřív.
vyvíjíš, ejhle, bude polovina pracovní doby, honem začleňovat. Strávíš tedy čas integrací (+ testováním), začleníš, následně kolegové tráví čas reakcí na tvoje změny. Odpoledne přijdeš na to, že je v tom ranním kódu potřeba něco více či méně překopat. Čas trávený intergrací a testováním dopoledne je přinejmenším zčásti ztracený - jak tvůj, tak tvých kolegů, všichni jste pracovali kvůli kódu, který ve výsledném SW vůbec nebude.Výhoda toho "mého" přístupu je, že eliminuje všechy složky, které vám běžně působí problém. A sice "ejhle", "honem", "trávíš čas" (ve smyslu čekáš/vyčerpáváš se) a "překopat". A to právě proto, že je to nastavené tak, aby se tyhle věci nestihly vyvinout a nabobtnat.
Opravdu si myslíš, že i s takovým vyhazováním času z okna budeš schopen dodat funkční výsledek za dobu menší než T1 + T2? To sotva. O tom, že master větev bude vypadat, jako by na ní pracovala banda prasopsů, ani nemluvím.Ano čas je kratší, výsledek je funkční (opravdu funkční) a master větev obsahuje až na silné výjimky jen přechody z jednoho zeleného stavu do druhého. A zelený stav znamená, že všechno funguje od začátku až do konce.
Jen tak mimochodem, pochlubíš se nám, která firma se užíví takto úžasným způsobem práce?Citace z isbn 0596527679: CHAPTER 1 Why Agile? Agile development is popular. All the cool kids are doing it: Google, Yahoo, Symantec, Microsoft, and the list goes on.
Pokud to neznáte vy, tak je to vaše věc, ale při tvrzení, že nikdo a nikdy a neexistuje si myslím že jste trochu ujel.Už jenom samotný fakt, že drtivá většina takové problémy nemá, svědčí o tom, že vámi popisované problémy nejsou způsobeny použitou technologií a organizací práce, ale něčím jiným. „Nikdo a nikdy“ je jenom takový hovorový výraz, který se často používá i v případě, že se najde pár výjimek. Vy byste se ale spíš měl zabývat rozporem, že tvrdíte, že něco způsobuje problémy, a většina uživatelů se s takovým problémem nesetkala.
Cena za chybu se nezlevňuje.Cena za chybu při vývoji samozřejmě zlevňuje. Dříve jste musel přelepovat dirku nebo rovnou vyhodit celý štítek, přišel jste o drahocenný strojový čas – dneska zmáčknete delete nebo za minutu spustíte kompilaci znova. To je výrazné zlevnění.
Cena za chybu je funkce silně závislá na čase mezi jejím vyrobením a opravením. A s tím časem lze pracovat. V dobách štítků to bylo dlouho pro ty důvody které popisujete. A ještě dnes je např. rozdíl mezi tím, když si spustíte kompilaci z příkazové řádky a čekáte na zapomenuté středníky, a tím když to IDE automaticky podtrhne červeně. Programátor pracující s IDE opraví syntaktickou chybu rychleji než programátor pracující s editorem a překladačem. Aplikací stejného principu týmy pracující s CI opraví chyby v programu rychleji než týmy pracující s feature větvemi.Nepřipadá vám to divné? Uvedete X příkladů, které programátorovi usnadňují práci a nenutí ho udělat to hned na první pokus správně, a nakonec k tomu přiřadíte pravý opak, který programátorovi práci přidělává a nutí ho vše dělat „na první dobrou“. To se k sobě moc nehodí…
Rozdělit čas na T1 vývoj a T2 testování znamená že do konce T2 nebudu vědět jestli práce v T1 za něco stojí. Co když na začátku T1 udělám chybný předpoklad a na tom postavím celou další práci? To je extrémní případ, ale ukazuje, jak je důležité odhalit co nejvíc problémů co nejdřív.Proto se běžně vývoj a testování prolíná. Jenže k tomu je potřeba klid, nemůžete vyvíjet a testovat, když vám zároveň pořád přicházejí změny a chyby od někoho jiného.
Výhoda toho "mého" přístupu je, že eliminuje všechy složky, které vám běžně působí problém. A sice "ejhle", "honem", "trávíš čas" (ve smyslu čekáš/vyčerpáváš se) a "překopat". A to právě proto, že je to nastavené tak, aby se tyhle věci nestihly vyvinout a nabobtnat. … Ano čas je kratší, výsledek je funkčníChápal bych to tak, že pro samou integraci s kódem, který se nikdy nepoužije, už vám nezbývá žádný čas na vývoj. Ale tak jste to asi nemyslel. Zajímalo by mne, jak tím, že někomu zkrátíte čas na vývoj, docílíte toho, aby nedělal chyby a navrhl vše rovnou správně. Proč se ta vaše metoda nepoužívá třeba ve výrobě? Vyrábíte jeden výrobek 3 dny a občas stejně vyrobíte zmetek? Od teď to musíte stihnout za 4 hodiny, a uvidíte, že zmetky už nebudou… Já bych na to tedy nevsadil ani korunu.
CHAPTER 1 Why Agile? Agile development is popular. All the cool kids are doing it: Google, Yahoo, Symantec, Microsoft, and the list goes on.Nás nezajímá, kdo používá úplně jiné metody vývoje, než vy. Nás by zajímal někdo, kdo používá tu vaši metodu „čím méně času, tím lepší výsledek“. Až budete mít někdy hodně klidnou náladu a jen tak něco vás nevyvede z míry, přečtěte si o tom, jak Microsoft vyvíjí Windows, a jak trvá týdny, než kód od programátora přes různé větve probublá do masteru.
drtivá většinaTj. všech pět co vede se mnou tuhle diskusi?
Dříve jste musel přelepovat dirku nebo rovnou vyhodit celý štítek, přišel jste o drahocenný strojový čas – dneska zmáčknete delete nebo za minutu spustíte kompilaci znova.A podívejte se pořádně co říkáte. Je to o čase než se chyba opraví, a v tom je ta cena.
Nepřipadá vám to divné? Uvedete X příkladů, které programátorovi usnadňují práci a nenutí ho udělat to hned na první pokus správně, a nakonec k tomu přiřadíte pravý opak, který programátorovi práci přidělává a nutí ho vše dělat „na první dobrou“.V tom co říkám já, žádný rozpor není. Vaše interpretace je špatná.
Proto se běžně vývoj a testování prolíná.Pokud se vývoj a testování prolíná není důvod otestovaný kus vývoje šmudlat po šuplíkách, ale můžete ten kus rovnou odevzdat.
Jenže k tomu je potřeba klid, nemůžete vyvíjet a testovat, když vám zároveň pořád přicházejí změny a chyby od někoho jiného.Tímhle jen říkáte, že integrace s dalším kódem nemusí být bezproblémová. Ale nějakou magií pokud jí odložím o týden, tak to bezproblémové bude?
Proč se ta vaše metoda nepoužívá třeba ve výrobě? Vyrábíte jeden výrobek 3 dny a občas stejně vyrobíte zmetek? Od teď to musíte stihnout za 4 hodiny, a uvidíte, že zmetky už nebudou…Je rozdíl stihnout třídenní práci za 4 hodiny a je rozdíl stihnout třídenní práci za tři dny, ale dělat každé 4 hodiny kontrolu jakosti a postupu k cíli. Ve skutečnosti se kontroly ve výrobě dělají často, protože nechcete, aby se vadná součástka začlenila do výrobku a přišlo se na to až když si ho někdo koupí.
Nás nezajímá, kdo používá úplně jiné metody vývoje, než vy.Já používám (mimo jiné) CI, což je součást agilní metodiky. Jak jste přišel na to, že je to něco jiného, než agilní metodika?
přečtěte si o tom, jak Microsoft vyvíjí Windows, a jak trvá týdny, než kód od programátora přes různé větve probublá do masteruJdeme zase k debatě o způsobu vývoje OS? Vyvíjíte snad OS? Microsoft není jen Windows. Microsoft agilní metodiky používá a dokonce se jim to líbí tak, že si dají práci s tím, aby ty metodiky adaptovali na svoje celosvětové týmy.
Tj. všech pět co vede se mnou tuhle diskusi?I pět proti jednomu je drtivá většina.
A podívejte se pořádně co říkáte. Je to o čase než se chyba opraví, a v tom je ta cena.Zapomínáte k tomu ještě připočítat čas, kdy se změna projeví. Každopádně stisknutí klávesy delete trvá i s rezervou vteřinu, nové vyděrování a čekání na přidělený strojový čas dny nebo týdny.
Pokud se vývoj a testování prolíná není důvod otestovaný kus vývoje šmudlat po šuplíkách, ale můžete ten kus rovnou odevzdat.O tom píšu celou dobu. Odevzdává se, když je práce hotová, ne když zazvoní minutka.
Tímhle jen říkáte, že integrace s dalším kódem nemusí být bezproblémová. Ale nějakou magií pokud jí odložím o týden, tak to bezproblémové bude?Ano, bude. Buď vyvíjíte a integrujete najednou, nebo postupně. V tom je podstatný rozdíl. Když budete vařit oběd a opravovat auto, také vám to půjde daleko lépe, když to budete dělat postupně, než když se to pokusíte udělat najednou.
Ve skutečnosti se kontroly ve výrobě dělají často, protože nechcete, aby se vadná součástka začlenila do výrobku a přišlo se na to až když si ho někdo koupí.ve skutečnosti se kontroly ve výrobě dělají podle postupu výroby, a ne podle času. Když budete dělat kontroly podle času, docílíte jen toho, že se těsně před kontrolou bude fixlovat, aby výrobek kontrolou prošel – pokud bude pozadu oproti plánu, bude se fixlovat, že už výroba postoupila, pokud bude napřed, bude se fixlovat, že na něm další kroky ještě nebyly udělány. To fixlování je ovšem jen ztráta času, potenciální zdroj chyb a dané testy jsou k ničemu (zjistíte z nich akorát to, jak dobře to někdo nafixloval). Stejné je to i u programování. Můžete nutit programátory, aby každé čtyři hodiny nafixlovali, že kód projde testy. Ale je to kontraproduktivní.
Já používám (mimo jiné) CI, což je součást agilní metodiky. Jak jste přišel na to, že je to něco jiného, než agilní metodika?Vy používáte svůj vlastní postup, který chybně nazýváte CI. Váš postup není agilní metodika, protože ho nikdo jiný, než vy, k agilním metodikám neřadí, a protože je postaven na přesně opačných principech, než agilní metodiky.
Microsoft agilní metodiky používáTo nepopírám. Jenom jsem nikdy neslyšel nic o tom, že by používal vaši metodiku, ale zaznamenal jsem, že používá metodiku právě opačnou, o které vy prohlašujete, že nefunguje.
O tom píšu celou dobu. Odevzdává se, když je práce hotová, ne když zazvoní minutka.Proti tomu já nic nemám. Akorát si plánuju práci tak, že ji mám hotovou a můžu odevzdávat průběžně po 1 dni. (Celá debata se pak strhla ve smyslu, že takhle se práce plánovat nedá, ale ona se tak plánovat dá.)
Když budete vařit oběd a opravovat auto, také vám to půjde daleko lépe, když to budete dělat postupně, než když se to pokusíte udělat najednou.Když budete programovat a vařit oběd tak budou platit stejné principy.
Můžete nutit programátory, aby každé čtyři hodiny nafixlovali, že kód projde testy. Ale je to kontraproduktivní.O nucení to není.
Vy používáte svůj vlastní postup, který chybně nazýváte CI. Váš postup není agilní metodika, protože ho nikdo jiný, než vy, k agilním metodikám neřadí, a protože je postaven na přesně opačných principech, než agilní metodiky.A v čem se konkrétně liším?
Proti tomu já nic nemám. Akorát si plánuju práci tak, že ji mám hotovou a můžu odevzdávat průběžně po 1 dni. (Celá debata se pak strhla ve smyslu, že takhle se práce plánovat nedá, ale ona se tak plánovat dá.)Pro mne je práce hotová, když je hotový nějaký smysluplný celek. Pro vás je asi hotová tehdy, když projde kompilace a testy.
Agilní metodiky se nesnaží zamaskovat, že vývojáři dělají chyby, že se mění požadavky na software nebo že se software postupně vyvíjí. Přistupují k tomu opačně, např. když už tedy programátor dělá chyby, tak se udělají taková opatření, aby se na ty chyby co nejrychleji přišlo, aby jejich oprava byla snadná, aby ovlivnily co nejméně ostatních programátorů a kódu. Vy k tomu přistupujete přesně opačně, chyba během vývoje je pro vás obrovský problém, takže vaši programátoři se logicky nebudou soustředit na to, aby výsledný produkt obsahoval co nejméně chyb, ale na to, aby bylo co nejméně chyb během vývoje. Když to přeženu, je jedno, zda bude výsledný program fungovat, ale hlavně aby se nikdy nespustil kompilátor nad zdrojákem, ve kterém chybí středník. Dobře je to vidět na příkladech, kde jste popisoval plánování své práce. Rozdělíte ji na části, které sami o sobě nedávají žádný smysl a výsledek té práce se nepoužívá. Díky tomu vám pak prochází testy a vy jste spokojen. To je ale přesný opak toho, o co se snaží CI. CI znamená, že se snažíte funkční kód co nejrychleji začít používat; vy místo toho kód složitě upravujete, aby se nepoužíval, a pak jej co nejrychleji dáte do VCS. Ke skutečné integraci (ne kódu, ale funkcionality) pak dojde až po několika dnech, když skončíte práci – jenže při skutečné CI už by ten kód dávno někdo používal.Vy používáte svůj vlastní postup, který chybně nazýváte CI. Váš postup není agilní metodika, protože ho nikdo jiný, než vy, k agilním metodikám neřadí, a protože je postaven na přesně opačných principech, než agilní metodiky.A v čem se konkrétně liším?
Pro mne je práce hotová, když je hotový nějaký smysluplný celek. Pro vás je asi hotová tehdy, když projde kompilace a testy.A smysluplný celek i s testy jde udělat za jeden den.
Vy k tomu přistupujete přesně opačně, chyba během vývoje je pro vás obrovský problém, takže vaši programátoři se logicky nebudou soustředit na to, aby výsledný produkt obsahoval co nejméně chyb, ale na to, aby bylo co nejméně chyb během vývoje.Chyba během vývoje je levnější než chyba během nasazení a používání někde kam se musí jet přes hory a doly. Většinu chyb se snažíme najít při vývoji a vyřešit je. Není pravda, že by měly být "obrovský problém" a nerozumím tomu, proč je to podle vás "přesně opačně", než "mít opatření aby se na chyby co nejrychleji přišlo". Byl jste to vy, kdo "co nejrychleji" považoval za nemístné. Tvrdil jste, že chyba, kterou dostanete na stůl co nejrychleji vás obtěžuje a zdržuje od vašeho poklidného vývoje v koutě.
Rozdělíte ji na části, které sami o sobě nedávají žádný smysl a výsledek té práce se nepoužívá. Díky tomu vám pak prochází testy a vy jste spokojen.Jestli něco nedává smysl tak je to vaše představa že sedím nad programem který nic nedělá, nad testy které nic netestují, a dostávám za to peníze.
Ke skutečné integraci (ne kódu, ale funkcionality) pak dojde až po několika dnech, když skončíte práci – jenže při skutečné CI už by ten kód dávno někdo používal.Další nesmysl. K integraci dochází každý den po takových kvantech po jakých se za ten den stihne udělat. Kód který se ten ten udělá už jede naostro. To, že se něco nedodělaného někde vypne, je praktika, která se používá až při dodání uživateli jako build nebo run time konfigurace.
A smysluplný celek i s testy jde udělat za jeden den.Nejde.
Většinu chyb se snažíme najít při vývoji a vyřešit je.Vývoj znamená ty vývojáře, kteří na dané věci dělají. Vy se ale snažíte i případné chyby dostat co nejrychleji i k ostatním vývojářům, kteří jsou ale k dané věci v rolích uživatelů. Z chyb během vývoje děláte chyby během nasazení a používání.
Tvrdil jste, že chyba, kterou dostanete na stůl co nejrychleji vás obtěžuje a zdržuje od vašeho poklidného vývoje v koutě.Ano, chyba někoho jiného, se kterou jsem se nemusel vůbec setkat, mne obtěžuje a zdržuje.
Jestli něco nedává smysl tak je to vaše představa že sedím nad programem který nic nedělá, nad testy které nic netestují, a dostávám za to peníze.Vždyť to tady opakovaně popisujete. Pokud vývoj něčeho trvá déle, dá se to podle vás rozplánovat tak, aby v průběhu vznikal kód a testy, které půjdou zkompilovat a projdou testy – a nezáleží na tom, že se ten kód ve skutečnosti nikde nepoužívá.
Další nesmysl. K integraci dochází každý den po takových kvantech po jakých se za ten den stihne udělat. Kód který se ten ten udělá už jede naostro.Sám jste to popisoval na několika příkladech. Vývoj nějaké funkce trvá třeba 3 dny, tak vy si to rozdělíte na 10 půldenních částí. Po každé takové části máte kód, který projde kompilací a testy, ale ve skutečnosti se nikde nepoužívá, nepoužíváte ho ani vy sám. Teprve po pěti dnech dojde ke skutečné integraci a ten kód se začne používat. CI se normálně snaží co nejrychleji integrovat funkcionalitu. Vaše úprava znamená co nejrychleji integrovat kód – i když je nepoužívaný.
Nejde.Největší nepřítel čehokoliv je vnitřní přesvědčení že to "nejde"... Znám lidi, kteří mi tvrdili, že něco nejde otestovat, tak jsme sedli a napsali to, a najednou to šlo. Zajímavé, co... ale ten váš případ bude určitě něco jiného a proto to nejde.
Vývoj znamená ty vývojáře, kteří na dané věci dělají. Vy se ale snažíte i případné chyby dostat co nejrychleji i k ostatním vývojářům, kteří jsou ale k dané věci v rolích uživatelů. Z chyb během vývoje děláte chyby během nasazení a používání.Pokud jsou opravdu v rolích uživatelů, tak na ně můžu zavést stejný proces, jako s ostatníma uživatelema. Tzn. definice požadavků, akceptační testy, release. Tohle je ale pro tým o 5 lidech naprostý overkill, takže žádná role vnitřního uživatele se nekoná. Všichni jedou na jedné lodi a maximální význam toho co označujete za "uživatele" je to, že na nějaké feature dělá po mně zítra pepa, a pozítří franta. V tom případě chci přesně to, aby dneska po mně zbyl produkt, který se sám umí otestovat a kde je přesně poznat, do jakého bodu jsem došel a kde se má navázat. A né ... "héé, tohle ještě nejde přeložit, těhle 5 testů neprochází, nechápu proč, a na tohle nesahej, protože to ještě nemám hotový, ale dostanu se k tomu určitě co nejdřív!!". A upřímně to tak chci i když zítra k tomu přijdu zase já.
Sám jste to popisoval na několika příkladech. Vývoj nějaké funkce trvá třeba 3 dny, tak vy si to rozdělíte na 10 půldenních částí. Po každé takové části máte kód, který projde kompilací a testy, ale ve skutečnosti se nikde nepoužívá, nepoužíváte ho ani vy sám.Můj příklad s přechodem na jinou databázi popisuje, jak 1. den přibyla binárka databáze (ta se používá - v balení instalačního balíku), další den přibyl spouštěcí skript (ten používá binárku a zároveň se používá v nainstalovaném produktu), další den se do databáze začaly sypat data, atd. Takže produkt z 1. dne se používá v 2. dni, a produkt z prvních 2 dní se používá ve 3. dnu atd.
CI se normálně snaží co nejrychleji integrovat funkcionalitu.Metodika CI integruje kód a pouští na něm testy ve velmi krátkých intervalech (půlden, nebo dokonce každý commit). Předpokládá se, že funkcionalita je zastoupena testy. Ale není pravda že by každé kolo integrace muselo přinášet nějakou novou funkcionalitu. Můžete klidně commitnout nějaký refactoring, který z definice žádnou funkcionalitu nepřidává, a nechat si výsledný kód projet na integračním počítači.
Zajímavé, co... ale ten váš případ bude určitě něco jiného a proto to nejde.Ano, můj případ je samozřejmě něco jiného. Vy píšete, že někdo tvrdil, že něco nejde, a ono to šlo. To ale ještě neznamená, že všechna tvrzení o tom, že něco nejde, jsou nepravdivá. Proč tedy nepředvedete, že každý kód, který tvoří nějakou funkcionalitu, jde napsat za 4 hodiny? Proč to nepředvedete třeba na změně používané SQL databáze?
Pokud jsou opravdu v rolích uživatelů,To jsou skoro vždy. Každý vývojář je uživatelem kódu spousty dalších vývojářů.
tak na ně můžu zavést stejný proces, jako s ostatníma uživatelema. Tzn. definice požadavků, akceptační testy, release.No sláva. O tom píšu celou dobu.
Tohle je ale pro tým o 5 lidech naprostý overkill, takže žádná role vnitřního uživatele se nekoná.To se mýlíte. Těch pět lidí asi nepíše kód, který není nijak provázaný – leda by dělali každý na jiném projektu. Jinak samozřejmě jeden vývojář píše kód, který volá kód někoho jiného – je tedy jeho uživatelem.
V tom případě chci přesně to, aby dneska po mně zbyl produkt, který se sám umí otestovat a kde je přesně poznat, do jakého bodu jsem došel a kde se má navázat.To já chci také. A proto ten bod určuju podle toho, jak vypadá ten kód, ne kolik je hodin.
A né ... "héé, tohle ještě nejde přeložit, těhle 5 testů neprochází, nechápu proč, a na tohle nesahej, protože to ještě nemám hotový, ale dostanu se k tomu určitě co nejdřív!!".Právě proto se dál předává kód tehdy, když je hotový a otestovaný, ne podle toho, že je čas na integraci a tak se musí dát dál, i když to ani nejde přeložit.
Můj příklad s přechodem na jinou databázi popisuje, jak 1. den přibyla binárka databáze (ta se používá - v balení instalačního balíku), další den přibyl spouštěcí skript (ten používá binárku a zároveň se používá v nainstalovaném produktu), další den se do databáze začaly sypat data, atd. Takže produkt z 1. dne se používá v 2. dni, a produkt z prvních 2 dní se používá ve 3. dnu atd.Ale co ty produkty byly? Co jste testoval druhý den? Přítomnost nějakého binárního souboru, ne funkci databáze. Kdybyste tam místo databáze dal Word, tak jste teprve třetí den přišel na to, že Word jako relační databáze není příliš vhodný. Takže jste sice kód integroval každý den, ale funkcionalitu až po několika dnech. K čemu to tedy celé bylo dobré?
Předpokládá se, že funkcionalita je zastoupena testy.To předpokládáte akorát vy. Většina lidí si uvědomuje, že automatizované testování je užitečné, ale nenalhávají si kvůli tomu, že jejich automatizované testy pokrývají 100 % funkcionality. Naopak jsou si dobře vědomi toho, jakou část pokrývají automatizované testy, a co je potřeba testovat jinak.
Ale není pravda že by každé kolo integrace muselo přinášet nějakou novou funkcionalitu.Mělo by přinášet novou funkcionalitu nebo změnu implementace té stávající. Ale kód, který nikdo nepoužívá, nemá v integračních testech žádný význam.
Můžete klidně commitnout nějaký refactoring, který z definice žádnou funkcionalitu nepřidává, a nechat si výsledný kód projet na integračním počítači.To mohu, ale nemusím kvůli tomu ten kód ještě nutit ostatním. Nechám ten kód sestavit ze své větve, třeba ho nasadím na server, a teprve pak objevím nějaké chyby. Tak je opravím, a teprve po několika iteracích budu ten kód považovat za natolik opravený, že jej dám do hlavní větve. Z ní si ho pak ostatní stáhnou podle potřeby, až dokončí svou práci.
To jsou skoro vždy. Každý vývojář je uživatelem kódu spousty dalších vývojářů.Můj produkt ale nejde ke spoustě dalších vývojářů. (Pokud by šel, pracoval bych s nimi jako s uživateli.)
Těch pět lidí asi nepíše kód, který není nijak provázaný – leda by dělali každý na jiném projektu. Jinak samozřejmě jeden vývojář píše kód, který volá kód někoho jiného – je tedy jeho uživatelem.Takový uživatel je se mnou v úplně jiném vztahu než uživatel zákazník.
Právě proto se dál předává kód tehdy, když je hotový a otestovaný, ne podle toho, že je čas na integraci a tak se musí dát dál, i když to ani nejde přeložit.Vy to chápete celou dobu asi špatně, nebo nevím. Já žádný termín na integraci nehoním. Můj kód je hotový a otestovaný každých možná 5-10 minut. Změny a testy dělám paralelně při sobě. Doslova po jednotlivých metodách, ne-li řádkách. Mám spoustu prostoru si říct "tak, a teď je hotová nějaká větší část, jdu pushnout, integrovat a vyvětrat si hlavu". Když za celý den nejsem schopen přijít něco co nejde (celý den) ani přeložit tak asi dělám něco hodně špatně. Raději než ten zmatek opravovat, to hodím do koše a začnu znova. Ve skutečnosti platí pravidlo, že když se vám nedaří projít test do půl hodiny, tak jste se zasekl a měl byste se vrátit a jít na to znova. Zní to krutě ale vyplatí se to. Je to úplně jiný systém než jste možná zvyklý. A ne, neni to můj vynález.
Ale co ty produkty byly? Co jste testoval druhý den? Přítomnost nějakého binárního souboru, ne funkci databáze. Kdybyste tam místo databáze dal Word, tak jste teprve třetí den přišel na to, že Word jako relační databáze není příliš vhodný. Takže jste sice kód integroval každý den, ale funkcionalitu až po několika dnech. K čemu to tedy celé bylo dobré?Každý den se integruje jedna funkcionalita. Funkcionalita č. 1 = instalátor umí nainstalovat databázi. Funkcionalita č. 2 = spouštěcí skript umí spustit nainstalovanou databázi. Funkcionalita č. 3 = programy používají nainstalovanou a spuštěnou databázi. atd. Dobré to bylo k tomu, že jsem každý den viděl, že všechny dosud dodané funkce byly kompatibilní s nejnovější verzí produktu (=se všemi změnami od jiných lidí). Ten příklad s Wordem nemá s CI nic společného protože v tom nefiguruje ta integrace s prací někoho jiného. Pokud já dělám na SQL databázi a franta dělá souběžně na něčem jiném, a najednou si v nějaké věci dupnem na nohu, tak to CI odhalí dřív, než kdybychom se mergovali až nakonec. Např. franta může změnit nějakou knihovnu, kvůli které mi nepoběží spouštěcí skript, tak já na to přijdu dejme tomu v den č. 3 ráno. Jelikož je den č. 3 ze 14, a nefunguje mi věc kterou jsem dělal jeden den (č. 2) tak nejsem ve stresu a v klidu zajdu za frantou, proberu to, skript upravím, a nad takto upraveným skriptem buduju další funkce. Kdybych se naopak tou změnou knihovny "nenechal rušit", a budoval funkce nad starou knihovnou a skriptem, tak bych v den č. 13 ze 14 při velkém merge zjistil, že nejede databáze, protože nefunguje skript, protože ??? hodina hledání, aha franta před 2 týdny ... hele, franto, to je těžce v prdeli, já když teď předělám ten skript, tak musím ještě překopat ABCD a zejtra to musíme odevzdávat. Nó tak jo, tak tu zas budem přes noc nó. A tahle situace je ještě desetkrát horší, když se kombinuje s praktikama typu "automatické testy pokrývají malou část", takže krom toho, že na poslední chvíli překopávám skripty, tak ještě dokola manuálně builduju a instaluju na server (protože to nemám určitě taky automatizované - stálo by to moc práce) a proklikávám všechny formuláře ve web aplikaci. Samozřejmě nesmím zapomenout vychytat všechny možnosti, např. že když si zákazník koupí kachničku do vany, a nechá si jí zabalit dárkově do papíru, který není na skladě, tak dostane 10% slevu. A nebo ne, protože to jsem zkoušel už včera a ani jedno z toho jsme při práci s frantou určitě nezkazili.
Nechám ten kód sestavit ze své větve, třeba ho nasadím na server, a teprve pak objevím nějaké chyby. Tak je opravím, a teprve po několika iteracích budu ten kód považovat za natolik opravený, že jej dám do hlavní větve. Z ní si ho pak ostatní stáhnou podle potřeby, až dokončí svou práci.A dostanou se do situace viz výše. Já vím, neznáte to, neexistuje, ...
Můj produkt ale nejde ke spoustě dalších vývojářů.Pokud děláte na projektu sám, nevím, co tu pořád řešíte.
Takový uživatel je se mnou v úplně jiném vztahu než uživatel zákazník.No a co? To ještě neznamená, že má být bezdůvodně otravován vašimi chybami a vaším vývojem.
Můj kód je hotový a otestovaný každých možná 5-10 minut.Co je to za projekt? Nedovedu si představit, co může být tak jednoduché, že vše zvládnete za 10 minut napsat a ještě otestovat. Kdybyste dělal třeba webové stránky, nestihnete za těch 10 minut ani spustit všechny prohlížeče, ve kterých je potřeba to vyzkoušet.
Ve skutečnosti platí pravidlo, že když se vám nedaří projít test do půl hodiny, tak jste se zasekl a měl byste se vrátit a jít na to znova.Nepředstavujte vy si pod testy pořád jen automatizované testy?
Je to úplně jiný systém než jste možná zvyklý.Ano, já jsem zvyklý považovat program za hotový tehdy, když funguje, ne když jde sbuildovat a projdou automatické testy.
Každý den se integruje jedna funkcionalita.Nikoli. Každý den se nahraje kód funkcionality do společného úložiště. Integruje se až tehdy, když se začne používat.
Ten příklad s Wordem nemá s CI nic společného protože v tom nefiguruje ta integrace s prací někoho jiného.Úplně stejně, jako ve vašem případě s databází.
Pokud já dělám na SQL databázi a franta dělá souběžně na něčem jiném, a najednou si v nějaké věci dupnem na nohu, tak to CI odhalí dřív, než kdybychom se mergovali až nakonec.CI ano, ale ne váš systém.
Např. franta může změnit nějakou knihovnu, kvůli které mi nepoběží spouštěcí skript, tak já na to přijdu dejme tomu v den č. 3 ráno.Nebo vám ten skript poběží, ale špatně. A přijdete na to až 14. den, protože jste celou dobu integroval jenom kód, ale ne funkcionalitu.
Kdybych se naopak tou změnou knihovny "nenechal rušit", a budoval funkce nad starou knihovnou a skriptem, tak bych v den č. 13 ze 14 při velkém merge zjistil, že nejede databáze, protože nefunguje skript, protože ??? hodina hledání, aha franta před 2 týdny ... hele, franto, to je těžce v prdeli, já když teď předělám ten skript, tak musím ještě překopat ABCD a zejtra to musíme odevzdávat. Nó tak jo, tak tu zas budem přes noc nó.Tomuhle ale váš způsob práce nijak nezabrání, protože sice dáváte kód do společného úložiště, ale ten kód není integrovaný, takže se nikde jinde nepoužívá. Na tohle je jediný recept – zodpovědnost za jednotlivé části projektu, kdy si ten zodpovědný pohlídá takové věci, jako je dopad výměny nějaké knihovny. Přece nemůžete nechat nějakého čerstvého absolventa po 14 dnech zapracování měnit jen tak části aplikace, kterým vůbec nerozumí.
automatické testy pokrývají malou částTo je fakt. Když před tím budete zavírat oči, jenom se tím výsledek podstatně zhorší.
Samozřejmě nesmím zapomenout vychytat všechny možnostiNa vychytání všech možností se dobře hodí automatizované testy.
A dostanou se do situace viz výše. Já vím, neznáte to, neexistuje, ...Neznám. Možná, že to někde existuje. Ale z faktu, že ve většině projektů takové problémy nejsou, je zřejmé, že problém je někde jinde, než kde ho vidíte vy.
Nedovedu si představit, co může být tak jednoduché, že vše zvládnete za 10 minut napsat a ještě otestovat.Napsat novou třídu, něco nastavit, něco refaktorovat. Test suite z toho běží tak 10 sekund i s překladem.
Kdybyste dělal třeba webové stránky, nestihnete za těch 10 minut ani spustit všechny prohlížeče, ve kterých je potřeba to vyzkoušet.Vždyť je můžu mít puštěné a stisknout reload.
Nebo vám ten skript poběží, ale špatně. A přijdete na to až 14. den, protože jste celou dobu integroval jenom kód, ale ne funkcionalitu.A co je to záhadné "špatně"?
Ne, já mám oči otevřené a každý nalezený průšvih cpu hned do testu.automatické testy pokrývají malou částTo je fakt. Když před tím budete zavírat oči, jenom se tím výsledek podstatně zhorší.
Nikoli. Každý den se nahraje kód funkcionality do společného úložiště. Integruje se až tehdy, když se začne používat.Myslím, že si dost silně pletete pojmy a/nebo nevidíte souvislosti.
CI ano, ale ne váš systém.Máte na ty věci opravdu podivný názor. Nejdřív odmítnete CI včetně dobrých praktik, tak jak jsou popsány v originálním článku a v další literatuře. Pak najednou jste na CI expert. Mám z toho dojem, že ty věci z praxe neznáte a jen žvaníte.
Napsat novou třídu, něco nastavit, něco refaktorovat. Test suite z toho běží tak 10 sekund i s překladem.Uživatelé ale nepoužívají novou třídu, ale novou funkcionalitu.
A co je to záhadné "špatně"?Nebude dělat to, co má.
Ne, já mám oči otevřené a každý nalezený průšvih cpu hned do testu.S vámi je to těžké. Vy prostě nevidíte nic jiného, než kód. Že to pak bude používat nějaký člověk? A že by byl rád, aby ta aplikace dělala to, co má? To jde evidentně zcela mimo vás. Přece procházejí testy, tak koho zajímá, že v tom textovém editoru nejde psát…
Nejdřív odmítnete CI včetně dobrých praktik, tak jak jsou popsány v originálním článku a v další literatuře.CI jsem nikdy neodmítal. Jenom se vám snaží vysvětlit, že jste CI vůbec nepochopil a za CI vydáváte nějaký váš systém, který je v mnoha ohledech přesným opakem CI.
Uživatelé ale nepoužívají novou třídu, ale novou funkcionalitu.No a to mi brání postupovat k té funkcionalitě po třídách?
Nebude dělat to, co má.A na to přijdete jak?
Že to pak bude používat nějaký člověk? A že by byl rád, aby ta aplikace dělala to, co má? To jde evidentně zcela mimo vás. Přece procházejí testy, tak koho zajímá, že v tom textovém editoru nejde psát…Proč to stavíte takhle? Když chci aby v tom šlo psát, tak si přeci napíšu testy, které ověří, že v tom jde psát.
Jenom se vám snaží vysvětlit, že jste CI vůbec nepochopil a za CI vydáváte nějaký váš systém, který je v mnoha ohledech přesným opakem CI.Tomu se velmi těžko věří, když zároveň tvrdíte že Fowler se mýlí, Google je irelevantní takže de fakto každý zdroj který Vám poskytnu tak nějak smetete ze stolu. Přitom sám jste neposkytl nic víc než svůj názor.
No a to mi brání postupovat k té funkcionalitě po třídách?Nebrání. Ale třída procházející testy ještě zdaleka neznamená otestovaná funkcionalita.
A na to přijdete jak?Testováním, ne jen automatizovaným.
Proč to stavíte takhle? Když chci aby v tom šlo psát, tak si přeci napíšu testy, které ověří, že v tom jde psát.Jistě, jenom si naprogramujete umělou inteligenci. Můžete nám teda popsat, jak se píše test, který otestuje přehlednost, srozumitelnost a použitelnost UI? Jak se píše test, který testuje srozumitelnost workflow? Jak test, který testuje srozumitelnost chybových zpráv?
Tomu se velmi těžko věří, když zároveň tvrdíte že Fowler se mýlíTo jsem nikde netvrdil. Tvrdím, že vy se mýlíte v jeho interpretaci.
Google je irelevantníTo jsem netvrdil – ostatně vy jste nijak nedokázal, že by Google používal zrovna vaši metodiku.
Přitom sám jste neposkytl nic víc než svůj názor.Názor a argumenty na jeho podporu.
Nebrání. Ale třída procházející testy ještě zdaleka neznamená otestovaná funkcionalita.Čili "funkcionalita" se dá rozdělit na posloupnost menších kroků. Každý krok lze vyprodukovat a zaintegrovat tak aby nezavedl regresi. A to je celé. Viz: Frequent commits encourage developers to break down their work into small chunks of a few hours each. This helps track progress and provides a sense of progress. Often people initially feel they can't do something meaningful in just a few hours, but we've found that mentoring and practice helps them learn.
Testováním, ne jen automatizovaným.A to testujete hala bala, nebo podle nějakého scénáře? Pokud nejste schopen to testování nějak uchopit a popsat, tak se na to nelze spolehnout. Pokud to schopen popsat jste, tak se můžete rozhodnout jestli to zautomatizujete nebo ne. Většinou to zautomatizovat jde. Rozhodně u nějakého skriptu, který dělá přesně definované úkoly, si nedovedu představit, že by měl být problém s automatizací testů. Začínám si myslet, že se vám to celé zdá nepochopitelné proto, že si nedovedete představit, že byste puntičkářsky chování softwaru popsal do posledního řádku. Ale to je zhruba to, co dobrá sada testů dělá.
Jistě, jenom si naprogramujete umělou inteligenci. Můžete nám teda popsat, jak se píše test, který otestuje přehlednost, srozumitelnost a použitelnost UI? Jak se píše test, který testuje srozumitelnost workflow? Jak test, který testuje srozumitelnost chybových zpráv?Místo AI mi stačí si tyhle věci probrat se zákazníkem, ten mi naspecifikuje, co jak má být, a já si můžu udělat v nejjednodušším případě test, který skontroluje skutečný výstup programu proti té specifikaci. Nejlepší se to dělá s nějakým frameworkem na akceptační testy, kde je ta specifikace jak srozumitelná pro zákazníka (dá se číst jako věty v angličtině), tak spustitelná jako test. Tady si zase začínám myslet, že neumíte uchopit rozdíl mezi rolí zákazníka, který určuje tu "srozumitelnost a použitelnost" a rolí vývojáře, který to pak udělá, ačkoliv cílovou doménu nezná. A opět, musíte pedanticky popsat a testovat všechny aspekty, které si zákazník přeje.
Tvrdím, že vy se mýlíte v jeho interpretaci.To asi těžko, když píšu to samé (já a další spousta lidí, kteří to používají) ...
Čili "funkcionalita" se dá rozdělit na posloupnost menších kroků. Každý krok lze vyprodukovat a zaintegrovat tak aby nezavedl regresi. A to je celé.Není to celé. Je to pouze menší část.
Pokud nejste schopen to testování nějak uchopit a popsat, tak se na to nelze spolehnout.Testuje se funkcionalita aplikace. Něco může být explicitně popsané, něco nemusí, protože popisovat by to bylo složité nebo nepřesné.
Většinou to zautomatizovat jde.Pořád jste nepopsal, jak automatizuje lidské vnímání a chování. Jenom taková „prkotina“ jako rozložení jednotlivých prvků na obrazovce může učinit aplikaci absolutně nepoužitelnou. Můžete testovat, zda se rozvržení prvků na pixel shoduje s předchozí verzí, ale to je nepoužitelné, pokud děláte změny.
Začínám si myslet, že se vám to celé zdá nepochopitelné proto, že si nedovedete představit, že byste puntičkářsky chování softwaru popsal do posledního řádku. Ale to je zhruba to, co dobrá sada testů dělá.Já si to právě představit dovedu, takže vím, že je to prakticky nemožné. Chování softwaru do posledního řádku, takže pak můžete dokázat, co software dělá, se dělá jen ve velmi ojedinělých případech a u velmi specializovaného a malého software.
Místo AI mi stačí si tyhle věci probrat se zákazníkem, ten mi naspecifikuje, co jak má být, a já si můžu udělat v nejjednodušším případě test, který skontroluje skutečný výstup programu proti té specifikaci.Dobře. Tak tady máte specifikaci: „zobrazit položky nákupního košíku tak, aby uživatel získal dojem, že název zboží, množství, jednotková cena a celková cena u jednoho zboží patří k sobě“. A teď mi popište ten test.
Něco může být explicitně popsané, něco nemusí, protože popisovat by to bylo složité nebo nepřesné.Nemůžete pracovat s nepřesnou nebo složitou specifikací. Musíte se zamyslet, jak to zjednodušit a zpřesnit. To je vaše přidaná hodnota.
Pořád jste nepopsal, jak automatizuje lidské vnímání a chování.Musíte ho popsat, a pak ho můžete automatizovat.
Jenom taková „prkotina“ jako rozložení jednotlivých prvků na obrazovce může učinit aplikaci absolutně nepoužitelnou. Můžete testovat, zda se rozvržení prvků na pixel shoduje s předchozí verzí, ale to je nepoužitelné, pokud děláte změny.Já si myslím, že tohle není prkotina. Prkotina je testovat spouštěcí skript. Testování renderingu grafiky je dost těžké i na dnešní poměry. Samozřejmě, grafikou myslím to "V" z modelu MVC. Tam je vizuální kontrola změn asi to nejlepší co můžete vymyslet. Screenshoty si můžete generovat a tak si usnadnit kontrolu. Na druhou stranu (a naštěstí) to "V" je většinou dobře odizolované od ostatních změn a samo se zas tak často nemění.
Já si to právě představit dovedu, takže vím, že je to prakticky nemožné. Chování softwaru do posledního řádku, takže pak můžete dokázat, co software dělá, se dělá jen ve velmi ojedinělých případech a u velmi specializovaného a malého software.Já ale nemyslím matematické důkazy, jen spustitelný popis toho, co se od které části očekává, jak má vypadat vstup a výstup.
„zobrazit položky nákupního košíku tak, aby uživatel získal dojem, že název zboží, množství, jednotková cena a celková cena u jednoho zboží patří k sobě“Tak to je typický případ špatné specifikace. Asi bych šel za zákazníkem a vyjasnil si, co je to ten dojem. Dospěli bychom k nějaké konkrétní variantě, jak se to zobrazí. Dejme tomu že výsledek bude, že to bude jeden řádek v tabulce, se sloupci v uvedeném pořadí. Můžeme se ještě dohodnout na zarovnání, formátu ceny, atp. Z toho plynou následující testy... 1) uděláte si v GUI frameworku mock, kde napíšete nějaký pevně daný vstup a ověříte, že se zobrazí tak jak chcete (test na view)... pamatuju si že když jsem tohle řešil naposled, tak třeba nefungovalo zarovnávání... 2) automatické testy na metodu která převádí objekt Košík do tabulky kterou akceptuje ten GUI framework (test na model)... otestujete Košík s 0, 1 a 3 položkami... A to by asi pro začátek stačilo, samozřejmě platí pravidlo, že při problémech se zaměříte s testováním více na problémovou část.
Nemůžete pracovat s nepřesnou nebo složitou specifikací. Musíte se zamyslet, jak to zjednodušit a zpřesnit. To je vaše přidaná hodnota.Ne, nemusím. Nebudu vyrábět stostránkový nepřesný elaborát plný psychologie, ergonomie a dalšího na věc, kterou trošku zkušený tester odhalí na první pohled.
Musíte ho popsat, a pak ho můžete automatizovat.Simulovat strojově některé rysy lidského chování se ti nejlepší vědci pokouší už desítky let. V některých dílčích oblastech už to superpočítače zvládají – třeba šachy nebo teď Riskuj. A vy to samé chcete jen tak mezi řečí udělat v testu, který napíšete za pět minut.
Testování renderingu grafiky je dost těžké i na dnešní poměry.No sláva. Konečně jste připustil, že některé věci se automatizovaně testovat nedají, nebo se to nevyplatí.
Já ale nemyslím matematické důkazy, jen spustitelný popis toho, co se od které části očekává, jak má vypadat vstup a výstup.Ono je to ale takřka totéž. Vemte si jenom takový primitivní příkaz
cat – nikde nenajdete úplný popis jeho chování, a i kdybyste takový vytvořil, nedokážete jej stoprocentně převést do testů.
Tak to je typický případ špatné specifikace. Asi bych šel za zákazníkem a vyjasnil si, co je to ten dojem. Dospěli bychom k nějaké konkrétní variantě, jak se to zobrazí. Dejme tomu že výsledek bude, že to bude jeden řádek v tabulce, se sloupci v uvedeném pořadí.Zákazník ale nechce řešit nějaké zobrazování v tabulce, to je implementační detail, který ho nezajímá.
Z toho plynou následující testy...To jsou nepochybně užitečné testy. Ale pokrývají menšinu toho, co je potřeba otestovat. Existuje spousta případů, kdy něco tyhle testy splní, ale stejně to bude zobrazené špatně. Takže stejně nezbývá nic jiného, než k počítači posadit člověka, a nechat jej zkontrolovat, zda se to zobrazuje správně. Při podrobnější specifikaci (pokud na to bude mít zadavatel náladu) můžete mít nějaké vzorové zobrazení a tester bude kontrolovat „jenom“ to, zda se to zobrazuje dostatečně podobně.
Nebudu vyrábět stostránkový nepřesný elaborát plný psychologie, ergonomie a dalšího na věc, kterou trošku zkušený tester odhalí na první pohled.To zase stavíte extrémy. Takový elaborát je stejně nezajímavý jako ta prvotní nepřesná specifikace. Je potřeba mít maximum jasných a jednoduchých zadání, které může za vás ověřit i počítač. Něco z toho umí popsat tester, něco ne.
Simulovat strojově některé rysy lidského chování se ti nejlepší vědci pokouší už desítky let. V některých dílčích oblastech už to superpočítače zvládají – třeba šachy nebo teď Riskuj.Ano, proto se to dnes dělá tak, že se lidi nesimulují, ale pozorují. Výsledek toho lze replikovat strojově.
Konečně jste připustil, že některé věci se automatizovaně testovat nedají, nebo se to nevyplatí.Já nevím, ale s tím, že některé věci počítač neověří, jsem nikdy problém neměl. Nesouhlasím ale s tím, že se to dá zobecnit na většinu věcí. Např. ergonomie/přitažlivost UI je vypíchnuta v každé dobré knize o testování.
Vemte si jenom takový primitivní příkaz cat – nikde nenajdete úplný popis jeho chování, a i kdybyste takový vytvořil, nedokážete jej stoprocentně převést do testů.Myslím, že cat jsme už probrali ...
Zákazník ale nechce řešit nějaké zobrazování v tabulce, to je implementační detail, který ho nezajímá.Za prvé by ho to zajímat mělo (viz níže) a za druhé tak to můžu vždycky rozhodnout za něj. Každopádně to chci vyřešit vědomě a následně z toho udělat to jasné a jednoduché zadání.
To jsou nepochybně užitečné testy. Ale pokrývají menšinu toho, co je potřeba otestovat. Existuje spousta případů, kdy něco tyhle testy splní, ale stejně to bude zobrazené špatně.A spousta čeho např? A když už o tom budete přemýšlet, tak zkuste jít o krok dál a zeptat se sám sebe, jestli se ty nové defekty nedají testovat.
Při podrobnější specifikaci (pokud na to bude mít zadavatel náladu) můžete mít nějaké vzorové zobrazení a tester bude kontrolovat „jenom“ to, zda se to zobrazuje dostatečně podobně.To přece není o nějaké náladě, ale o stylu práce. Zákazník, který se tváří že mu je vše jedno, počítačům nerozumí, a nechá vás 2 měsíce "kreativně" pracovat, obvykle zapláče nad výsledkem. Zákazník, který se mnou úzce spolupracuje, má jednak lichotivý pocit, že dělám všechno proto, aby byl s produktem spokojený, a jednak opravdu dělám všechno proto, aby byl s produktem spokojený.
Ano, proto se to dnes dělá tak, že se lidi nesimulují, ale pozorují. Výsledek toho lze replikovat strojově.Počítače zatím možná zvládnou najít v obraze hlavní předmět nebo hledat něco, co mají zadané. Posoudit význam jednotlivých prvků v obraze a jejich kontext, to nezvládnou – vždyť Watson to teprve teď zvládá s řečí. A vy se pořád tváříte, že něco takového běžně integrujete do testů.
Nesouhlasím ale s tím, že se to dá zobecnit na většinu věcí.Pro uživatele je nejpodstatnější to, co a jak vnímá on. A to je zároveň to, co se automaticky testuje velmi špatně, často to vůbec nejde.
Např. ergonomie/přitažlivost UI je vypíchnuta v každé dobré knize o testování.Ale automatické testování ergonomie či použitelnosti byste tam hledal marně.
Myslím, že cat jsme už probrali ...A zjistili jsme, že i u tak primitivního programu dokážete otestovat jenom zlomek toho, co bude uživatel používat.
Za prvé by ho to zajímat měloNe, technické řešení zákazníka nezajímá. když já si půjdu koupit auto a výrobce se mne zeptá, jak má postavit motor, budu od něj hodně rychle utíkat.
Každopádně to chci vyřešit vědomě a následně z toho udělat to jasné a jednoduché zadání.To je ale pořád jen otázka toho, do jakých podrobností chcete jít.
A spousta čeho např? A když už o tom budete přemýšlet, tak zkuste jít o krok dál a zeptat se sám sebe, jestli se ty nové defekty nedají testovat.Představte si náš oblíbený
cat, který pokud najde ve vstupu nějaký specifický řetězec, na výstupu jej nahradí něčím jiným. Nebo druhé úterý v lichém měsíci v sudém roce v každé 13. minutě pozmění výstup 5 bajtů od pozice 68127. Jsem zvědav, jakými testy tohle odhalíte, když nebudete o těch chybách vědět dopředu.
Počítače zatím možná zvládnou najít v obraze hlavní předmět nebo hledat něco, co mají zadané. Posoudit význam jednotlivých prvků v obraze a jejich kontext, to nezvládnou – vždyť Watson to teprve teď zvládá s řečí. A vy se pořád tváříte, že něco takového běžně integrujete do testů.Víte, tohle taky přetahujete do extrému.
Pro uživatele je nejpodstatnější to, co a jak vnímá on. A to je zároveň to, co se automaticky testuje velmi špatně, často to vůbec nejde.Proto se vývoj softwaru netýká jen testování, ale taky definování požadavků s uživatelem.
Ne, technické řešení zákazníka nezajímá. když já si půjdu koupit auto a výrobce se mne zeptá, jak má postavit motor, budu od něj hodně rychle utíkat.To je zase špatný příklad. Software se narozdíl od aut vyvíjí. Kdybyste si nechal auto vyvinout pro svoje potřeby, tak byste měl na výběr motoru asi jiný názor. Navíc "technické řešení" se týká toho, jestli to bude v javě nebo v dotnetu, ale ne jestli to bude tabulka nebo obrázek.
To je ale pořád jen otázka toho, do jakých podrobností chcete jít.To je dobrá otázka. Zacházíte až tam, kde přírůstek v podrobnosti přestane mít měřitelnou přidanou hodnotu. Návod jak tam dojít poskytují různé metodiky.
Představte si náš oblíbený cat, který pokud najde ve vstupu nějaký specifický řetězec, na výstupu jej nahradí něčím jiným. Nebo druhé úterý v lichém měsíci v sudém roce v každé 13. minutě pozmění výstup 5 bajtů od pozice 68127. Jsem zvědav, jakými testy tohle odhalíte, když nebudete o těch chybách vědět dopředu.Pokud o tom nebudu vědět dopředu tak na to nejprv budu muset přijít, stejně jako kdokoliv jiný.
Víte, tohle taky přetahujete do extrému.Co je na tom extrémního? Počítače to zatím opravdu nedokážou, a je to podstatná součást testování. Nix extrémního na tom není, je to věc, na kterou musíte narazit pokaždé, když se snažíte udělat kompletní pokrytí automatizovanými testy.
Kdybyste si nechal auto vyvinout pro svoje potřeby, tak byste měl na výběr motoru asi jiný názor.Měl bych názor na výběr motoru. Ale pořád bych očekával, že výrobce toho auta umí motor vyrobit a nebude po mně chtít vědět, jak to má udělat.
Navíc "technické řešení" se týká toho, jestli to bude v javě nebo v dotnetu, ale ne jestli to bude tabulka nebo obrázek.technické řešení je, zda to bude tabulka v HTML, seznam v HTML, divy v HTML apod.
Zacházíte až tam, kde přírůstek v podrobnosti přestane mít měřitelnou přidanou hodnotu. Návod jak tam dojít poskytují různé metodiky.Pochybuju o tom, že to tak ve skutečnosti děláte. ve skutečnosti nejspíš zacházíte až tam, kdy náklady na popis začnou převyšovat zvýšené náklady na opakované manuální testování po nějakou rozumnou dobu. Nebo-li když budete specifikaci sepisovat týden, a ruční testování v příštích 5 letech by dohromady trvalo 1 den, zvolíte ruční testování.
Pokud o tom nebudu vědět dopředu tak na to nejprv budu muset přijít, stejně jako kdokoliv jiný.Kdokoli jiný ale má šanci na to přijít, protože testuje i jinak, než již hotovými automatizovanými testy. Vy ale build, který projde automatizovanými testy, rovnou nasazujete k zákazníkovi, takže na to přijdete až tehdy, když vám chybu oznámí zákazník.
Co je na tom extrémního? Počítače to zatím opravdu nedokážou, a je to podstatná součást testování. Nix extrémního na tom není, je to věc, na kterou musíte narazit pokaždé, když se snažíte udělat kompletní pokrytí automatizovanými testy.Extrémní je jak na tom bazírujete. Ano, strojové rozpoznání hlasu nebo obrazu je těžké, a proto si svou práci zorganizuju tak, aby na tom nestála. A ano, je důležité kontrolovat vizuální podobu a nejlépe se to dělá okem, ale to je asi tak všechno. Pokud jste fotograf, tak to je většinová záležitost, pokud jste vývojář software, tak není.
Ale pořád bych očekával, že výrobce toho auta umí motor vyrobitStejně tak výrobce software ví jak ten software napsat.
Pochybuju o tom, že to tak ve skutečnosti děláte.Proč?
Kdokoli jiný ale má šanci na to přijít, protože testuje i jinak, než již hotovými automatizovanými testy. Vy ale build, který projde automatizovanými testy, rovnou nasazujete k zákazníkovi, takže na to přijdete až tehdy, když vám chybu oznámí zákazník.Jak jsem už psal, manuální testování má své místo jako detektor děr v procesu testování, tj. hledají se úplně nové třídy závad. Na to toho člověka platíte, ne na to, aby dokola spouštěl cat a psal tam hello. Pokud ten člověk dostane zjevení, že si má nastavit datum na úterý třináctého nebo jak to bylo, tak na tu chybu pravděpodobně přijde. Jinak se projeví až u zákazníka. Co jiného s tím chcete dělat?
Ano, strojové rozpoznání hlasu nebo obrazu je těžké, a proto si svou práci zorganizuju tak, aby na tom nestála.To máte dobré. Většina lidí ale pořád vyvíjí software, který používají lidé, ne stroje.
A ano, je důležité kontrolovat vizuální podobu a nejlépe se to dělá okem, ale to je asi tak všechno. Pokud jste fotograf, tak to je většinová záležitost, pokud jste vývojář software, tak není.Zřejmě pořád nechápete, že vizuální podoba je to, čím program komunikuje s uživatelem. Představte si takovou fakturu – to, co z ní dělá fakturu, je právě vizuální podoba. Zkuste si fakturu rozstříhat na jednotlivé údaje a ty jen tak nasypat na stůl – dostanete chaos, ve kterém se nikdo nevyzná (to v lepším případě, s velmi nízkou pravděpodobností dostanete něco, co člověk dokáže interpretovat, ale bude to špatně, a ještě daleko menší část je to, co bude člověk interpretovat správně). Program může interně s daty pracovat správně, ale když to pak špatně prezentuje uživateli, je to k ničemu.
Protože byste pak nedělal nic jiného, než specifikace a testy. Pro každou specifikaci nebo sadu testů vám najdu případ, který ještě není plně popsán a dá se zpřesnit nebo se dá otestovat případ, který může nastat, může v něm být chyba a zatím se netestuje.Proč?Zacházíte až tam, kde přírůstek v podrobnosti přestane mít měřitelnou přidanou hodnotu. Návod jak tam dojít poskytují různé metodiky.Pochybuju o tom, že to tak ve skutečnosti děláte.
Jak jsem už psal, manuální testování má své místo jako detektor děr v procesu testování, tj. hledají se úplně nové třídy závad.No jo, ale jak tohle zařadíte do toho vašeho 4hodinového vývojového cyklu, jak to zařadíte do vašeho schématu „co projde automatizovanými testy, může jít k zákazníkovi“?
Pokud ten člověk dostane zjevení, že si má nastavit datum na úterý třináctého nebo jak to bylo, tak na tu chybu pravděpodobně přijde.Pokud ten člověk o problematice něco ví, zpravidla dokáže vyhmátnout ty zajímavé případy.
Co jiného s tím chcete dělat?Jiného nic. Jenom se vám celou dobu snažím vysvětlit, že tohle je také součást testování. A tahle součást nezapadá do vašeho konceptu „cokoliv je hotové za 4 hodiny, ověří se to automatickými testy“.
Představte si takovou fakturu – to, co z ní dělá fakturu, je právě vizuální podoba.Vizuální podoba v tom má určitě zastoupení, ale gró každého účetního programu (a masivně větší zdroj možný chyb) je v obsahu té faktury a v tom jak se k němu dospěje.
Zkuste si fakturu rozstříhat na jednotlivé údaje a ty jen tak nasypat na stůlJasně, tak je to špatně. Ale tahle chyba je jednak triviální na odhalení a hlavně a zejména jde obsah a formu od sebe oddělit tak, že mají minimální vzájemné ovlivnění. Takže to, že lidi komunikují s programem přes GUI neklade žádné omezení na testování funkčnosti toho programu. To je přece základ MVC. Představte si naopak, že vlivem deadlocku kdesi hluboko mezi servicama toho programu se té faktury nedočkáte, nebo vlivem přetečení čehosi naúčtujete někomu mínus miliardu korun. Nebo že váš programátor, na kterém necháte vyjasnění nejasné specifikace, poplete má dáti a dal.
Program může interně s daty pracovat správně, ale když to pak špatně prezentuje uživateli, je to k ničemu.& vice versa.
Protože byste pak nedělal nic jiného, než specifikace a testy.Specifikace nedělám - to lze nahradit těmi testy. A testy dělám společně s kódem.
Pro každou specifikaci nebo sadu testů vám najdu případ, který ještě není plně popsán a dá se zpřesnit nebo se dá otestovat případ, který může nastat, může v něm být chyba a zatím se netestuje.Super, najděte si zaměstnání jako tester. A z mojí zkušenosti odhaduju, že brzo zjistíte, že ten bod, kde už nový test bude redundantní proti ostatním, není tak daleko.
Pokud ten člověk o problematice něco ví, zpravidla dokáže vyhmátnout ty zajímavé případy.Ano, od toho tam je - aby měl zkušenosti a znalosti. Ale pak tam máte 5 vývojářů, a ti potřebujou dělat a nečekat na testera. Znovu opakuju, že role toho testera je najít systematické problémy, nikoliv dělat vyčerpávající pokrytí. To si udělají ti vývojáři už sami na základě znalostí/konkrétního zadání které jim předá ten tester. (Model, kde programátoři něco vyplodí, a pak na to přijde parta "testerů" která v tom najde tunu chyb, nefunguje už někdy od 80. let.)
Jenom se vám celou dobu snažím vysvětlit, že tohle je také součást testování. A tahle součást nezapadá do vašeho konceptu „cokoliv je hotové za 4 hodiny, ověří se to automatickými testy“.Naopak, to k tomu patří, a vzájemně se to podporuje.
Vizuální podoba v tom má určitě zastoupení, ale gró každého účetního programu (a masivně větší zdroj možný chyb) je v obsahu té faktury a v tom jak se k němu dospěje.jenže vám je houby platné, když se dospěje ke správnému výsledku, když pak uživateli třeba celkovou částku prezentujete tak, že to pochopí jako variabilní symbol.
Ale tahle chyba je jednak triviální na odhalení a hlavně a zejména jde obsah a formu od sebe oddělit tak, že mají minimální vzájemné ovlivnění.Protože uvádím triviální příklady. Ve skutečnosti je to často složitější, a nejde jen o vzhled, ale také o chování – a to nejen chování jedné „obrazovky“, ale třeba taky o workflow.
Takže to, že lidi komunikují s programem přes GUI neklade žádné omezení na testování funkčnosti toho programu. To je přece základ MVC.Samozřejmě, že to klade omezení. Když v MVC otestujete jenom M a trochu C, neotestoval jste všechno a v tom zbytku pořád mohou být chyby.
Představte si naopak, že vlivem deadlocku kdesi hluboko mezi servicama toho programu se té faktury nedočkáte, nebo vlivem přetečení čehosi naúčtujete někomu mínus miliardu korun. Nebo že váš programátor, na kterém necháte vyjasnění nejasné specifikace, poplete má dáti a dal.Já si to představit dokážu. To jsou ale věci, které se dají testovat automaticky (aspoň některé, u toho deadlocku to nemusí být vůbec snadné). Vy si ale představte, že se té faktury nedočkáte kvůli chybě v GUI nebo workflow. Vás to evidentně vůbec netrápí, mně je naopak celkem jedno, jestli je to chyba v logice aplikace nebo v GUI nebo v čemkoli jiném, podstatné je pro mne to, že výsledek nefunguje.
Specifikace nedělám - to lze nahradit těmi testy.Uf. Doufám, že se s výsledkem nikdy nepotkám.
A testy dělám společně s kódem.Tím spíš by vás mělo trknout, že když uděláte chybu v kódu, je dost pravděpodobné, že stejnou chybu uděláte i v testu.
A z mojí zkušenosti odhaduju, že brzo zjistíte, že ten bod, kde už nový test bude redundantní proti ostatním, není tak daleko.To těžko. Zatím jste nedokázal vyjmenovat všechny testy ani pro takovou trivialitu, jako je
cat. Není tak daleko bod, u kterého začnu předpokládat, že pokud se testovaný kód chová tak, jak si myslím, další testy už nepokrývají nic tak zajímavého. Pak ale potřebuju tenhle předpoklad ověřovat ručním testováním a hledat při něm další zajímavé oblasti.
Ale pak tam máte 5 vývojářů, a ti potřebujou dělat a nečekat na testera.První, kdo ten kód bude testovat, je snad právě ten vývojář, který to napsal. A ten potřebuje psát a testovat, a ne čekat na jiného vývojáře, až opraví svou chybu, kvůli které testovat nemůže.
To si udělají ti vývojáři už sami na základě znalostí/konkrétního zadání které jim předá ten tester.No právě. Ale kdy to mají chudáci dělat, když to mají napsat a komplet otestovat za 4 hodiny?
Naopak, to k tomu patří, a vzájemně se to podporuje.Nikoli. To, že funkcionalita musí být napsaná a komplet otestovaná za 4 hodiny se vylučuje s tím, že budete ručně testovat a hledat místa, kde by mohly nastávat problémy.
Uf. Doufám, že se s výsledkem nikdy nepotkám.Přiznávám se, že tohle motivovalo moji otázku, kde se ten phtův přístup používá. Akorát jsem bohužel dostal jenom odpověď na to, kdo používá přístup jiný.
když uděláte chybu v kódu, je dost pravděpodobné, že stejnou chybu uděláte i v testu.To je v rozporu asi se vším co je kde o testování napsáno.
čekat na jiného vývojáře, až opraví svou chybu... je chybná extrapolace Vašich zkušeností s projekty.
To, že funkcionalita musí být napsaná a komplet otestovaná za 4 hodiny se vylučuje s tím, že budete ručně testovat a hledat místa, kde by mohly nastávat problémy.Pokud jsem to před tím nenapsal dost jasně, tak ruční testování testuje proces výroby software, nikoliv software. Tudíž testuje něco jiného než software, a tudíž nepřekáží pravidelnému vývojovému cyklu software.
To teda nevím, co čtete. To jako chcete tvrdit, že když programátor v kódu zapomene ošetřit dělení nulou, při psaní testu ho políbí múza a test na ošetření dělení nulou napíše?když uděláte chybu v kódu, je dost pravděpodobné, že stejnou chybu uděláte i v testu.To je v rozporu asi se vším co je kde o testování napsáno.
Co tedy děláte s chybou, která brání testování aplikace, vy?čekat na jiného vývojáře, až opraví svou chybu... je chybná extrapolace Vašich zkušeností s projekty.
Pokud jsem to před tím nenapsal dost jasně, tak ruční testování testuje proces výroby software, nikoliv software.V tom případě se vám zase někam ztratilo testování software. Nebo zase budete tvrdit, že vám stačí již hotové automatizované testy?
To jako chcete tvrdit, že když programátor v kódu zapomene ošetřit dělení nulou, při psaní testu ho políbí múza a test na ošetření dělení nulou napíše?Testování funkcí pro hraniční případy je to nejzákladnější a nejjednodušší, co můžete testovat.
Co tedy děláte s chybou, která brání testování aplikace, vy?Opravím to, nebo ten commit dám do p. ... revertnu.
Testování funkcí pro hraniční případy je to nejzákladnější a nejjednodušší, co můžete testovat.Testování hraničních případů je to nejjednodušší, co se dá kontrolovat přímo v programu. Buď se tedy pak testy na to dělají zbytečně, protože na to nikdy žádný programátor nezapomene – a nebo si programátor neuvědomí, že jde o nějaký hraniční případ, pak ho ale nebude ani testovat.
Opravím to, nebo ten commit dám do p. ... revertnu.To musí jít vývoj rychle dopředu, když si navzájem pořád něco revertujete. Co když na to commitu závisí další commity?
Buď se tedy pak testy na to dělají zbytečně, protože na to nikdy žádný programátor nezapomeneTo by implikovalo, že test se může po projití smazat, což není pravda.
a nebo si programátor neuvědomí, že jde o nějaký hraniční případ, pak ho ale nebude ani testovat.Proto existují všechny ty metodiky, aby se to "neuvědomí" zahnalo až na práh vymření.
To musí jít vývoj rychle dopředu, když si navzájem pořád něco revertujete.Pokud revertujete něco pořád, tak to svědčí spíš o tom, že máte tým plný nezodpovědných lidí, a měl byste s tím něco udělat.
Co když na to commitu závisí další commity?To samé - opravit nebo revertnout.
To by implikovalo, že test se může po projití smazat, což není pravda.Neimplikovalo.
Proto existují všechny ty metodiky, aby se to "neuvědomí" zahnalo až na práh vymření.To je hodně naivní, myslet si, že se podaří psát takřka dokonalý software. Může se psát lepší software, který bude mít méně chyb, ale nepočítám s tím, že by se něco zásadně změnilo a chyby se podařilo takřka vymýtit. Zatím se daří tak maximálně udržovat jejich množství na stejné úrovni, i když se složitost projektu zvyšuje.
Pokud revertujete něco pořád, tak to svědčí spíš o tom, že máte tým plný nezodpovědných lidí, a měl byste s tím něco udělat.K nezodpovědnosti je tlačíte vy tím, že jim nedáváte čas na testování.
To samé - opravit nebo revertnout.Takže práce lidí se revertuje jenom pro to, že měli tu smůlu a commitovali až po nějaké chybě? Myslím, že definice CI jako postupu, kdy se ty samé změny neustále přidávají a zase odebírají, je velmi inovativní.
nepočítám s tím, že by se něco zásadně změnilo a chyby se podařilo takřka vymýtitMožná se vám bude zdát zajímavé počtení jak tým o asi 5 lidí téměř bez zkušeností a s jedním dobrým managerem (-kou) programovali embedded multivláknovou aplikaci v jazyce C. Tipněte si, kolik při tom udělali chyb. http://www.drdobbs.com/architecture-and-design/193501924
tlačíte ... nedáváte časS tímhle vyjadřováním byste mohl dělat politika, pokud nevyjde kariéra v software. ;)
Takže práce lidí se revertuje jenom pro to, že měli tu smůlu a commitovali až po nějaké chybě?Ta situace byla, že někdo commitne něco, co neprojde testama. Na takovém základu by se neměly stavět další věci stejně jako se paneláky nestaví na vodě. Navíc ten postup je: "opravit nebo revertovat", ne "revertovat".
Myslím, že definice CI jako postupu, kdy se ty samé změny neustále přidávají a zase odebírají, je velmi inovativní.A taky je vaše.
Možná se vám bude zdát zajímavé počtení jak tým o asi 5 lidí téměř bez zkušeností a s jedním dobrým managerem (-kou) programovali embedded multivláknovou aplikaci v jazyce C. Tipněte si, kolik při tom udělali chyb.Tipoval jsem, že to nikdo neví. Pokud jsem něco nepřehlédl, tipoval jsem správně – píšou tam o 51 evidovaných chybách, ale už nic o tom, zda se někdo vůbec pokusil další chyby hledat. Jinak aplikace, která sbírá nějaká data a něco z toho počítá, je to nejjednodušší, co lze předhodit automatizovanému testování.
Ta situace byla, že někdo commitne něco, co neprojde testama. Na takovém základu by se neměly stavět další věci stejně jako se paneláky nestaví na vodě. Navíc ten postup je: "opravit nebo revertovat", ne "revertovat".Ta situace je, že něco prošlo automatizovanými testy, ale neprošlo to testováním. Což způsobuje váš přístup. Já celou dobu tvrdím, že je lepší počkat s commitováním do hlavní větve, ponechat danou věc ve vedlejší větvi a tam ji pořádně otestovat. A teprve pak ji přesunout do hlavní větve.
píšou tam o 51 evidovaných chybách, ale už nic o tom, zda se někdo vůbec pokusil další chyby hledatJo, jenom celý článek (plus zdroje) popisuje metodologii jak ty chyby hledali. Ale určitě to udělali špatně™. :)
je lepší počkat s commitováním do hlavní větve, ponechat danou věc ve vedlejší větvi a tam ji pořádně otestovat. A teprve pak ji přesunout do hlavní větve.Cokoliv uděláte stran testování ve své větvi, je nutno zopakovat, jakmile uděláte merge s dalšími větvemi.
Jo, jenom celý článek (plus zdroje) popisuje metodologii jak ty chyby hledali.Asi jsem četl jiný článek. „Spouštěli jsme unit testy“ není metodologie hledání chyb. Hledání chyb znamená, že se zjišťuje, kdy se program chová jinak, než se od něj očekává.
Cokoliv uděláte stran testování ve své větvi, je nutno zopakovat, jakmile uděláte merge s dalšími větvemi.Není. Stačí otestovat, že se vše správně spojilo.
„Spouštěli jsme unit testy“ není metodologie hledání chyb. Hledání chyb znamená, že se zjišťuje, kdy se program chová jinak, než se od něj očekává.Píšou, že chyby na úrovni unit testů vůbec neevidovali, a těch 51 je odhaleno až v dalších levelech.
Stačí otestovat, že se vše správně spojilo.Nevím jak bych tohle dělal jinak, než normální testování.
A postup využívající větve je v porovnání s komity rovnou do masteru údajně neefektivní.Co když na to commitu závisí další commity?To samé - opravit nebo revertnout.
Tiskni
Sdílej:
