Francamente, preferisci la codifica da cowboy? [chiuso]

La maggior parte dei programmatori che difendono metodologie politicamente corrette come Agile, Waterfall, RUP, ecc. Alcuni seguono la metodologia ma non tutti. Francamente, se puoi scegliere la metodologia, certamente andresti a integrare le metodologie "corrette" o preferiresti la metodologia "più semplice" come la programmazione da cowboy? Perché?

So che dipende. Per favore, spiega quando useresti l'uno o l'altro. Per favore, dì quali vantaggi vedi sulla codifica Cowboy.

Vedi su Cowboy coding su Wikipedia

Penso che quasi tutti i programmatori esperti abbiano attraversato tre fasi e alcune ne abbiano attraversate quattro:

1. I programmatori o le pepite da cowboy non sanno quasi nulla del design e lo vedono come una formalità non necessaria. Se si lavora su piccoli progetti per stakeholder non tecnici, questo atteggiamento può essere utile per un po '; ottiene cose fatte, colpisce il capo, fa sentire bene il programmatore con se stesso e conferma l'idea che sa cosa sta facendo (anche se non lo fa).

2. Architettura Gli astronauti hanno assistito ai fallimenti dei loro primi progetti di palla-di-filo per adattarsi alle mutevoli circostanze. Tutto deve essere riscritto e per evitare la necessità di un'altra riscrittura in futuro, creano piattaforme interne e finiscono per spendere 4 ore al giorno in supporto perché nessun altro capisce come usarle correttamente.

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

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

4. Programmatori nastro adesivo AKA guru o consulenti ben pagati sanno ciò che l'architettura e il design hanno intenzione di utilizzare entro cinque minuti dopo aver sentito le esigenze del progetto. Tutto il lavoro di architettura e design sta ancora accadendo, ma è a un livello intuitivo e sta avvenendo così in fretta che un osservatore inesperto lo confonderebbe con la codifica da cowboy - e molti lo fanno .

   Generalmente queste persone sono tutte orientate alla creazione di un prodotto "abbastanza buono" e quindi le loro opere potrebbero essere un po 'poco ingegnerizzate ma sono a miglia di distanza dal codice spaghetti prodotto dai programmatori di cowboy. Le pepite non sono nemmeno in grado di identificare queste persone quando vengono informate 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 programmatore di cowboy più di quanto puoi scegliere di essere analfabeta.

Se sei un programmatore di cowboy, allora non conosci altro modo.

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

Se sei un quasi ingegnere (o un ingegnere professionista), completare un progetto con uno sforzo di progettazione iniziale minimo o nullo è una scelta consapevole (di solito dovuta a scadenze assurde) che deve essere ponderata rispetto agli ovvi rischi e intrapresa solo dopo che le parti interessate hanno accettato (di solito per iscritto).

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

Nessuno "preferisce" la codifica da cowboy rispetto ad altre metodologie perché non è una metodologia. È l'equivalente di sviluppo software dei pulsanti di schiacciamento in un videogioco. Va bene per i livelli principianti, ma chiunque sia passato oltre quel livello semplicemente non lo farà. Potrebbero fare qualcosa di simile ma non sarà la stessa cosa.

Sì.

Preferisco anche lasciare le calze sul pavimento dove le ho tolte, la mia scrivania coperta di stampe e vecchi involucri di snack, il mio lavandino pieno di piatti sporchi e il letto sfatto.

Non considero una vacanza programmata in anticipo come una vacanza adeguata, un pasto consumato pensando all'alimentazione come cibo adeguato o stare su sentieri conosciuti come un'escursione.

Mi piace divertirmi, essere sorpreso, imparare cose nuove, fare errori e non essere mai sicuro di riuscire a tornare indietro. E a volte, questo atteggiamento è esattamente ciò che è necessario per far decollare un progetto ...

... ma il più delle volte è semplicemente irresponsabile. Quando la danza finisce, il pifferaio verrà pagato ... Dimentica questo a tuo rischio e pericolo.

Hai esattamente ragione. Questo approccio alla "programmazione da cowboy" potrebbe rendere più rapida la prima revisione del codice, ma i risparmi di tempo saranno più che persi grazie a:

