it-swarm-eu.dev

Upřímně, dáváte přednost kódování Cowboy?

Většina programátorů bránících metodologicky korektní metody jako Agile, Waterfall, RUP atd. Někteří z nich se řídí metodikou, ale ne všichni. Upřímně řečeno, pokud si můžete vybrat metodologii, určitě byste šli do mainstreamových „správných“ metodik nebo byste upřednostňovali „jednodušší“ metodologii, jako je kovbojské programování? Proč?

Vím, že to záleží. Vysvětlete prosím, kdy chcete použít jednu nebo druhou. Prosím, řekněte, jaké výhody vidíte v kódování Cowboy.

Více informací o kódování Cowboy na Wikipedii

68
Maniero

Myslím, že téměř každý zkušený programátor prošel třemi fázemi a některé projdou čtyřmi:

  1. Cowboy coders nebo nuggets nevím nic o designu nic a nepovažuj to za zbytečnou formalitu. Pokud pracují na malých projektech pro netechnické zúčastněné strany, může jim tento postoj chvíli sloužit; to dostane věci hotovo, zaujme šéfa, přiměje programátora, aby se cítil dobře o sobě, a potvrzuje myšlenku, že ví, co dělá (i když ne).

  2. Astronauti architektury byli svědky selhání jejich prvních projektů s míčky z příze, které se přizpůsobily měnícím se okolnostem. Všechno musí být přepsáno a aby se v budoucnu zabránilo potřebě dalšího přepisu, vytvoří vnitřní platformy, a nakonec utratí 4 hodiny denně na podporu, protože nikdo jiný nechápe, jak je správně používat.

  3. Kvazi-inženýři se často mýlí s skutečnými , vyškolenými inženýry, protože jsou skutečně kompetentní a rozumí některé technické principy. Jsou si vědomi základních inženýrských a obchodních konceptů: Rizika, NI, UX, výkon, udržovatelnost atd. Tito lidé vidí design a dokumentaci jako kontinuum a jsou obvykle schopni přizpůsobit úroveň architektury/designu požadavkům projektu.

    V tomto bodě se mnozí zamilovali do metodik, ať už jsou agilní, vodopád, RUP atd. Začnou věřit v absolutní neomylnost a dokonce nutnost těchto metodik, aniž by si to uvědomili v skutečné pole softwarového inženýrství, jsou to pouze nástroje, nikoli náboženství. A bohužel jim to brání v tom, aby se někdy dostali do závěrečné fáze, což je:

  4. Duct páskové programátory AKA gurus nebo vysoce placení konzultanti vědět, jakou architekturu a design budou používat do pěti minut po vyslechnutí požadavků projektu. Veškerá práce na architektuře a designu se stále děje, ale je to na intuitivní úrovni a probíhá tak rychle, že by ji netrénovaný pozorovatel zaměnil za kódování kovboje - a mnoho .

    Obecně se tito lidé zabývají vytvářením produktu, který je „dost dobrý“, a tak jejich práce mohou být trochu nedostatečně upraveny, ale jsou mil od špagetového kódu produkovaného kovbojskými kodéry. Nuggets nemohou tyto lidi identifikovat, když o nich řeknou , protože pro ně všechno, co se děje v pozadí, prostě neexistuje.

Někteří z vás si pravděpodobně budou myslet v tuto chvíli, že jsem na tuto otázku neodpověděl. Je to proto, že samotná otázka je chybná. Cowboy kódování není volba , je to úroveň dovednosti a vy si nemůžete vybrat, že budete cowboy coderem víc, než si můžete vybrat být negramotný.

Pokud jste kovbojský kodér, nevíte nic jiného.

Pokud jste se stali astronautem architektury, jste fyzicky a psychologicky neschopní vyrábět software bez designu.

Pokud jste kvazi-inženýr (nebo profesionální inženýr), pak dokončení projektu s malým nebo žádným předním návrhovým úsilím je vědomou volbou (obvykle kvůli absurdním termínům), která musí být zvážena proti zjevným rizikům a podniknuta pouze poté, co se na nich zúčastněné strany dohodnou (obvykle písemně).

A pokud jste programátor s páskovými pásky, pak nikdy neexistuje žádný důvod k „kovbojskému kódu“, protože můžete vytvořit produkt kvalitní stejně rychle.

