Francamente, preferisci la codifica di Cowboy? [chiuso]

Penso che quasi tutti i programmatori esperti abbiano attraversato tre livelli e alcuni ne analizzino quattro:

1. I codificatori dei cowboy o le nuggets non conoscono quasi nulla del design e lo considerano una formalità inutile. Se si lavora su piccoli progetti per le parti interessate non tecniche, questo atteggiamento può essere utile per un po '; Ottiene le cose fatte, impressiona il capo, fa sentire bene il programmatore e conferma l'idea di sapere cosa sta facendo (anche se non lo fa).

2. Gli astronauti di architettura hanno assistito ai fallimenti dei loro primi progetti di gomitolo di filato per adattarsi alle mutevoli circostanze. Tutto deve essere riscritto e per impedire la necessità di un'altra riscrittura in futuro, creano piattaforme interne e finisci per dedicare 4 ore al giorno all'assistenza perché nessun altro sa come usarli correttamente.

3. Quasi-engineers spesso si scambiano per effettivi , ingegneri addestrati perché sono competenti genuinamente e comprendono alcuni principi ingegneristici. Sono a conoscenza dei concetti di ingegneria e business sottostanti: rischio, ROI, UX, prestazioni, manutenibilità e così via. Queste persone vedono il design e la documentazione come un continuum e sono solitamente in grado di adattare il livello di architettura / design ai requisiti del progetto.

   A questo punto, molti si innamorano delle metodologie, che siano Agile, Cascata, RUP, ecc. Cominciano a credere nell'assoluta infallibilità e persino necessità di queste metodologie senza rendersi conto che nel attuale campo dell'ingegneria del software, sono solo strumenti, non religioni. E sfortunatamente, impedisce loro di arrivare alla fase finale, ovvero:

4. Programmatori di nastri conduttivi AKA guru o consulenti altamente pagati conoscono l'architettura e il design che useranno entro cinque minuti dopo aver sentito i requisiti del progetto. Tutto il lavoro di architettura e design è ancora in corso, ma è a livello intuitivo e sta accadendo così velocemente che un osservatore inesperto lo scambierà per codifica da cowboy - e molti lo fanno .

   Generalmente queste persone si occupano di creare un prodotto che è "abbastanza buono" e quindi i loro lavori potrebbero essere un po 'poco ingegnerizzati, ma sono miglia lontani dal codice spaghetti prodotto dai codificatori dei cowboy. I nugget non possono nemmeno identificare queste persone quando sono parlate di loro , perché per loro tutto ciò che sta accadendo in background non esiste.

Alcuni di voi probabilmente penseranno a voi stessi a questo punto che non ho risposto alla domanda. Questo perché la domanda stessa è difettosa. La codifica da cowboy non è una scelta , è un livello di abilità e non puoi scegliere di essere un codificatore di cowboy più di quanto tu possa scegliere di essere analfabeta.

Se sei un codificatore di cowboy, non sai in nessun altro modo.

Se sei diventato un astronauta di architettura, sei fisicamente e psicologicamente incapace di produrre software senza progettazione.

Se sei un quasi-ingegnere (o un ingegnere professionista), quindi il completamento di un progetto con uno sforzo di progettazione minimo o inesistente è una scelta consapevole (solitamente dovuta a scadenze assurde) che deve essere valutata rispetto ai rischi evidenti , e intrapreso solo dopo che le parti interessate hanno accettato (di solito per iscritto).

E se sei un programmatore di videocassette, non c'è mai motivo di "codice cowboy" perché puoi creare un prodotto di qualità altrettanto rapidamente.

Nessuno "preferisce" codificare i cowboy rispetto ad altre metodologie perché non è una metodologia. È l'equivalente di sviluppo del software dei pulsanti di ammucchiamento in un videogioco. Va bene per i principianti, ma nessuno che passi da quella fase semplicemente non lo farà. Potrebbero fare qualcosa che sembra simile ma non sarà la stessa cosa.

Sì.

Preferisco anche lasciare i calzini sul pavimento dove li ho tolti, la mia scrivania coperta di stampe e vecchie confezioni di snack, il mio lavandino pieno di piatti sporchi e il mio letto disfatto.