• Bug aggiuntivi
• Tempo aggiuntivo necessario per trovare gli errori che avresti avuto comunque
• Dover decodificare il codice per ricordare cosa hai fatto quando è necessario apportare una modifica in sei mesi
• Tempo extra dedicato alla formazione di sviluppatori aggiuntivi che devono lavorare sul tuo codice
• Non avere un registro delle revisioni a cui guardare quando si effettua una modifica che rompe qualcosa
• Non avendo moduli puoi facilmente riutilizzarli in progetti successivi
• E ancora e ancora e ancora

Come Neil Butterworth menzionato nella sua risposta, a volte devi fare quello che devi fare. Come pratica generale, no, sbattere il codice il più velocemente possibile senza perdere tempo nel controllo del codice sorgente, nei modelli, nella documentazione, ecc. È un'abitudine molto brutta da prendere in considerazione.

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

Ciò si riduce alla questione se è possibile implementare le cose correttamente senza una struttura stretta e un sacco di tempo consumato nella pianificazione.

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

Cioè, vogliono chiedere che qualcosa venga fatto e che qualcuno ci salti sopra, lo esegua e lo faccia uscire. Nessuna gestione del progetto, riunioni, teleconferenze o moduli. Fallo e basta. Non ho mai avuto un cliente che dicesse "ehi, questo è stato fatto un po 'troppo in fretta per i nostri gusti, lo apprezzeremmo se ci mettessi una piccola cascata o qualcosa la prossima volta".

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

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

• Individua il modo più semplice per implementare rapidamente qualcosa
• Sapere a che punto si romperà
• Scrivi un codice pulito, leggibile e semplice
• Prevedi come gli utenti lo useranno, abusarlo e romperlo
• Ridimensionalo / sottraggilo nei posti giusti e non andare su di esso con l'astronauta
• Sapere dove e come gestire casi limite ed eccezioni

Persone come questa producono risultati davvero eccezionali con una gestione e una struttura molto ridotte, ma sono rare.

EDIT: Per riferimento futuro, la mia risposta è per un'altra domanda, che è stata fusa in questa. È abbastanza fuori posto qui, ma non è stata la mia chiamata.

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

Voglio dire, non è che lei usi una metodologia non convenzionale o forse obsoleta. Lei usa solo coscientemente nessuno . Senza standard. Nessuna garanzia di qualità. Niente affatto. Da dove si aspetta che provenga la qualità del software? Alberi?
È divertente, in realtà nega l'esperienza delle persone che citi, quando ovviamente le manca. È valido fornire argomenti verificabili e pertinenti per mettere in discussione le loro affermazioni. Ma cercare di screditarli negando la loro esperienza non lo è.

Ma il punto principale è: quanto tempo impiega il controllo della versione?
Se non può essere convinta a investire i 5 secondi di tanto in tanto, dovresti prenderlo dal suo capo. Il controllo della versione non è facoltativo. Punto.

E una volta che la utilizza usando il controllo versione, puoi facilmente rintracciare i bug che ha introdotto. E lasciare che il suo correggerli. È il suo pasticcio, perché dovresti ripulirlo? Se pensa che il suo approccio sia migliore, allora lascia che lo faccia - fino in fondo .
Supponendo che possa effettivamente farlo (entro un tempo ragionevole), hai ancora un problema: il lavoro di squadra con lei è quasi impossibile. E questo è qualcosa che dovrai risolvere convincendola (che sembra improbabile), facendola partire (per il bene della tua compagnia) o lasciando (per il bene della tua sanità mentale).
Ma il suo fallimento in primo luogo è molto più probabile e dovrebbe sicuramente 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 lavori da solo o in gruppo.

Se lavoro in una squadra, sono necessarie alcune convenzioni e accordi - tutti i membri della squadra devono seguire alcuni standard concordati per lavorare verso l'obiettivo comune in modo che i loro sforzi siano compatibili.

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

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

I team sono bravi a apportare miglioramenti incrementali e a mettere insieme nuovi sistemi basati su ricette collaudate abbastanza rapidamente (a condizione che siano guidati bene), ma è raro sentire parlare di una vera invenzione fatta da un team. Il lavoro di gruppo e i metodi richiesti hanno le loro virtù, ma anche la codifica da cowboy.

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