Nikdo preferuje kovbojské kódování před jinými metodikami, protože to není metodika. Je to ekvivalent vývoje softwaru pro tlačítka rozdrcení ve videohře. Je to v pořádku pro začátečníky, ale kdokoli, kdo se pohyboval kolem této fáze, to prostě neudělá. Mohli by udělat něco, co vypadá podobně , ale nebude to totéž.

204
Aaronaught

Ano.

Také raději nechávám ponožky na podlaze, kde jsem je sundával, můj stůl zakrytý výtisky a starými svačinkami, můj dřez plný špinavých jídel a postel nevyrobená.

Dovolenou plánovanou předem nepovažuji za řádnou dovolenou, jídlo konzumované s ohledem na výživu správné jídlo nebo pobyt na známých trasách správnou turistiku.

Ráda se bavím, jsem překvapená, učím se nové věci, dělám chyby a nikdy si nebudu zcela jistá, jestli se mi to vrátí. A někdy je tento postoj přesně to, co je nutné k tomu, aby se projekt dostal ze země ...

... ale většinu času je to prostě nezodpovědné. Až tanec skončí, bude mu plat zaplacen ... Zapomeňte na to, co je v nebezpečí.

46
Shog9

Máte přesně pravdu. Tento přístup „kovbojského programování“ může první revizi kódu urychlit, ale časová úspora bude více než ztracena díky:

  • Další chyby
  • K nalezení chyb, které byste stejně měli, byste potřebovali další čas
  • Budete muset zpětně analyzovat váš kód, abyste si pamatovali, co jste udělali, když potřebujete provést změnu za šest měsíců
  • Extra čas strávený školením dalších vývojářů, kteří potřebují pracovat na vašem kódu
  • Nemáte protokol revizí, na který byste se měli podívat, až provedete změnu, která něco rozbije
  • Nemáte moduly, které můžete snadno znovu použít v pozdějších projektech
  • A dál a dál a dál

Jak Neil Butterworth zmínil ve své odpovědi, někdy musíte udělat to, co musíte udělat. Obecnou praxí však je, že se co nejrychleji vyhýbat kódu, aniž byste museli trávit čas řízením zdrojových kódů, vzory, dokumentací atd., Je velmi špatný zvyk.

Dobré pro vás, když analyzujete své spolupracovníky a zvažujete, zda jsou jejich návyky prospěšné nebo škodlivé místo slepého jednání tak, jak to dělají.

31
Warren Pena

To opravdu přichází na otázku, zda můžete věci implementovat správně, aniž byste měli pevnou strukturu a spoustu času stráveného v plánování.

Vyhodím tu něco, co by mohlo být opravdu nepopulární: zákazníci obecně chtějí, aby se věci řešily kovbojským způsobem.

To znamená, že chtějí požádat, aby se něco stalo, a nechat někoho, aby na to skočil, provedl to a dostal to tam. Žádné řízení projektů, schůzky, konferenční hovory nebo formuláře. Prostě to udělej. Nikdy jsem neměl zákazníka říct: "Hej, to bylo uděláno příliš rychle pro naše chutě, bychom ocenili, kdybyste tam dal trochu vodopádu nebo něco tam příště".

Metodiky a struktura týmu jsou navrženy tak, aby rovaly podmínky projektu a získaly různé úrovně vývojářů na stejné stránce a stejným způsobem pracovaly na stejných cílech.

Úspěšní kovbojové, se kterými jsem pracoval, jsou schopni:

  • Najděte nejjednodušší způsob, jak něco rychle implementovat
  • Vědět, v jakém okamžiku se to zlomí
  • Napište čistý, čitelný a přímý kód
  • Předpovídejte, jak jej uživatelé budou používat, zneužívat a porušovat
  • Měřítko to/abstraktní to na správných místech, a ne jít na architekturu astronaut na to
  • Vědět, kde a jak řešit případy a výjimky Edge

Lidé, jako je tento, produkují skutečně skvělé výsledky s velmi malou režií správy a struktury, ale jsou vzácní.

29
Brandon

EDIT: Pro budoucí použití je moje odpověď na otázku jiná , která byla sloučena do této. Je to docela na místě, ale to nebylo moje volání.


Je prostě líná, arogantní, ignorantská a extrémně sobecká. Toto chování je bezohledné.