Non considero una vacanza programmata in anticipo per essere una vacanza adeguata, un pasto consumato con una mente verso un'alimentazione corretta, o su sentieri conosciuti.

Mi piace divertirmi, essere sorpreso, imparare cose nuove, commettere errori, e non essere mai abbastanza sicuro se riuscirò a tornare indietro. E a volte, quell'atteggiamento è esattamente ciò che è necessario per far decollare un progetto ...

... ma il più delle volte, è solo irresponsabile. Quando il ballo finisce, il piper sarà pagato ... Dimentica questo a tuo rischio e pericolo.

Hai esattamente ragione. Questo approccio di "programmazione da cowboy" può ottenere la prima revisione del codice più velocemente, ma i risparmi di tempo saranno più che persi grazie a:

• Altri bug
• Tempo aggiuntivo necessario per trovare gli errori che avresti comunque avuto
• Dovendo eseguire il reverse engineering del codice per ricordare cosa hai fatto quando è necessario apportare una modifica in sei mesi
• Ulteriore tempo dedicato alla formazione di sviluppatori aggiuntivi che devono lavorare sul tuo codice
• Non si dispone di un registro delle revisioni a cui guardare quando apporti una modifica che interrompe qualcosa
• Non avendo moduli puoi facilmente riutilizzarli in progetti successivi
• E avanti e avanti e

Come Neil Butterworth ha menzionato nella sua risposta, a volte devi fare quello che devi fare. Tuttavia, come pratica generale, no, sbattere il codice il più velocemente possibile senza il tempo speso per il controllo del codice sorgente, i modelli, la documentazione, ecc. È una pessima abitudine da accettare.

Buon per te per analizzare i tuoi colleghi e considerare se le loro abitudini sono benefiche o dannose invece di fare ciecamente come fanno loro.

Questo dipende in realtà dalla possibilità o meno di implementare le cose correttamente senza una struttura rigida in atto e un sacco di tempo consumato nella pianificazione.

Ho intenzione di lanciare qualcosa qui su questo che potrebbe essere davvero impopolare: i clienti in genere vogliono che le cose vengano gestite in modo da cowboy .

Cioè, vogliono chiedere che venga fatto qualcosa, e fare in modo che qualcuno vi salti sopra, eseguirlo e farlo fuori. Nessuna gestione di progetti, riunioni, chiamate in conferenza o moduli. Fallo e basta. Non ho mai avuto un cliente che dicesse "hey, questo è stato fatto un po 'troppo velocemente per i nostri gusti, lo apprezzeremmo se avessi messo una piccola cascata o qualcosa in là la prossima volta".

Le metodologie e la struttura del team sono progettate per livellare il campo di gioco di un progetto e ottenere vari livelli di sviluppatori sulla stessa pagina, lavorando per gli stessi obiettivi, allo stesso modo.

I "cowboys" di successo con cui ho lavorato sono in grado di:

• Identifica il modo più semplice per implementare rapidamente qualcosa
• Sapere a che punto si romperà
• Scrivi un codice pulito, leggibile e diretto
• Indovina in che modo gli utenti lo utilizzeranno, lo violeranno e lo romperanno
• Scala / estrai nei punti giusti, e non vai su astronauti dell'architettura su di esso
• Scopri dove e come gestire casi limite ed eccezioni

Persone come questa producono risultati davvero eccezionali con pochissimi costi di gestione e struttura, ma sono rari.

EDIT: per riferimento futuro, la mia risposta è per altro domanda, che è stata unita a questa. È abbastanza fuori luogo qui, ma non era la mia chiamata.

È solo pigra, arrogante, ignorante ed estremamente egoista. Questo comportamento è spericolato.

Voglio dire, non è che usi una metodologia non convenzionale o forse obsoleta. Usa consapevolmente nessuno . Nessun standard Nessuna garanzia di qualità. No a tutti. Da dove si aspetta la qualità del software? Alberi?
È strano che in realtà neghi l'esperienza delle persone che hai citato, quando lei ovviamente le manca. Fornire argomenti verificabili e pertinenti per mettere in discussione le loro affermazioni è valido. Ma provare a screditarli negando la loro esperienza non lo è.