Sarei scioccato se dovesse affrontare un nuovo problema e iniziare a progettare un'applicazione che richiede mesi-uomo da zero. Ma se si tratta di un plug-in, un semplice strumento che puoi scrivere in 2 ore, una funzione che esegue una conversione e non è pensata per un riutilizzo, il design e i modelli sono effettivamente buoni solo per perdere tempo.

Inoltre, immagino che gran parte del design sia già stato elaborato in un thread di sfondo da qualche parte all'interno della testa degli sviluppatori senior.

Devi iniziare a preoccuparti quando lo sviluppatore senior inizia a sfornare 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 sono state aggiunte a tutte le negoziazioni. E questo doveva essere per tutti i software di trading entro una settimana. Voglio dire che doveva essere fatto - se la bandiera non fosse lì non si potrebbe scambiare. In circostanze del genere, tutte le buone pratiche vanno a buon fine - devi solo andare (come dicevamo una volta) "hacky, hacky, hacky". E in tali circostanze, scrivere codice velocemente e accuratamente è la chiave. Soprattutto perché non c'erano sistemi di test disponibili.

Dalla mia esperienza, la codifica di cow boy CON controllo del codice sorgente è 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 è in grado di produrre un buon prodotto - qualcosa che fa ciò che dovrebbe fare ed è mantenibile e affidabile - allora che importanza ha se vengono seguite metodologie o processi formali? I processi sono grandi per garantire un livello di qualità, ma se qualcuno sta già lavorando sopra quel piano, i processi non aggiungono nulla all'equazione. Al giorno d'oggi, troppi sviluppatori sembrano pensare che il punto della programmazione sia aderire ai processi, anziché produrre un buon prodotto.

Questo tipo di persona si chiama hacker e di solito non è un termine gratuito tra i più professionali tra di noi.

Come hai notato, il tempo risparmiato in progettazione, organizzazione e controllo si perde nel debug. E spesso nel trovare quale versione di codice era quella effettivamente spedita. Se riesci a trovarlo affatto!

Trovo che questo tipo di persona sia troppo avvolto in se stesso, penso che siano troppo bravi per lavorare con i "limiti" che gli altri devono soffrire e quindi non preoccuparti di loro, e questo perde ancora più tempo rispetto al resto del la squadra deve ripulire dopo di loro. Inoltre, non sono troppo coinvolti nel processo di correzione dei bug (è un compito dello sviluppatore della manutenzione, ben al di sotto delle capacità e del talento del programmatore l33t).

Quindi, potrebbe essere un approccio comune altrove, ma al mio posto (e sono un programmatore senior che ha tendenze a questo approccio, ehm) non lo subiamo. 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 est e dannatamente utile!)

Kent Beck et al., Sono tutti professionisti che hanno visto i vecchi modi carichi di processo essere cattivi in ​​se stessi, quindi hanno creato nuove metodologie per organizzare il codice mantenendolo ancora più orientato all'artigianato, e poi ne hanno parlato a tutti gli altri - pubblicando libri ( come mai lo hai fatto prima di Internet?)

Sembra che tu abbia ragione, non accettare cattive pratiche solo perché qualcun altro non può hackerarlo. Il tuo capo squadra o manager dovrebbe essere molto duro con questa "rockstar", ma se non lo sono ... beh, ciò non ti impedisce di fare la cosa giusta. Basta non accettare da lei una pratica scadente, se lei fa un casino (e lo farà!), Allora lasciala pulire. Rispetti le buone pratiche (e sai cosa sono) senza lasciarle prendere a scapito della tua produttività di codifica e sarai buono per il futuro.

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

L'unico fatto importante sono i risultati a lungo termine 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 specifiche) e la squadra con il cowboy deve anche passare qualche settimana / mese a ripulire il pasticcio del cowboy, potrebbero finire con miglior risultato prima.

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

Decidi quale e ottimizza l'elenco del team.

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

Potresti trovare qualche intuizione nella mia risposta a Frankly, preferisci la codifica da cowboy? Il problema è che "codifica da cowboy" significa cose diverse per persone diverse, e non è immediatamente ovvio, a un occhio inesperto, quale versione stai vedendo.

Quando qualcuno può vedere un problema e iniziare immediatamente a scrivere il codice, in modo rapido e preciso, questo potrebbe essere il segno di un ingegnere esperto che l'ha già visto migliaia di volte prima e conosce già il modo migliore per risolvere il problema.

Oppure, potrebbe essere il segno di un dilettante di rango.