Myslím, že nejde o to, že používá nekonvenční nebo možná zastaralou metodiku. Jen vědomě používá žádné . Žádné standardy. Žádné zajištění kvality. Ne, vůbec. Odkud očekává kvalitu softwaru? Stromy?
Je zábavné, že ve skutečnosti popírá zkušenosti lidí, které citujete, když jí to zjevně postrádá. Poskytnutí ověřitelných a relevantních argumentů pro zpochybnění jejich nároků je platné. Ale snažit se je zdiskreditovat popřením jejich zkušeností není.

Ale hlavní bod je: Kolik času zabere kontrola verzí?
Pokud nemůže být přesvědčena, aby investovala 5 sekund každou chvíli, měli byste ji vzít na svého šéfa. Řízení verzí není volitelné. Tečka.

A jakmile ji budete mít pomocí řízení verzí, můžete snadno sledovat, které chyby představila. A ať je opraví . Je to její nepořádek, proč byste to měli vyčistit? Pokud si myslí, že její přístup je lepší, nechte ji udělat - celou cestu .
Za předpokladu, že to skutečně dokáže (v rozumné době), máte stále problém: týmová práce s ní je téměř nemožná. A to je něco, co budete muset vyřešit buď tím, že ji přesvědčíte (což zní nepravděpodobně), necháte ji odejít (kvůli vaší společnosti) nebo odejít (kvůli vaší rozumnosti).
Ale její selhání je na prvním místě mnohem pravděpodobnější a mělo by rozhodně prokázat váš názor. A pak se začne řídit osvědčenými postupy, jak to dělá mnoho lidí se spoustou zkušeností.

13
back2dos

Záleží úplně na tom, zda pracuji samostatně nebo v týmu.

Pokud pracuji v týmu, některé jsou vyžadovány úmluvy a dohody - každý v týmu musí dodržovat některé společně dohodnutý standard, aby pracoval na dosažení společného cíle tak, aby jejich úsilí je kompatibilní.

Ale pokud pracuji sám, pak samozřejmě chci být kovbojem. Všechny skvělé výtvory na světě byly vynalezeny jedinou myslí, nebo maximálně dvěma, kovbojským stylem. Jen abychom jmenovali alespoň některé:

  • Klasická mechanika? Cowboy Isaac Newton, později přírůstky od Leibniz, Lagrange, Hamilton.
  • Letoun? Cowboys Wright.
  • Teorie relativity? Kovboj Albert Einstein.
  • Základní věda o počítačích? Cowboy Alan Turing.
  • Tranzistor? Cowboys Walter Brattain a John Bardeen.

Týmy dokážou postupná vylepšení a sestavování nových systémů založených na ověřených receptech poměrně rychle (za předpokladu, že jsou vedeny dobře), ale je vzácné slyšet o skutečném vynálezu týmu. Týmová práce a metody, které vyžaduje, mají své přednosti, ale také kódování kovboje.

11
Joonas Pulakka

Závisí na problému. Dobrý vedoucí vývojář bude psát velmi kompaktní, jednoduchý a robustní kód, který je velmi stabilní a používá všechny osvědčené postupy, aniž by proplétal stránkami dokumentace a spoustou různých vzorů a paradigmat. Ale bude také vědět, kdy si může dovolit dělat takové věci.

Byl bych šokován, kdyby vzal nový problém a začal navrhovat aplikaci, která by vyžadovala mužské měsíce od nuly. Ale pokud se jedná o plugin, jednoduchý nástroj, který můžete napsat za 2 hodiny, funkce, která provádí určitou konverzi a není určena pro opakované použití, design a vzory jsou ve skutečnosti dobré pouze pro ztrátu času.

Také myslím, že velká část návrhu byla již zpracována v pozadí vlákna někde uvnitř hlavy vývojářů.

Musíte začít dělat starosti, když vedoucí vývojář začne chrlit třídy složitého systému nebo nových aplikací od nuly, a to bez plánování.

7
Coder

Závisí to na okolnostech. Například po některých katastrofálních obchodních skandálech několik elektronických burz trvalo na tom, že do všech obchodů byly přidány vlajky automatického obchodování. A to muselo být pro celý obchodní software uvnitř týdne. Myslím, že to muselo být provedeno - pokud tam vlajka nebyla, nemohl jsi obchodovat. Za takových okolností se všechny osvědčené postupy týkají rady - stačí jít (jak jsme říkali) „hacky, hacky, hacky“. Za těchto okolností je klíčové rychlé a přesné psaní kódu. Zejména proto, že nebyly k dispozici žádné testovací systémy.

6
Neil Butterworth