Tuttavia, il punto principale è: Quanto tempo impiega il controllo della versione? Se lei non può essere convinta di investire i 5 secondi di tanto in tanto, dovresti portarlo dal suo capo. Il controllo della versione non è opzionale. Punto fermo.

E una volta che hai usato il controllo della versione, puoi facilmente rintracciare quali errori ha introdotto. E lascia che lei li risolva. È il suo casino, perché dovresti pulirlo? Se lei pensa che il suo approccio sia migliore, allora lascia che lo faccia - fino in fondo .
Supponendo che lei possa farlo davvero (entro un tempo ragionevole), hai ancora un problema: lavorare con lei è quasi impossibile. E questo è qualcosa che dovrai risolvere convincendola (il che sembra improbabile), facendola andare (per il bene della tua compagnia) o lasciandola (per il bene della tua sanità mentale).
Ma il suo fallimento in primo luogo è molto più probabile e dovrebbe assolutamente dimostrare il tuo punto. E poi inizierà ad aderire alle migliori pratiche come fanno molte persone con molta esperienza.

Dipende completamente dal fatto che io stia lavorando da solo o in una squadra.

Se lavoro in una squadra, sono richieste convenzioni e accordi alcuni - tutti i membri del team devono seguire alcuni standard comunemente concordati per lavorare verso l'obiettivo comune in modo che i loro gli sforzi sono compatibili.

Ma se lavoro da solo, ovviamente voglio essere un cowboy. Tutte le grandi creazioni del mondo sono state inventate da una sola mente, o al massimo due, in perfetto stile da cowboy. Solo per citarne alcuni:

• Meccanica classica? Cowboy Isaac Newton, aggiunte successive da Leibniz, Lagrange, Hamilton.
• Aereo? Cowboy Wright.
• Teoria della relatività? Cowboy Albert Einstein.
• Scienza fondamentale dei computer? Cowboy Alan Turing.
• Transistor? Cowboys Walter Brattain e John Bardeen.

I team sono bravi a fare miglioramenti incrementali e mettere insieme nuovi sistemi basati su ricette collaudate abbastanza velocemente (a condizione che siano guidati bene), ma è raro sentire parlare di un'invenzione reale fatta da un team. Il lavoro di squadra e i metodi che richiede hanno le loro virtù, ma anche la codifica dei cowboy.

Dipende dal problema. Un buon sviluppatore senior scriverà un codice molto compatto, semplice e robusto che è molto stabile e utilizza tutte le migliori pratiche senza sfornare pagine di documentazione e tonnellate di modelli e paradigmi diversi. Ma saprà anche quando può permettersi di fare cose del genere.

Sarei scioccato se prendesse un nuovo problema e iniziasse a progettare un'applicazione che richiedesse man-month da zero. Ma se si tratta di un plug-in, uno strumento semplice che puoi scrivere in 2 ore, una funzione che fa alcune conversioni e non è intesa per un riutilizzo, il design e i pattern sono in realtà solo buoni per sprecare il tempo.

Inoltre, immagino che gran parte del progetto sia già stata elaborata in una discussione di background da qualche parte all'interno del capo degli sviluppatori senior.

Devi iniziare a preoccuparti quando lo sviluppatore senior inizia a sfornare le classi di un sistema complesso, o nuove applicazioni da zero e senza pianificazione.

Dipende dalle circostanze. Ad esempio, dopo alcuni disastrosi scandali commerciali, diverse borse elettroniche hanno insistito sul fatto che le bandiere di auto-trading venivano aggiunte a tutte le operazioni. E questo doveva essere per tutti i software di trading entro una settimana. Voglio dire che doveva essere fatto - se la bandiera non era lì non si poteva scambiare. In circostanze del genere, tutte le buone pratiche vanno alla lavagna: devi solo andare (come dicevamo noi) "hacky, hacky, hacky". E in quelle circostanze, scrivere codice in modo rapido e preciso è la chiave. Soprattutto perché non c'erano sistemi di test disponibili.

Dalla mia esperienza, la codifica di cow boy WITH source control è il modo migliore e più privo di bug per sviluppare sistemi software di grandi dimensioni.

