it-swarm-eu.dev

Jak se stát programátorem s nulovou chybou?

Můj šéf mi vždy říkal, že dobrý programátor by měl být schopen zajistit, aby kód, který mění, byl spolehlivý, správný a důkladně ověřený; že byste měli zcela porozumět všem výsledkům a dopadům, které vaše změny způsobí. Snažil jsem se, abych byl takovým programátorem - testováním znovu a znovu - ale chyby tam stále jsou.

Jak mohu být programátor s nulovou chybou a vědět, co způsobí a ovlivní každá postava mého kódu?

168
Elaine

Nekódujte vůbec.

To je jediný způsob, jak můžete být programátor s nulovou chybou.

Chyby jsou nevyhnutelné, protože programátoři jsou lidé, vše, co můžeme udělat, je pokusit se jim co nejlépe zabránit, reagovat rychle, když dojde k chybě, poučit se z našich chyb a zůstat v obraze.

365
wildpeaks

Nulové chyby nejsou možné pro netriviální program.

Je možné se dostat velmi blízko, ale produktivita trpí. A to je užitečné pouze pro určitý vysoce rizikový software. Space Shuttle software mě napadne. Jejich produktivita je však řádově několik řádků denně. Pochybuji, že to váš šéf chce.

Tento software neobsahuje chyby. Je to perfektní, stejně dokonalé jako lidské bytosti. Zvažte tyto statistiky: poslední tři verze programu - každá 420 000 řádků - každá měla pouze jednu chybu. Posledních 11 verzí tohoto softwaru mělo celkem 17 chyb.

Vezměte upgrade softwaru a umožněte raketoplánu navigovat pomocí Global Positioning Satellites, což je změna, která zahrnuje pouze 1,5% programu, nebo 6 366 řádků kódu. Specifikace pro jednu změnu běží 2 500 stránek, objem silnější než telefonní seznam. Specifikace aktuálního programu vyplní 30 svazků a spustí 40 000 stránek.

124
CodesInChaos

"Zero-bug programátor" je oxymoron, jako tichý zpěvák, ale za posledních zhruba 60 let programování vyprodukovalo několik destilovaných kousků moudrosti, díky nimž se stanete lepším programátorem, jako například:

  • Buďte pokorní - vy a budete dělat chyby. Opakovaně.
  • Buďte si plně vědomi omezené velikosti lebky. Přistupujte k úkolu s plnou pokorou a vyhýbejte se chytrým trikům jako mor. [Edsger Dijkstra]
  • Boj kombinatorický výbuch
  • Zbavte se proměnlivého stavu (pokud je to možné). Ano, naučte se funkční programování.
  • Snižte počet možných cest kódů
  • Pochopte (velikost) velikosti vstupních a výstupních prostorů (vašich funkcí) a pokuste se je zmenšit, abyste se dostali stále blíže k 100% testovacímu pokrytí
  • Vždy předpokládejte, že váš kód nefunguje - dokažte to jinak!
98
Maglob

TDD

Smyslem TDD je, že nepíšete jediný řádek kódu, pokud neexistuje test vyžadující tento řádek kódu. A aby to bylo do extrému, vždy začnete vyvíjet novou funkci psáním akceptačního testu. Zde jsem zjistil, že psaní okurka test stylů je ideální.

Přístup TDD přináší přinejmenším dvě výhody.

  • Celý kód je napsán tak, aby vyřešil specifickou funkci, takže nedošlo ke zbytečné nadprodukci.
  • Kdykoli změníte existující řádek kódu, pokud porušíte funkci, budete upozorněni

To neprokazuje nulové chyby, protože by to bylo nemožné (již bylo poukázáno na nespočet dalších odpovědí). Ale poté, co jsem se naučil TDD a stal se v něm dobrým (ano, je to také dovednost, která vyžaduje praxi), mám mnohem větší důvěru ve svůj vlastní kód, protože je důkladně testován. A co je důležitější, mohu změnit existující kód, kterému úplně nerozumím, aniž bych se obával funkčnosti.

Ale TDD vám nepomůže celou cestu. Nemůžete napsat kód bez chyb, pokud nerozumíte důkladně architektuře systému a úskalím této architektury. Např. Pokud píšete webovou aplikaci, která zpracovává více požadavků současně, musíte vědět, že nemůžete sdílet mutabilní data mezi více požadavky (nespadejte do pasce nováčků a ukládejte do mezipaměti mutabilní data pro zlepšení výkonu).

Věřím, že vývojové týmy, které jsou v TDD dobré, dodávají kód s nejmenšími vadami.

25
Pete