Podle mých zkušeností je kódování kravského chlapce S řízením zdroje nejlepším a nejbezpečnějším způsobem vývoje velkých softwarových systémů.

5
jojo

Tento druh člověka se nazývá hacker a obvykle to není bezplatný termín od profesionálů mezi námi.

Jak jste si všimli, čas ušetřený v designu, organizaci a kontrole je při ladění ztracen. A často při zjišťování, které vydání kódu bylo to, co bylo skutečně dodáno. Pokud to vůbec najdete!

Zjistil jsem, že tento druh lidí je příliš zabalený do sebe, myslím, že jsou příliš dobří na to, aby pracovali s „omezeními“, která musí ostatní trpět, a proto se s nimi neobtěžují, a že ztrácí ještě více času jako zbytek tým musí po nich uklidit. Také se příliš neúčastní procesu opravy chyb (to je úkol vývojáře údržby, dostatečně pod dovednostmi a talentem kodéra l33t).

Takže to může být běžný přístup jinde, ale u mě (a já jsem starší kodér, který má sklon k tomuto přístupu, ehm) to netrpíme. Nejde o to, že požadujeme spoustu procesů a postupů, ale trváme na minimálním množství organizace, řízení zdrojového kódu (což je upřímné, je krvavý východ a zatraceně užitečné!)

Kent Beck et al, jsou všichni profesionálové, kteří viděli, že staré postupy naložené procesem byly samy o sobě špatné, takže vytvořili nové metodiky pro organizování kódování, přičemž je stále udržují více orientované na řemeslo, a pak všem ostatním o tom - vydáváním knih (jak jinak jste to dělali tehdy před internetem?)

Zníte, jako byste to měli pravdu - nepřijímejte špatnou praxi jen proto, že to někdo jiný nemůže zaseknout. Váš týmový vedoucí nebo manažer by měl na této „rockové hvězdě“ tvrdě klesat, ale pokud nejsou .. dobře, stále vám to nebrání dělat správnou věc. Jednoduše od ní nepřiznávejte trýznivé praktiky, pokud ji zašroubuje (a bude!), Nechte ji vyčistit. Řídíte se dobrými postupy (a víte, jaké to jsou), aniž byste je nechali převzít na úkor produktivity kódování a budete dobří pro budoucnost.

Tady je esej od opravdu bystrého spisovatele. Neřeší to váš problém, ale dá vám několik vhledů, proč je to tak a možná pár tipů, jak s ním profesionálně jednat.

4
gbjbaanb

Myslím, že jeden z komentátorů měl pravdu - je to všechno o výsledcích.

Pokud osoba může produkovat dobrý produkt - něco, co dělá to, co má dělat, a je držovatelné a spolehlivé - pak na čem záleží, pokud jsou dodržovány formální metodiky nebo procesy ? Procesy jsou skvělé pro zajištění kvality podlahy, ale pokud už někdo pracuje nad tímto poschodím, procesy nepřidávají do rovnice nic. Příliš mnoho vývojářů v dnešní době, imo, si myslí, že bod programování je dodržovat procesy, na rozdíl od produkování dobrého produktu.

4
GrandmasterB

Možná najdete v mé odpovědi odpověď na přímně, dáváte přednost kódování kovbojů? Problém je v tom, že „kódování kovbojů“ znamená různé věci pro různé lidi a není to okamžitě zřejmé pro netrénované oko, kterou verzi vidíte.

Když se někdo může podívat na problém a okamžitě začít vyřazovat kód, rychle a přesně, znamená to, že může je znamením hlavního inženýra, který to viděl tisíckrát předtím a již zná nejlepší způsob, jak problém vyřešit.

Nebo to může být známka hodnostářského.

Řeknu vám jednu věc: Odmítnutí používat kontrolu verzí nebo psaní testů, protože jsou příliš „akademické“, je definitivně ne „senior“ nebo dokonce vzdáleně profesionální přístup. Takovou věc nikdy nikdy neuvidíte ve velkém softwarovém obchodě, jako je Microsoft nebo Google, a pravděpodobně to neuvidíte ve většině startupů nebo přiměřeně vyspělých podnikových týmů.

Rizika jsou prostě příliš velká. Co když váš počítač zemře přes noc? Nashledanou 3 roky produktivity. Dobře, takže si děláte zálohy; co se stane, když uděláte zásadní změnu, uvědomíte si, že to bylo úplně špatně a musíte to vrátit? To se děje i těm nejzkušenějším a nejtalentovanějším vývojářům, protože požadavky jsou špatné. Pokud neběžíte žádný druh kontroly verzí, budete točit svá kola v blátě. Byl jsem tam jednou a chtěl bych se vrátit nikdy .