Penso che uno dei commentatori abbia avuto ragione - è tutto sui risultati.

Se la persona può produrre un buon prodotto - qualcosa che fa quello che dovrebbe fare, ed è mantenibile e affidabile - allora cosa importa se le metodologie formali o i processi sono seguiti? I processi sono ottimi per garantire un pavimento di qualità, ma se qualcuno sta già lavorando sopra quel piano, i processi non aggiungono nulla all'equazione. Troppi sviluppatori in questi giorni, imo, sembrano pensare che il point della programmazione sia quello di aderire ai processi, al contrario di produrre un buon prodotto.

Questo tipo di persona è chiamato un hacker e di solito non è un termine complementare da quello più professionale tra noi.

Come hai notato, il tempo risparmiato in progettazione, organizzazione e controllo viene perso nel debug. E spesso nel trovare quale versione del codice era quella che è stata effettivamente spedita. Se riesci a trovarlo a tutti!

Trovo che questo tipo di persona sia troppo coinvolto in se stesso, pensa che siano troppo bravi per lavorare con le "limitazioni" che gli altri devono subire e quindi non si preoccupano di loro, e che perde ancora più tempo il resto della squadra deve ripulire dopo di loro. Inoltre, non sono troppo coinvolti nel processo di risoluzione dei bug (è compito di un programmatore di manutenzione, ben al di sotto delle abilità e dei talenti del 'l33t coder').

Quindi, potrebbe essere un approccio comune altrove, ma al mio posto (e io sono un programmatore esperto che ha tendenze a questo approccio, ehm) non ne soffriamo. Non è che richiediamo un sacco di processi e procedure, ma insistiamo su una quantità minima di organizzazione, controllo del codice sorgente (che a dire il vero è dannatamente orientale e dannatamente utile!)

Kent Beck e altri, tutti i professionisti che hanno visto i vecchi processi carenti erano cattivi, quindi ha creato nuove metodologie per organizzare la codifica mantenendola sempre più orientata all'artigianato, e poi ne ha parlato a tutti - pubblicando libri (come mai l'hai fatto prima di Internet?)

Sembra che tu abbia ragione: non accettare cattive pratiche solo perché qualcun altro non può hackerarlo. Il tuo team o il tuo manager dovrebbero venire giù duramente su questa "rockstar", ma se non lo sono ... beh, ciò non impedisce ancora di fare la cosa giusta. Basta non accettare la pratica scadente da lei, se lei rovina (e lei lo farà!), Allora lascia che pulisca. Ti attieni alle buone pratiche (e sai cosa sono) senza lasciare che subentrino a discapito della produttività della codifica, e sarai buono per il futuro.

Ecco un saggio di uno scrittore veramente perspicace. Non risolve il tuo problema, ma ti dà alcune informazioni sul perché è come è e forse alcuni suggerimenti per affrontarlo professionalmente.

L'unico dato importante è il risultato a lungo termine del prodotto del team.

Si sostiene che una squadra che include un grande programmatore (o più) produrrà risultati migliori di una squadra con un numero ancora maggiore di programmatori medi che codificano a una velocità media.

Se il cowboy produce cose che i programmatori normali non fanno (per una determinata scadenza o specifica), e la squadra con il cowboy deve anche spendere qualche settimana / mese per pulire il casino del cowboy, potrebbero comunque finire con il risultato migliore prima.

Se la squadra con il cowboy non riesce a ripulire (documentare, eseguire il debug, integrare, mantenere) il disastro anche dopo molti mesi / anni, quindi qualsiasi progresso che il cowboy ha creato non ha dato alla squadra un vantaggio a lungo termine. / p>

Decidi quale e ottimizza il roster del team.

Non tutti i programmatori funzionano (o dovrebbero funzionare) allo stesso modo, purché il risultato finale sia buono.

Potresti trovare qualche informazione nella mia risposta a Francamente, preferisci la codifica dei cowboy? Il problema è che "Codifica da cowboy" significa cose diverse per persone diverse, e non è immediatamente ovvio, per l'occhio inesperto, quale versione stai vedendo.