Věc je, že chyby jsou věci, které neuznáváte . Pokud nemáte nějaké encyklopedické znalosti programovacího jazyka/kompilátoru a všech prostředí, ve kterých bude vaše aplikace spuštěna, nemůžete očekávat, že vytvoříte 100% bezchybný kód.

Počet chyb můžete snížit pomocí mnoha testů, ale nakonec bude pravděpodobně nějaký okrajový případ, který nebude účtován. Joel Spolsky napsal obzvláště pěkný článek o oprava chyb .

19
user7007

Ano, je nemožné mít v kódu nikdy chybu, ale není možné mít méně chyb. Postoj, že „To je hloupé, vždycky budete mít chyby“ je jen policajt, ​​aby nedošlo ke snížení počtu chyb ve vašem kódu. Nikdo není dokonalý, ale měli bychom a měli bychom se snažit být lepší. Ve svém vlastním úsilí o zlepšení jsem našel následující body užitečné.

  • To není snadné. Přes noc se nezlepšíte. Takže se nenechte odradit a nevzdávejte se.
  • Pište méně a chytřejší. Méně kódu je obvykle lepší kód. Je přirozené chtít plánovat dopředu a pokusit se vytvořit úžasné designové vzory, ale z dlouhodobého hlediska jen psaní toho, co potřebujete, šetří čas a zabraňuje chybám.
  • Složitost je nepřítel. Méně se nepočítá, pokud se jedná o nejasný komplikovaný nepořádek. Kód golf je zábava, ale je to peklo pochopit a horší peklo ladit. Kdykoli píšete komplikovaný kód, otevíráte se světu problémů. Udržujte věci jednoduché a krátké.
  • Složitost je subjektivní. Kód, který byl kdysi komplikovaný, se stane jednoduchým, jakmile se stanete lepším programátorem.
  • Zkušenosti záleží. Jedním ze dvou způsobů, jak se stát lepším programátorem, je praktikování. Praxe NENÍ psát programy, které umíte psát s lehkostí, je to psaní programů, které trochu bolí a nutí vás myslet.
  • Dalším způsobem, jak se zlepšit, je číst. Existuje mnoho tvrdých témat v programování se učit, ale nikdy se nebudete moci učit pouhým programováním, musíte je studovat. Musíte si přečíst těžké věci. Věci, jako je bezpečnost a souběžnost, jsou nemožné, protože se naučíte správně pouhým napsáním kódu, pokud se nechcete učit odstraňováním katastrof. Pokud mi nevěříte, podívejte se na stránky epických bezpečnostních problémů, jaké měl gawker. Kdyby si našli čas na to, aby se naučili, jak správně zabezpečit bezpečnost, a ne jen aby udělali něco, co by fungovalo, nepořádek by se nikdy nestal.
  • Přečtěte si blogy. Existuje spousta zajímavých blogů, které vám poskytnou nové a zajímavé způsoby, jak se podívat a přemýšlet o programování, které vám pomohou ...
  • Naučte se špinavé detaily. Drobné podrobnosti o tom, jak temné části vašeho jazyka a aplikace pracují, jsou velmi důležité. Mohli by držet tajemství, která vám pomohou vyhnout se psaní komplikovaného kódu, nebo to mohou být části, které mají vlastní chyby, kterým se musíte vyhnout.
  • Zjistěte, jak si uživatelé myslí. Někdy jsou vaši uživatelé vyrovnaní a budou s vaší aplikací pracovat způsobem, kterému nerozumíte a nemůžete předvídat. Musíte se dostat do jejich hlav natolik, abyste věděli o podivnějších věcech, které by mohli vyzkoušet, a ujistěte se, že vaše aplikace to zvládne.
17
AmaDaden

Nulové chyby? Zní to jako potřebujete LISP (sledujte skeptickou cestu a vyhýbejte se hudebnímu videu).