Neexistuje žádná omluva - vytvoření úložiště trvá 10 minut a provedení potvrzení trvá 10 sekund. Tvoří asi 1% vaší celkové doby vývoje. Testy, pokud jste ve spěchu, mohou být snadno omezeni na 20-30 minut denně a přesto mohou být přiměřeně užitečné.

Nejsem fanouškem metodik Agile (všimněte si velkého písmene A), ale někdy musíte opravdu vyhrnout rukávy a začít psát zatracený kód. Viděl jsem lidi a týmy s „analýzou paralýzy“ a produktivita skutečně zasáhla viditelný zásah. Ale odvolání základních nástrojů našeho obchodu , jako je kontrola revizí a testy, je pro mě opravdu klinerem; tato osoba nepatří do vyšší pozice.

3
Aaronaught

Jedinou důležitou skutečností jsou dlouhodobé produktové výsledky týmu.

Existuje tvrzení, že tým zahrnující jednoho skvělého programátora (nebo více) přinese lepší výsledky než tým s ještě větším počtem průměrných programátorů, kteří kódují průměrným tempem.

Pokud kovboj produkuje věci, které běžní programátoři nemají (pro daný termín nebo specifikaci), a tým s kovbojem musí dokonce strávit pár týdnů/měsíců úklidem kovbojského nepořádku, mohou ještě skončit lepší výsledek dříve.

Pokud tým s kovbojem nemůže vyčistit (dokumentovat, ladit, integrovat, udržovat) nepořádek ani po mnoha měsících/rokech člověka, pak jakýkoli pokrok, který vytvořil kovboj, neposkytl týmu dlouhodobou výhodu.

Rozhodněte se a optimalizujte rozpis týmu.

Ne každý programátor pracuje (nebo by měl fungovat) stejným způsobem, pokud je konečný výsledek dobrý.

3
hotpaw2

Když si myslím, že „tradiční“ metodologie, myslím, že „vedení neví, jak rozumět vývojářům, takže místo toho, aby vstoupili do světa vývojářů a dostatečně pochopili, aby věděli, co se děje, přimějí vývojáře, aby vstoupili do jejich světa“.

V zásadě, když pomyslím na „Agilní“, myslím, že „děláte, co musíte udělat, abyste minimalizovali neefektivnost způsobenou více lidmi, kteří pracují společně.“ Takže jsem pevně v táboře, že „neexistuje nic jako Agilní metodologie , pouze soubor hodnot a principů “.

Jinými slovy, existují věci, které musíte udělat na velmi velkém projektu, a tam jsou věci, které musíte udělat na malých projektech, a tam jsou věci, které děláte na obou.

Například bych neměl víc než nejjednodušší počet nevyřízených projektů, na kterých pracuji sám ... Byl by to jen seznam úkolů. Pokud jsou nás dva, pravděpodobně bych tento seznam sdílel, ale ve velmi jednoduchém formátu (pravděpodobně jen poznámka uložená v našem úložišti kódu). Jakmile mám 3 nebo 4, hledám nějaký druh systému pracovních položek.

2
MIA

Ano, ale musíte to uznat, když to NEDĚLETE.

Na něčem malém jste pravděpodobně v pohodě, ale pokud máte něco složitého, nebezpečného, ​​omezeného atd., Musíte být schopni rozpoznat, kdy je správné provedení za čas navíc.

Také si myslím, že byste měli určitě přemýšlet Aaronaughtovou odpovědí. Kovboj znamená pro různé lidi různé věci.

2
Bill

Mám pocit, že vaše nechuť k jejímu stylu způsobuje, že jej mírně zkreslujete. Říkáte kovbojský přístup se platí za ladění - je to to, co se již děje, nebo je to váš předpoklad toho, jak bude hrát?

Spravedlivé zveřejnění - sám jsem senior vývojář a často se vzdávám formálního procesu navrhování a pokračování zkušeností. Nemít formální proces pro někoho, kdo je velmi zkušený v problémové oblasti, je docela běžné. Pokud jste problém vyřešili desítky časů, nepotřebujete formální proces znovu formulovat podobné řešení.