Quando qualcuno può esaminare un problema e iniziare immediatamente a criptare il codice, in modo rapido e preciso, potrebbe essere il segno di un ingegnere che l'ha già visto mille volte e già conosce il il modo migliore per risolvere il problema.

Oppure potrebbe essere il segno di un dilettante di grado.

Ti dirò una cosa: rifiutare di usare il controllo di versione o scrivere test perché sono troppo "accademici" è in definitiva non un approccio "senior" o anche da remoto. Non vedrai mai, mai e poi mai questo tipo di cose fatte in un negozio di software importante come Microsoft o Google, e probabilmente non lo vedrai nemmeno nella maggior parte delle startup o in team aziendali ragionevolmente maturi.

I rischi sono semplicemente troppo grandi. Cosa succede se il tuo PC muore durante la notte? Addio 3 anni di produttività. Ok, quindi fai i backup; allora cosa succede quando fai un grande cambiamento, renditi conto che era completamente sbagliato e devi ripristinarlo? Questo succede anche agli sviluppatori più esperti e talentuosi perché i requisiti sono sbagliati. Se non stai eseguendo alcun tipo di controllo della versione, stai solo facendo girare le ruote nel fango. Sono stato lì, una volta, e non mai tornare indietro.

Non ci sono scuse: ci vogliono 10 minuti per configurare un repository e 10 secondi per fare un commit. Costituisce forse l'1% del tempo totale di sviluppo. I test, se sei di fretta, possono essere facilmente ridotti a 20-30 minuti al giorno e sono comunque ragionevolmente utili.

Non sono un fan delle metodologie Agile (nota la A maiuscola), ma a volte hai davvero bisogno di rimboccarti le maniche e iniziare a scrivere il maledetto codice. Ho visto persone e team con "paralisi dell'analisi" e la produttività ha davvero un impatto visibile. Ma il licenziamento degli strumenti di base del nostro commercio come il controllo delle revisioni e i test è davvero il punto di forza per me; questa persona non appartiene a una posizione senior.

Sì, ma devi riconoscere quando NON farlo.

Su qualcosa di piccolo probabilmente stai bene, ma se hai qualcosa di complesso, pericoloso, limitato, ecc. devi essere in grado di riconoscere quando un design appropriato vale il tempo extra.

Penso anche che dovresti sicuramente pensare attraverso la risposta di Aaronaught. Cowboy significa cose diverse per persone diverse.

Quando penso a metodologie "tradizionali", penso che "il management non sa come capire gli sviluppatori, quindi invece di entrare nel mondo degli sviluppatori e capire abbastanza per sapere cosa sta succedendo, fanno in modo che gli sviluppatori entrino nel loro mondo" .

Fondamentalmente, quando penso a "Agile", penso che "fai ciò che devi fare per ridurre al minimo le inefficienze introdotte da più persone che lavorano insieme". Quindi sono fermamente nel campo che "non esiste la THE metodologia Agile , solo un insieme di valori e principi".

In altre parole, ci sono cose che devi fare su un progetto molto grande, e ci sono cose che devi fare su piccoli progetti, e ci sono cose che fai su entrambi.

Ad esempio, non avrei più del più semplice backlog per un progetto su cui sto lavorando ... Sarebbe solo una lista di cose da fare. Se siamo in due, probabilmente avrei condiviso quella lista, ma in un formato molto semplice (probabilmente solo una nota memorizzata nel nostro repository di codice). Una volta che ho 3 o 4, sto cercando una sorta di sistema di oggetti di lavoro.

Solo durante la prototipazione di funzionalità molto semplici.

Poi, una volta fatto e considerato nel modo giusto, metto da parte il codice e faccio sul serio.

L'ho fatto una volta su un progetto reale (al tempo in cui l'abbiamo chiamato Samurai Programming, dopo la serie di sketch di Samurai Tailor su Saturday Night Live), e con mio grande stupore, ha funzionato bene. Naturalmente, quello che ho iniziato era spazzatura, quindi c'era poco rischio di peggiorare la situazione.

Tuttavia, sono un cuore "pulito" e non mi piace lo stile di sviluppo del tiro al bersaglio.

D'altro canto, il modus operandi pesantemente processato non è di mio gusto neanche. Mi piace solo pianificare prima di agire.