Je mimořádně obtížné dosáhnout kódu bez chyb v běžných kódovacích prostředích (Java, C #, PHP atd.). Zaměřil bych se na produkci dobře otestovaného a recenzovaného kódu v krátkých kontrolovaných iteracích.

Zachování kódu tak jednoduchého, jak jen můžete , vám pomůže vyhnout se chybám.

Ujistěte se, že používáte nástroje pro analýzu kódu (např. FindBugs , PMD atd.), které - v kombinaci s přísnými varováními kompilátoru - odhalí nejrůznější problémy s vaším kódem. Vezměte na vědomí, co vám říkají, opravdu se snažte porozumět tomu, co je povahou chyby, a poté podnikněte kroky ke změně svého programovacího idiomu tak, aby se kódování cítilo nepřirozeně způsobem, který tuto chybu znovu zavede.

8
Gary Rowe

Osobně si myslím, že snaha o programování bez chyb se zdá být dražší (v čase i penězích). Abyste dosáhli nulové chyby nebo dokonce téměř nulové chyby, musíte mít vývojáře důkladně vyzkoušeni. To znamená, že regresní test vše před odesláním kódu pro kontrolu opravy. Tento model mě nezdá být nákladově efektivní. Je lepší, když vývojáři provádějí důsledné testování a důkladné testování necháte na týmu QA. Zde je proč:

  • Vývojáři sají při testování. Je to pravda a vy to víte. (Jsem vývojář!) Dobrý tým QA vždy najde případy Edge, na které vývojáři nikdy nepřemýšlejí.
  • Vývojáři jsou dobří v kódování. Nechte je, aby se vrátili k tomu, v čem Excel (a obvykle to, co i přesto dávají přednost.)
  • Tým QA může najít chyby související s více vývojovými úkoly najednou.

Přijměte, že při psaní kódu budou zaznamenány chyby. To je důvod, proč máte proces QA, a to vše je součástí vývoje. To samozřejmě neznamená, že něco pošlete, jakmile napíšete poslední středník. Stále musíte zajistit kvalitu své práce, ale můžete to přehánět.

Kolik profesí můžete pojmenovat tak, aby jejich úkol byl vždy proveden hned hned, aniž byste provedli vzájemné hodnocení a/nebo testování?

8
Sebastien Martin

Všechny "Nekódovat vůbec." odpovědi zcela chybí. Také se váš šéf rozhodně nezdá být blbec!

Nedokážu si vzpomenout, jak často jsem viděl programátory, kteří prostě nevěděli, co jejich kód dělá. Jejich jediný vývojový philosohpy vypadal jako pokus a omyl (a často také kopírovat/vložit/upravit). Zatímco pokus a omyl je platný způsob, jak řešit některé problémy, často můžete analyzovat problémovou doménu a poté použít velmi specifické řešení založené na vašem porozumění nástrojům, které používáte a s trochou disciplíny a pečlivosti nebudete mít problém vyřešil pouze problém, ale také většina rohových případů (potenciální chyby) před jeho prvním nasazením. Můžete zaručit, že kód je bez chyb? Samozřejmě že ne. Ale s každou chybou, se kterou se setkáte nebo o ní přečtete, ji můžete přidat k věcem, o kterých byste mohli chtít přemýšlet, až něco napíšete/změníte. Pokud tak učiníte, získáte následně mnoho zkušeností s tím, jak napsat kód, který je téměř bez chyb. - Existuje spousta zdrojů, jak se stát lepším programátorem, který vám může pomoci na cestě ...

Osobně bych nikdy neučinil kód, kde nedokážu vysvětlit každý jednotlivý řádek. Každý řádek má důvod být tam, jinak by měl být odstraněn. Samozřejmě někdy uděláte předpoklady vnitřního fungování metod, které voláte, jinak byste museli znát vnitřní logiku celého rámce.

Váš šéf má zcela pravdu, když říká, že byste měli rozumět výsledkům a dopadu kódu, který píšete, na existující systém. Objeví se chyby? Ano, samozřejmě. Tyto chyby však budou způsobeny neúplným porozuměním systému/nástrojů, se kterými pracujete, a při každé opravě chyb budete mít lepší pokrytí.

8
Patrick Klug

Jak již ostatní připomínky již správně zdůraznily, neexistuje žádný netriviální software bez chyb.

Pokud chcete testovat software vždy mějte na paměti, že testy mohou prokázat pouze přítomnost chyb, nikoli jejich nepřítomnost.

V závislosti na vaší doméně práce můžete vyzkoušet formální ověření softwaru. Pomocí formálních metod si můžete být jisti, že váš software přesně vyhovuje specifikaci.

To samozřejmě neznamená, že software přesně dělá to, co chcete. Vypracování úplné specifikace není téměř vždy možné. V zásadě přesouvá místo, kde se mohou vyskytnout chyby, z implementace do specifikace.

Takže v závislosti na vaší definici „chyb“ můžete vyzkoušet formální ověření nebo se pokusit najít tolik chyb, kolik můžete ve svém softwaru.

7
FabianB

Buď nepíšete nic složitějšího než "Hello World!" nebo pokud každému řeknete, aby ho nikdy nepoužíval.

Zeptejte se svého šéfa na příklady tohoto tzv. Bezchybného kódu.

6
JeffO

Souhlasím s ostatními. Zde je návod, jak bych k problému přistoupil

  • Získejte testera. Podívejte se na Joelův test, proč.
  • Používejte knihovny značně; pravděpodobně byly lépe odladěny. Jsem velkým fanouškem CPAN pro Perla.
5
Brian Carlton

Můžete se snažit být programátorem nulových chyb. Snažím se být nulovým programátorem chyb, kdykoli píšu kód. Nicméně ne

  • zapojit více technik testování (jiné než ATDD)
  • vytvářet formální ověření našeho softwaru
  • mít samostatný tým QA
  • provádět tvrdou analýzu každé změny provedené v kódové základně
  • používat jazyk, který více směřuje k bezpečnosti a opatrnosti

Nedělám tyto věci, protože jsou nákladově zakázané za software, který píšu. Kdybych tyto věci udělal, pravděpodobně bych byl dále směrem k nulovým chybám, ale nedalo by to smysl podnikání.

Vytvářím interní nástroje, které velká část naší infrastruktury používá. Moje standardy pro testování a kódování jsou vysoké. Existuje však rovnováha. Neočekávám žádné chyby, protože nemůžu přimět lidi, aby vložili takový čas do jednoho kusu práce. Věci se mohou lišit, pokud jsem vytvářel software pro ovládání rentgenového stroje, proudových motorů atd. Pokud se můj software zlomí, na lince nejsou žádné životy, takže se nezabýváme takovou úrovní jistoty.

Úroveň jistoty bych přizpůsobil zamýšlenému použití softwaru. Pokud píšete kód, který bude používat NASA raketoplán, možná je přijatelná tolerance nulové chyby. Stačí přidat spoustu dalších a velmi drahých praktik.

5
dietbuddha

Myslím, že dobrým prvním krokem k tomu, abyste se stali programátorem „nulové chyby“, je změna vašeho přístupu k chybám. Místo toho, aby říkali věci „dochází,“ „získejte lepší QA a testery,“ nebo „vývojáři sají testy,“ řeknou:

Chyby nejsou přijatelné a udělám vše, co bude v mé moci, abych je odstranil.

Jakmile se to stane vaším postojem, chyby rychle klesnou. Při hledání způsobů, jak odstranit chyby, narazíte na vývoj zaměřený na testy. Najdete zde spoustu knih, blogových příspěvků a lidí nabízejících bezplatné rady ohledně lepších technik. Uvidíte důležitost zlepšování svých dovedností pomocí praxe (jako je kódování katas nebo zkoušení nových věcí doma). Začnete pracovat lépe, protože začnete pracovat na svém řemesle doma. A doufejme, že jakmile uvidíte, že je možné napsat dobrý software, vaše vášeň pro vaše řemeslo poroste.

4
Darren

V jistém smyslu má váš šéf pravdu. Je možné napsat software, který se blíží nulovým chybám.

Problém je ale v tom, že náklady při psaní (téměř) programů s nulovou chybou jsou neúměrně vysoké. Musíte dělat věci jako:

  • Použijte formální specifikace svých požadavků. Formální, jako při použití Z nebo VDM nebo nějaké jiné matematicky zdravé notace.

  • Použijte techniky dokazování věty k formálnímu prokázání, že váš program implementuje specifikaci.

  • Vytvářejte rozsáhlé soupravy jednotek a regrese a testovací soupravy systému, které testují chyby v každém směru. (A to samo o sobě nestačí.)

  • Nechte mnoho lidí zkontrolovat požadavky (formální i neformální), software (a důkazy). testy a nasazení.

Je velmi nepravděpodobné, že váš šéf je připraven zaplatit za všechno tohle ... nebo se vyrovnat s časem, který to všechno potřebuje.

2
Stephen C

Dosáhl jsem stavu „nulové chyby“. Řeknu svým uživatelům, že je to nezdokumentovaná funkce, nebo žádají o novou funkci, a proto je to vylepšení. Pokud žádná z těchto odpovědí není přijatelná, pouze jim řeknu, že nerozuměli jejich vlastním požadavkům. Nejsou tedy žádné chyby. Programátoři jsou perfektní.

1
angryITguy

Zde je postup pro vytvoření programu bez chyb:

  1. Nikdy nezačněte kódovat, pokud nemáte pro svou funkci NEBEZPEČNÉ SPECIFIKACE.
  2. NEZKOUŠEJTE, nebo pokud NESOUHLASÍTE NA ZKOUŠENÍ, abyste zachytili vady softwaru.
  3. Aplikujte všechny ZPĚTNÉ chyby z defektů objevených během testování, kontroly a výroby na proces a vývojáře, kteří vložili defekt na prvním místě. Ihned po zjištění závad zlikvidujte všechny vadné komponenty. Aktualizujte si své kontrolní seznamy a přeškolte své vývojáře, aby se už nedovolili dělat chyby.

Testování může prokázat pouze to, že máte chyby, ale obvykle je zbytečné dokazovat opak. Co se týče zpětné vazby - pokud máte stroj na výrobu mincí, který vyrábí mince a průměrně každých 10 s mincí, má vadu. Tuto minci můžete vzít, vyrovnat a znovu vložit do stroje. mince, která z recyklovaného blanketu nevyjde, nebude tak dobrá, ale možná přijatelná. každých 100s coin bude muset být znovu razítkem dvakrát a tak dále. Bylo by snadnější opravit stroj?

Lidé bohužel nejsou stroje. Chcete-li vytvořit dobrý programátor bez vad, musíte investovat spoustu času, školení a opakování všech provedených vad. Vývojáři musí být vyškoleni v metodách formálního ověřování, které se často obtížně učí a používají v praxi. Proti tomu také pracuje ekonomika vývoje softwaru - investovali byste 2 roky do školení programátora, který může udělat méně vad, jen aby ho viděl skákat k jinému zaměstnavateli? Můžete si koupit stroj, který vyrábí dokonalé mince, nebo si najmout dalších 10 opic kódu a vytvořit spoustu testů za stejnou cenu. Tento vyčerpávající proces můžete vnímat jako svůj „stroj“, vaše aktivum - investice do rozsáhlého školení vynikajících vývojářů se nevyplatí.

Brzy se naučíte, jak vyvinout software v přijatelné kvalitě, ale pravděpodobně nikdy nebudete ten, kdo je bez závad, a to z jednoduchého důvodu, že pro vývojáře, kteří vytvářejí perfektní kód, neexistuje trh, protože je pomalý.

1
Alexei Polkhanov

Pokud předpokládáme, že velké softwarové domy vědí , jak získat špičkové vývojáře (jako v programátoru nulových chyb ), můžeme odečíst tento software společnosti Microsoft musí být bez chyb. Přesto víme, že to není daleko od pravdy.

Vyvíjejí svůj software a když dosáhnou určité úrovně chyb s nízkou prioritou, jednoduše vydají produkt a vyřeší je později.

Pokud nevyvíjíte něco složitějšího než jednoduchá kalkulačka, není možné vyhnout se chybám společně. Peklo i NASA má redundanci na svých vozidlech a chybách. Přestože mají mnohem přísnější testování, aby se zabránilo katastrofickým selháním. Ale i přesto mají ve svém softwaru chyby.

Chyby jsou nevyhnutelné stejně jako se lidská povaha mýlí.

Nemít žádné chyby je jako mít 100% bezpečný systém. Pokud je systém 100% bezpečný, rozhodně už není užitečný (pravděpodobně leží uvnitř tun a tun betonu a není vůbec spojen s vnějškem. Není zapojen ani bezdrátově. Stejně jako neexistují dokonale zabezpečené systémy , neexistuje žádný složitý systém bez chyb.

0
Robert Koritnik

Program defenzivně: http://en.wikipedia.org/wiki/Defensive_programming

Pokud někdo dodržuje zásady programování defenzivně, budou změny snadno sledovatelné. Zkombinujte to s přísnými hlášeními o chybách během vývoje a spolehlivou dokumentací, jako je tomu u doxygenu, a měli byste být schopni přesně vědět, co celý váš kód dělá, a velmi účinně opravit všechny chyby, které se objeví.

0
Jason McCarrell

Mohlo by to být výsledkem nedorozumění dobré metodiky, a nikoli pouze generické kostí?

Co tím myslím je, že je možné, že váš šéf slyšel o „metodika nulové vady“ (viz oddíl č. 5) a neobtěžoval se pochopit, co to znamená?
Samozřejmě je pro vedení nevhodné odkládat vývoj nových funkcí ve prospěch chyb, které byste neměli vložit ...
A samozřejmě to ohrožuje jeho bonus, takže ho samozřejmě nezískáte, protože „dobří programátoři nemají chyby“ ...

Je dobré vytvářet chyby, pokud je můžete najít a je opravit (samozřejmě z rozumu).

0
AviD

Jedním ze základních konceptů testování softwaru je, že si NIKDY nemůžete být naprosto jisti, že program je dokonalý. Můžete to potvrdit navždy, ale to nikdy neprokáže, že program je kompletní, protože se rychle stává nemožným dokonce otestovat všechny kombinace vstup/proměnná.

Váš šéf vypadá jako jeden z těch, kteří „nerozumí tomu, co je na programování tak těžké, od pouhého psaní“

0
SpacePrez