it-swarm.it

Francamente, preferisci la codifica da cowboy?

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 circa Cowboy coding su Wikipedia

68
Maniero

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

  1. Codificatori da cowboy o pepite non sanno quasi nulla del design e lo vedono come una formalità inutile. 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. Gli astronauti dell'architettura hanno assistito ai fallimenti dei loro primi progetti con il gomitolo di adattarsi alle mutevoli circostanze. Tutto deve essere riscritto e per evitare la necessità di altro riscrivere in futuro, creano piattaforme interne e finisci per spendere 4 ore al giorno in supporto perché nessun altro capisce come usarli correttamente.

  3. Quasi-ingegneri spesso si scambiano per attuale, ingegneri addestrati perché sono veramente competenti e comprendere 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 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 necessità di queste metodologie senza rendersi conto che nel = effettivo campo dell'ingegneria del software, sono solo strumenti, non religioni. E sfortunatamente, impedisce loro di arrivare alla fase finale, che è:

  4. Programmatori nastro adesivo AKA guru o consulenti altamente pagati sanno quale architettura e design useranno entro cinque minuti dopo aver ascoltato i requisiti del progetto. Tutto il lavoro di architettura e design sta ancora avvenendo, ma è a un livello intuitivo e sta avvenendo così in fretta che un osservatore non addestrato lo confonderebbe con la codifica da cowboy - e molti lo fanno.

    Generalmente queste persone sono tutte orientate alla creazione di un prodotto che è "abbastanza buono" e quindi le loro opere potrebbero essere un po 'meno ingegnerizzate ma sono miglia lontane dal codice spaghetti prodotto dai programmatori di cowboy. I nugget non possono nemmeno identificare queste persone quando sono raccontate 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 è un scelta, è un livello di abilità e non puoi scegliere di essere un programmatore di cowboy più di quanto tu possa 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 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 che sembra simile ma non sarà la stessa cosa.

204
Aaronaught

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 con la mente per un'alimentazione corretta, 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, quell'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.

46
Shog9

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 i bug che avresti avuto comunque
  • Dover decodificare il tuo 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, eliminare il codice il più rapidamente 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.

31
Warren Pena

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 richiedere 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, è 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 variabili di sviluppatori nella 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 ed eccezioni Edge

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

29
Brandon

EDIT: per riferimento futuro, la mia risposta è per n'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. Usa solo consapevolmente nessuno. Senza standard. Nessuna garanzia di qualità. Niente affatto. Da dove si aspetta che provenga la qualità del software? Alberi?
È divertente che in realtà neghi 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 lascia che her risolvili. È 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.

13
back2dos

Dipende completamente dal fatto che io lavori da solo o in gruppo.

Se lavoro in gruppo, sono necessarie alcune convenzioni e accordi - tutti i membri del team devono seguire alcuni standard comunemente concordato 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.

11
Joonas Pulakka

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 modelli e paradigmi diversi. Ma saprà anche quando può permettersi di fare queste cose.

Sarei scioccato se prendesse un nuovo problema e iniziasse a progettare un'applicazione che richiede mesi-uomo da zero. Ma se si tratta di un plug-in, uno strumento semplice 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.

7
Coder

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 potresti 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.

6
Neil Butterworth

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.

5
jojo

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 del codice era quella effettivamente spedita. Se riesci a trovarlo!

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, tutti i professionisti che hanno visto i vecchi modi carichi di processo erano cattivi in ​​se stessi, quindi hanno creato nuove metodologie per organizzare il codice pur mantenendolo più orientato all'artigianato, e poi detto a tutti gli altri a riguardo - 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 n 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.

4
gbjbaanb

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

Se la persona è in grado di produrre un buon prodotto - qualcosa che fa quello che dovrebbe fare, ed è mantenibile e affidabile - allora cosa importa se vengono seguite metodologie o processi formali ? I processi sono grandi per garantire un livello qualitativo, 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 punto della programmazione sia aderire ai processi, invece di produrre un buon prodotto.

4
GrandmasterB

Potresti trovare alcune intuizioni nella mia risposta a Francamente, preferisci la codifica da cowboy? Il problema è che "codifica da cowboy" significa cose diverse per persone diverse, e non è immediatamente ovvio, ad un occhio non allenato, quale versione stai vedendo.

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

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

Ti dirò una cosa: rifiutare di usare il controllo di versione o scrivere test perché troppo "accademici" è definitivamente non un approccio "senior" o persino remoto. Non vedrai mai questo genere di cose fare 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 vorrei mai tornare indietro.

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 avuto un successo visibile. Ma il licenziamento degli strumenti di base del nostro commercio come il controllo di revisione e i test è davvero il fattore decisivo per me; questa persona non appartiene a una posizione senior.

3
Aaronaught

L'unico fatto importante sono i risultati a lungo termine del team.

Si sostiene che un team che include un grande programmatore (o più) produrrà risultati migliori di un team con un numero ancora maggiore di programmatori medi che codificano a un tasso medio.

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.

3
hotpaw2

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 esiste qualcosa come [[~ # ~] 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 arretrato 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 codici). Una volta che ne ho 3 o 4, cerco una sorta di sistema di oggetti di lavoro.

2
MIA

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.

2
Bill

Ho la sensazione che il tuo disgusto per il suo stile ti stia facendo travisare leggermente. Dici l'approccio del cowboy è pagato nel debug - è questo ciò 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 al design non è una "codifica da cowboy" nel mio libro (non è però 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.

1
Eran Galperin

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 durante la programmazione, oltre ottenere il lavoro fatto, è che sto aiutando chiunque usi il mio codice per fare IL LORO lavoro. Non posso dire di averlo sempre raggiunto, ma è quello che intendo fare.

Certo, tu potresti hai un hotrod nella tua squadra - ma cosa succede quando si prendono un paio di settimane di ferie e ti viene chiesto di eseguire il debug del loro lavoro o di aggiungere materiale? 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.

1
sunwukung

Solo durante la prototipazione di funzionalità molto semplici.

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

1
Klaim

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" nel cuore 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 apparecchiature avioniche o biomediche, ad es. Per i giochi, ad esempio, c'è molto meno svantaggio di eventuali guasti, quindi il costo e l'onere di pratiche di sviluppo rigorose e metodiche non è realmente giustificato.

1
Randall Schulz

Dipende (fortemente) dalle dimensioni del progetto. Da un lato, per ottenere un risultato decente devi avere un disegno. 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 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 produttività non è utile: alle persone spesso non piace reinventare la ruota, ma in alcuni casi è più facile reinventare che evitarlo.

In casi come questo, spesso è vale la pena di produrre una libreria per rendere le attività così facili. 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.

1
Jerry Coffin

Non penso che la codifica da cowboy sia un approccio senior.

Come altri hanno già detto, esiste 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.

0
Bernard Dy

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 ...

0
Aaron Anodide

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

0

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 semplicemente 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.

0
programmx10

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.

0
CesarGon