Nel complesso, ritengo che la quantità di processo formale appropriata dipenda in gran parte dalla grandezza (dimensione del codice, durata del progetto, numero di sviluppatori, tipi di requisiti, ecc.) del progetto. Voglio il rigore e criteri severi da imporre alle persone che sviluppano il software per l'avionica o attrezzature biomediche, ad es. Per i giochi, ad es., C'è molto meno svantaggio di eventuali guasti, quindi i costi e l'onere delle pratiche di sviluppo rigorose e metodiche non sono realmente giustificati.

Dipende (pesantemente) dalle dimensioni del progetto. Da un lato, per ottenere un risultato decente, è necessario avere un design. D'altra parte, se il progetto è abbastanza piccolo da poter concettualizzare l'intero disegno (ne è la maggior parte comunque) senza scriverlo, disegnare diagrammi, ecc., Allora probabilmente stai altrettanto bene senza quel lavoro extra di documentando tutto ciò che fai.

Quasi tutti hanno sentito abbastanza storie dell'orrore per rendersi conto che provare a saltare dentro senza una chiara idea di cosa stai facendo e dove le cose stanno andando è una ricetta per il disastro. Ciò che è molto più raro notare è che il contrario può essere ugualmente disastroso. Solo per esempio, la maggior parte di noi scrive regolarmente piccoli strumenti nel processo di programmazione. Scrivere una specifica completa, test, documentazione spesso non vale la pena. C'è una soglia al di sotto della quale la productization non vale la pena - le persone spesso non amano reinventare la ruota, ma in alcuni casi è più facile reinventare che evitarla.

In casi come questo, ciò che spesso è vale la pena produrre una libreria per rendere semplici le attività come questa. Con questo, il codice di front-end diventa spesso così banale che scrivere (o modificare) codice per fare ciò che vuoi diventa più facile che ordinare come ottenere un programma completo per fare ciò che vuoi. Considera, per exmaple, indentazione di gnu con i suoi 50+ flag diversi, molti dei quali interagiscono in vari modi, quindi le uniche scelte ragionevoli sono 1) non usarlo affatto, o 2) decidere di apprezzare ciò che ti dà invece di cercare di ottenere ciò che volevi originariamente.

Sembrano esserci due campi: quelli che preferiscono i risultati e quelli che favoriscono i principi. Cado nel secondo.

Sono un programmatore mediocre ma discutibilmente coscienzioso - la mia preoccupazione principale quando codifico, oltre di portare a termine il lavoro, è che sto aiutando chiunque usi il mio codice per ottenere il LORO compito. Non posso dire di averlo sempre raggiunto, ma è quello che mi propongo di fare.

Certo, potresti avere un hotrod nel tuo team - ma cosa succede quando impiegano un paio di settimane a lasciare e ti viene chiesto di eseguire il debug del loro lavoro o di aggiungervi qualcosa? In definitiva, i programmatori cowboy non sono giocatori di squadra. Potrebbero creare un codice fantastico, ma se la squadra dipende da loro, allora è pericoloso.

Ho la sensazione che il tuo disgusto per il suo stile ti stia distorcendo leggermente. Dici che l'approccio cowboy è pagato nel debug - è questo ciò che sta già accadendo, o è la tua ipotesi su come si svolgerà?

Divulgazione leale - Io stesso sono uno sviluppatore senior e spesso rinuncio a un processo formale per la progettazione e all'esperienza. Non avere un processo formale per qualcuno che ha molta esperienza nel dominio del problema è abbastanza comune. Se hai risolto un problema decine di volte, non hai bisogno di un processo formale per formulare nuovamente una soluzione simile.

Un processo formale riguarda la progettazione del codice - Non vedo perché dovrebbero essere introdotti ulteriori bug perché manca un processo formale. L'unico grande problema che ho letto nel tuo account è che il controllo di revisione non viene utilizzato, il che non è solo egoistico, ma addirittura spericolato per conto dello sviluppatore. In realtà, non sta affatto commettendo, o semplicemente non ha commesso uno schema di tuo gradimento?