Formální proces se zabývá návrhem kódu - nechápu, proč by mělo být zavedeno více chyb, protože chybí formální proces. Jediným velkým problémem, který jsem ve vašem účtu četl, je to, že se nepoužívá kontrola revizí - což je nejen sobecké, ale přímo bezohledné jménem vývojáře. Ve skutečnosti se vůbec nezavazuje, nebo se prostě nezavazuje podle vzoru, který je podle vašich představ?

Nemít formální přístup k designu není v mé knize „kovbojské kódování“ (i když nepoužíváme kontrolu revizí). Zkušenost by měla být použita přesně na to - aby se zkrátil čas potřebný k nalezení „dostatečně dobrého“ řešení. Pamatujte, že musíte vyřešit problémy, které v současné době máte, a usnadnit změnu kódu, nikoli navrhovat budoucí scénáře, které by se nikdy neměly stát. Se zkušeností získáte dobrý pocit, jak to udělat velmi rychle.

1
Eran Galperin

Zdá se, že existují dva tábory - ti, kteří upřednostňují výsledky, a ti, kteří upřednostňují principy. Padám do druhé.

Jsem průměrný, ale patrně svědomitý programátor - můj hlavní problém při kódování --- mimo dokončení práce, je to, že pomáhám každému, kdo používá můj kód, aby JEJÍ vykonal práci. Nemohu říci, že jsem toho vždy dosáhl - ale to je to, o co se snažím.

Jistě, máte může mít hotrod ve vašem týmu - ale co se stane, když si vezmou pár týdnů dovolené a budete vyzváni, aby odladili svou práci, nebo k tomu přidali věci? Nakonec, cowboy programátoři nejsou týmoví hráči. Mohou vytvořit skvělý kód, ale pokud tým na nich závisí, pak je to nebezpečné.

1
sunwukung

Pouze při prototypování velmi jednoduchých funkcí.

Poté, co jednou udělal a zvážil správnou cestu, jsem příkopu kód a brát vážně.

1
Klaim

Udělal jsem to jednou na skutečném projektu (v době, kdy jsme to nazvali Samurai Programming, po sérii náčrtů Samurai Tailor v sobotu Night Live), a k mému úžasu to fungovalo dobře. Samozřejmě to, co jsem začal, bylo odpadky, takže tam bylo malé riziko, že se to zhorší.

Jsem však v srdci „čistý“ a nelíbí se mi vývojový styl „střílet z kyčle“.

Na druhou stranu, podle mého vkusu není nijak silně naladěný modus operandi. Chci jen plánovat, než budu jednat.

Celkově mám pocit, že množství formálního procesu, který je vhodný, závisí do velké míry na velikosti (velikost kódu, doba trvání projektu, počet vývojářů, druhy požadavků atd.) Projektu. Chci přísná a přísná kritéria pro lidi vyvíjející software pro avioniku nebo biomedicínské vybavení, např. Například u her je mnohem méně nevýhodných poruch, takže náklady a zátěž důsledných a metodických vývojových postupů nejsou ve skutečnosti odůvodněné.

1
Randall Schulz

Závisí to (do velké míry) na velikosti projektu. Na jedné straně, abyste dosáhli slušného výsledku, musíte mít design. Na druhou stranu, pokud je projekt dostatečně malý, že dokážete konceptualizovat celý design (i když většinu z nich), aniž byste jej zapisovali, kreslili diagramy atd., Pak jste pravděpodobně stejně dobře bez toho, že byste museli pracovat navíc dokumentování všeho, co děláte.

Téměř každý slyšel dost hororových příběhů, aby si uvědomil, že snaha skočit dovnitř bez jasné představy o tom, co děláte a kam se věci dějí, je receptem na katastrofu. Mnohem vzácnější je, že opak může být stejně katastrofální. Jen například většina z nás běžně píše malé nástroje v procesu programování. Psaní kompletní specifikace, testy, dokumentace často prostě nestojí za to. Existuje prahová hodnota, pod kterou se produkce nestojí za to - lidé často nechtějí znovuobjevovat kolo, ale v některých případech je snazší znovuobjevit, než se jim vyhnout.