Vi dirò una cosa: Rifiutando di usare il controllo di versione o scrivere i test perché sono troppo "accademico" è definitivamente non è un approccio "senior" o anche da remoto professionale. Non vedrai mai questo genere di cose in un negozio di software importante come Microsoft o Google, e probabilmente non lo vedrai nella maggior parte delle startup o dei team aziendali ragionevolmente maturi.

I rischi sono semplicemente troppo grandi. Cosa succede se il tuo PC muore dall'oggi al domani? Ciao ciao 3 anni di produttività. Va bene, quindi fai i backup; allora cosa succede quando fai un cambiamento importante, ti rendi conto che era completamente sbagliato e devi ripristinarlo? Questo succede anche al più esperto e talentuoso degli sviluppatori perché i requisiti sono sbagliati. Se non stai eseguendo alcun controllo della versione, girerai le ruote nel fango. Ci sono stato, una volta, e non ci tornerò mai più.

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

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

Sì, ma devi riconoscere quando NON farlo.

Su qualsiasi cosa di piccole dimensioni probabilmente stai bene, ma se hai qualcosa di complesso, pericoloso, limitato, ecc. Devi essere in grado di riconoscere quando vale la pena dedicare un tempo adeguato a un progetto adeguato.

Penso anche che dovresti assolutamente pensare alla 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 sì che gli sviluppatori entrino nel loro mondo".

Fondamentalmente, quando penso ad "Agile", penso "fai quello che devi fare per ridurre al minimo le inefficienze introdotte da più persone che lavorano insieme". Quindi sono fermamente nel campo che "non c'è alcuna cosa come LA 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 altro che il più semplice degli arretrati per un progetto su cui sto lavorando ... Sarebbe solo un elenco di cose da fare. Se siamo in due, probabilmente avrei condiviso quell'elenco, ma in un formato molto semplice (probabilmente solo una nota memorizzata nel nostro repository di codice). Una volta che ne ho 3 o 4, cerco una sorta di sistema di oggetti di lavoro.

Solo durante la prototipazione di funzionalità molto semplici.

Quindi, una volta fatto e considerato nel modo giusto, abbandono il codice e divento serio.

L'ho fatto una volta su un vero progetto (all'epoca lo chiamavamo Programmazione Samurai, dopo la serie di schizzi Samurai Tailor su Saturday Night Live), e con mia grande sorpresa, ha funzionato bene. Ovviamente, quello che ho iniziato con la spazzatura, quindi c'erano pochi rischi di peggiorare le cose.

Tuttavia, sono un "pulito" e non mi piace lo stile di sviluppo sparatutto.

D'altra parte, il modus operandi pesantemente carico di processo non è neanche di mio gusto. Mi piace solo pianificare prima di agire.

Tutto sommato, ritengo che la quantità di processo formale appropriata dipenda fortemente dall'entità (dimensione del codice, durata del progetto, numero di sviluppatori, tipi di requisiti, ecc.) Del progetto. Voglio rigore e rigidi criteri da imporre alle persone che sviluppano il software per avionica o apparecchiature biomediche, ad esempio per i giochi, ad esempio, c'è molto meno svantaggio di eventuali guasti, quindi il costo e l'onere delle pratiche di sviluppo rigoroso e metodico non è proprio giustificata.

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

Quasi tutti hanno ascoltato abbastanza storie dell'orrore per rendersi conto che cercare di saltare senza una chiara idea di cosa stai facendo e dove stanno andando le cose è una ricetta per il disastro. Ciò che è molto più raramente sottolineato è che il contrario può essere altrettanto disastroso. Solo per esempio, molti di noi scrivono abitualmente 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 produttività non è utile: alle persone spesso non piace reinventare la ruota, ma in alcuni casi è più facile reinventare che evitarlo.

In casi come questo, ciò che è spesso è utile è productizing una libreria per semplificare le attività di questo tipo facile. Con ciò, il codice front-end spesso diventa così banale che scrivere (o modificare) il codice per fare quello che vuoi diventa più facile che capire come ottenere un programma completo per fare quello che vuoi. Considera, per esempio, il rientro di GNU con i suoi oltre 50 flag diversi, molti dei quali interagiscono in vari modi sottili, 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 inizialmente desideravi.