Non avere un approccio formale al design non è "codifica da cowboy" nel mio libro (non è però il controllo di revisione). L'esperienza dovrebbe essere utilizzata esattamente per questo: ridurre il tempo necessario per trovare una soluzione "abbastanza buona". Ricorda, devi risolvere i problemi che hai attualmente e rendere il codice facile da modificare, non progettare per scenari futuri che potrebbero non accadere mai. Con l'esperienza acquisisci una buona sensazione di come farlo molto velocemente.

No, mai.

Io faccio sempre analisi dei requisiti, penso all'architettura, disegno i dettagli e poi codice. Anche se lavoro da solo a casa per un progetto personale.

E attirerei immediatamente uno sviluppatore nel mio team se lavorasse in stile cowboy. Siamo ingegneri e abbiamo una responsabilità con il cliente e gli utenti.

Non penso che la codifica da cowboy sia un approccio di alto livello.

Come altri hanno già detto, c'è un vero pericolo nello scartare il controllo della versione. Saltare la documentazione e l'analisi potrebbe anche significare rischiare la consegna di qualcosa che l'utente non vuole. Solo la mia opinione, ma non penso che tu vada da "coder a sviluppatore" se tutto ciò che fai è il codice del cowboy.

Tuttavia, sì, ci sono eccezioni come quella di cui parla Neil Butterworth. E in queste situazioni preferirei che uno sviluppatore senior esperto fosse quello che deve fare la codifica del cowboy.

La programmazione da cowboy è un modo piuttosto sicuro di creare una grande palla di fango . Il che, per quanto sgradevole possa sembrare, tende a fornire ...

Penso che i programmatori più recenti tendano a fare cose da codificante da cowboy quando assumono aspetti di un progetto / ambiti che potrebbero non avere molta esperienza o quando stanno cercando di "fare le cose" a causa della pressione di un capo, ecc. So che ho sicuramente intrapreso questa strada alcune volte perché mi mancava la conoscenza del modello corretto da usare e semplicemente "mi sono fatto strada attraverso di esso".

La differenza tra me e la persona di cui ti lamenti è che di solito, poco dopo, mi sono reso conto che avrei potuto farlo meglio e reso più manutenibile e di solito mi sprona ad imparare di più e migliorare le mie capacità (leggendo libri / articoli sull'argomento). Quando torno a eseguire il debug di alcune di queste soluzioni compromesse, di solito trovo che sia un dolore e contribuisce maggiormente al mio desiderio di imparare come farlo nel modo giusto. Penso che questa persona che stai descrivendo sia fondamentalmente bloccata a un livello infantile di autoriflessione e lasciando che il proprio ego interferisca nel migliorare le proprie capacità di sviluppatore di software, non sembra una persona con cui vorrei lavorare.

Trovo il tuo post interessante. Ho spesso condiviso opinioni con il soggetto, e il suo sentimento è che i metodi eccessivamente formalizzati sono soffocanti. Come notato da qualcun altro, se è un genio e può tenere traccia di una moltitudine di note mentali allo stesso tempo senza dimenticare o confondersi, allora è abbastanza possibile mantenere una porzione monolitica di codice contorto e far sì che faccia cose incredibili con cambiamenti completamente oscuri . C'è una certa felicità mentale che arriva al cervello delle persone che possono farlo - è come essere un Dio di un piccolo universo nella tua mente.

Tuttavia, i datori di lavoro intelligenti hanno imparato a fondo che nessuno, a parte l'autore originale, può mai fare qualcosa di utile per quel codice. Se il programmatore si sposta, finiscono per sprecare un sacco di soldi per capire che l'unica opzione è riscrivere (ero solito pensare che significasse perdita totale, ma mi rendo conto in questi giorni che non si distrugge il risultato intrinseco di sviluppo iterativo a livello di funzionalità esterna).

Personalmente, non mi dispiacerebbe avere qualcuno del genere nella squadra, perché in una crisi, potrebbero fare qualcosa che nessun altro pensa.

D'altra parte, sii la tua persona e decidi tu stesso quale sia la risposta alla tua domanda, perché l'unica cosa certa è che nessuno ha capito quando si tratta di costruire Software. È una delle cose che lo rende un campo interessante ...