V případech, jako je tento, je často je užitečné vytvářet knihovnu tak, aby bylo snadné provádět podobné úkoly. Díky tomu se front-end kód často stává tak triviální, že psaní (nebo modifikace) kódu pro to, co chcete, bude snazší než třídění, jak získat kompletní program, aby udělal to, co chcete. Vezměme si například exmaple, gnu odrážku s 50 a více různými vlajkami, z nichž mnohé interagují různými jemnými způsoby, takže jedinou rozumnou volbou je 1) nepoužívejte ji vůbec, nebo 2) rozhodněte se, že se vám líbí, co vám dává místo toho, abychom se snažili získat to, co jste původně chtěli.

1
Jerry Coffin

Nemyslím si, že cowboy kódování je senior přístup.

Jak již uvedli ostatní, při likvidaci kontroly verzí existuje skutečné nebezpečí. Přeskočení dokumentace a analýzy by také mohlo znamenat riskování doručení něčeho, co uživatel nechce. Jen můj názor, ale nemyslím si, že jdete od „kodéru k vývojáři“, pokud vše, co děláte, je kovbojský kód.

Ano, existují však výjimky, jaké zmiňuje Neil Butterworth. A v těchto situacích bych raději měl zkušeného vývojáře, který musí dělat kódování kovboje.

0
Bernard Dy

Považuji váš příspěvek za zajímavý. Často jsem sdílel názory s vaším předmětem a její pocit je, že příliš formalizované metody jsou potlačené. Jak poznamenal někdo jiný, pokud je génius a dokáže sledovat mnoho mentálních poznámek současně, aniž by zapomněl nebo se zmátl, pak je docela možné udržovat monolitický kus spleteného kódu a nechat ho dělat úžasné věci se zcela temnými změnami. . Do mozku lidí přichází určité duševní štěstí, které to dokáže - je to jako být ve vaší mysli Bohem malého vesmíru.

Inteligentní zaměstnavatelé se však tvrdě naučili, že nikdo kromě původního autora nikdy nemůže udělat pro tento kód nic užitečného. Pokud se programátor pohne dál, nakonec zbytečně ztrácí spoustu peněz a zjistí, že jedinou možností je přepsání (myslel jsem si, že to znamenalo úplnou ztrátu, ale v dnešní době si uvědomuji, že nezničíte vnitřní výsledek iterativní vývoj na úrovni externí funkčnosti).

Osobně mi nebude vadit mít někoho takového v týmu, protože v krizi by mohli udělat něco, o čem nikdo jiný neuvažuje.

Na druhou stranu buďte svou vlastní osobou a rozhodněte se sami, jaká je odpověď na vaši otázku, protože jediné, co je jisté, je to, že nikdo to přišel na to, co se týče vytváření softwaru. Je to jedna z věcí, která z ní dělá zajímavé pole ...

0
Aaron Anodide

Cowboy programování je docela jistý způsob, jak vytvořit velká koule bláta . Což, jak nepříjemné, jak to zní, má sklon dodávat ...

0

Myslím, že novější programátoři mají tendenci dělat nějaké věci cowboy kódování, když berou na aspekty projektu/oblasti, které nemusí mít mnoho zkušeností s, nebo když se snaží "jen dostat věci udělat" kvůli tlaku od šéfa, atd. Vím, že jsem tuto cestu určitě několikrát prošel, protože mi chybělo znalosti o správném vzorci, který jsem použil, a jen jsem „prolomil cestu“.

Rozdíl mezi mnou a osobou, na kterou si stěžujete, spočívá v tom, že obvykle brzy poté, co jsem si uvědomil, že jsem to mohl udělat lépe a udržet jej lépe udržovatelným, a obvykle mě to pobízí, abych se naučil více a zlepšoval své dovednosti (čtením knih/článků o předmět). Když se vracím k ladění některých z těchto hackovaných řešení, obvykle to považuji za bolest a více to přispívá k mému přání naučit se, jak to udělat „správnou cestou“. Myslím, že tato osoba, kterou popisujete, je v zásadě zaseknutá na infantilní úrovni sebekontroly a nechává to, aby se její vlastní ego dostalo do cesty ke skutečnému zlepšování svých schopností vývojáře softwaru, nezdá se, že by s někým, s kým bych chtěl pracovat.

0
programmx10

Ne, nikdy.

Vždycky provádím analýzu požadavků, přemýšlím o architektuře, navrhuji detaily a poté kóduji. I když doma pracuji samostatně pro osobní projekt.

A okamžitě bych vypálil vývojáře v mém týmu, kdyby pracoval v kovbojském stylu. Jsme inženýři a máme odpovědnost vůči zákazníkovi a uživatelům.

0
CesarGon