Sembrano esserci due campi: quelli a favore dei risultati e quelli a favore dei principi. Cado in quest'ultimo.

Sono un programmatore mediocre ma probabilmente coscienzioso - la mia principale preoccupazione quando si scrive il codice, oltre a svolgere il lavoro, è che sto aiutando chiunque usi il mio codice per portare a termine il LORO lavoro. Non posso dire di averlo sempre raggiunto, ma è quello che intendo fare.

Certo, si potrebbe avere un hotrod sulla vostra squadra - ma cosa succede quando prendono un paio di settimane di congedo e ti viene chiesto di eseguire il debug il loro lavoro, o aggiungere cose ad esso? In definitiva, i programmatori di cowboy non sono giocatori di squadra. Possono creare un ottimo codice, ma se la squadra dipende da loro, allora è pericoloso.

Ho la sensazione che il tuo disgusto per il suo stile ti stia facendo travisare leggermente. Dici che l'approccio cowboy è pagato nel debug : è questo che sta già accadendo o è la tua ipotesi su come andrà a finire?

Divulgazione corretta - Sono anch'io uno sviluppatore senior e spesso rinuncio a un processo formale per la progettazione e l'esperienza continua. Non avere un processo formale per qualcuno che ha molta esperienza nel settore problematico è abbastanza comune. Se hai risolto un problema decine di volte, non è necessario un processo formale per formulare nuovamente una soluzione simile.

Un processo formale si occupa della progettazione del codice - non vedo perché dovrebbero essere introdotti più bug perché manca un processo formale. L'unico grosso problema che ho letto nel tuo account è che il controllo di revisione non viene utilizzato, il che non è solo egoistico, ma decisamente sconsiderato per conto dello sviluppatore. In realtà non si sta impegnando affatto, o semplicemente non sta commettendo secondo uno schema che è di tuo gradimento?

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

No, mai.

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

E licenzierei 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 senior.

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

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

La programmazione da cowboy è un modo piuttosto sicuro per creare una grande palla di fango . Che, per quanto spiacevole possa sembrare, tende a offrire ...

Penso che i programmatori più recenti tendano a fare alcune cose di codifica da cowboy quando affrontano aspetti di un progetto / ambiti con cui potrebbero non avere molta esperienza o quando stanno cercando di "fare le cose" a causa della pressione di un capo, ecc. So di aver sicuramente seguito questa strada un paio di volte perché non ero a conoscenza del modello corretto da usare e mi sono semplicemente "fatto strada".

La differenza tra me e la persona di cui ti lamenti è che di solito presto dopo mi rendo conto che avrei potuto farlo meglio e renderlo più mantenibile e di solito mi spinge a imparare di più e migliorare le mie abilità (leggendo libri / articoli sul soggetto). Quando torno a eseguire il debug di alcune di queste soluzioni hackerate di solito trovo che sia un dolore e contribuisce maggiormente alla mia voglia di imparare a farlo nel modo "giusto". Penso che questa persona che stai descrivendo sia sostanzialmente bloccata a un livello infantile di autoriflessione e che permetta al proprio ego di ostacolare effettivamente il miglioramento delle proprie capacità di sviluppatore di software, non sembra che qualcuno con cui vorrei lavorare.

Trovo il tuo post interessante. Ho spesso condiviso opinioni con il tuo argomento e la sua sensazione è che i metodi troppo formalizzati siano soffocanti. Come ha notato qualcun altro, se è un genio e può tenere traccia di una moltitudine di note mentali allo stesso tempo senza dimenticare o confondersi, allora è del tutto possibile mantenere un pezzo monolitico di codice contorto e farlo fare cose incredibili con cambiamenti completamente oscuri . C'è una certa felicità mentale che viene 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, tranne l'autore originale, può mai fare qualcosa di utile per quel codice. Se il programmatore va avanti, finiscono per sprecare un sacco di soldi per capire che l'unica opzione è quella di riscrivere (pensavo che ciò significasse perdita totale, ma in questi giorni mi rendo conto che non distruggi il risultato intrinseco di sviluppo iterativo a livello di funzionalità esterna).

Personalmente, non mi dispiacerebbe avere qualcuno del genere in squadra, perché in uno scricchiolio potrebbero fare qualcosa a cui 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 l' ha capito quando si tratta di costruire software. È una delle cose che lo rende un campo interessante ...