Cosa c'è di così brutto nella codifica creativa? [chiuso]

Stasera stavo guardando Bob Ross dipingere degli "alberi felici" e ho capito cosa mi ha stressato il mio codice ultimamente.

La comunità di persone qui e su Stack Overflow sembra rifiutare qualsiasi soffio di imperfezione. Il mio obiettivo è scrivere codice rispettabile (e quindi mantenibile e funzionante), migliorando le mie capacità. Eppure, codice in modo creativo.

Lasciami spiegare cosa intendo per "codifica in modo creativo":

• I miei primi passi in un progetto sono spesso sedermi e sottrarre un po 'di codice. Per cose più grandi, ho in programma un po 'qua e là, ma soprattutto mi tuffo e basta.
• Non faccio uno schema delle mie lezioni, a meno che non stia lavorando con altri che stanno creando altri pezzi nel progetto. Anche allora, non è certo la prima cosa che faccio. In genere non lavoro su grandi progetti e non trovo la grafica molto utile.
• Il primo giro di codice che scrivo verrà riscritto molte, molte volte mentre collaudo, semplifico, rifaccio e trasformo l'hack originale in qualcosa di riutilizzabile, logico ed efficiente.

Durante questo processo, pulisco sempre. Rimuovo il codice inutilizzato e commento tutto ciò che non è ovvio. Provo costantemente.

Il mio processo sembra andare controcorrente di ciò che è accettabile nella comunità degli sviluppatori professionisti e vorrei capire perché.

So che la maggior parte delle lamentele sul cattivo codice è che qualcuno si è bloccato con il pasticcio di un ex dipendente, e costava molto tempo e denaro da risolvere. Che ho capito. Quello che non capisco è come il mio processo sia sbagliato, dato che il risultato finale è simile a quello che otterresti con la pianificazione di tutto dall'inizio. (O almeno, è quello che ho trovato.)

Ultimamente la mia ansia per il problema è stata così grave che ho smesso di scrivere codice fino a quando non so tutto quello che c'è su ogni metodo per risolvere il problema specifico su cui sto lavorando. In altre parole, per lo più ho smesso del tutto di codificare.

Apprezzo sinceramente il tuo contributo, non importa quali siano le tue opinioni in merito.

Modifica: grazie a tutti per le risposte. Ho imparato qualcosa da ciascuno di essi. Siete stati tutti molto utili.

Non c'è niente di sbagliato nel codice-test-refactor-repeat, basta dire alla gente che stai prototipando.

D'altra parte, per i progetti più grandi scoprirai che un po 'di pensiero dato al design in anticipo ti farà risparmiare un sacco di tempo nel ciclo oh-crap-now-what!

PS: le tecniche di diagramma ti aiutano ad apprendere le abilità di pensiero visivo, che sono utili anche se nessuno ti vede mai i tuoi diagrammi.

Preferisco sempre un codice chiaro, leggibile e semplice a qualsiasi codice visivamente presentato, UML, con motivi di design, in cui classe / interfaccia includano nomi di pattern come "ItemVisitor" (?!). Modelli di progettazione, tecniche OO e tutto il resto devono formalizzare le regole. Quelle regole derivano dal buon senso.

È impossibile lavorare senza quella formalizzazione (a meno che non si lavori da soli sul proprio progetto) e l'eccessiva formalizzazione aumenta i costi del progetto. Non trascurare mai le esigenze degli altri di comprendere il tuo codice. Il codice migliore è il più semplice.

Non esitare mai a riscrivere il tuo codice. Per questo otterrò X downgrade (X> = 10), ma lo renderò audace: la riusabilità del codice non è la cosa più importante .

Prima di fissare il codice, è necessario considerare i casi d'uso che il codice implementerà. Perché il software deve essere usato e non sviluppato. Usabilità, utilità sono i due obiettivi più importanti e non importa chi userà quel software: un altro sviluppatore di parti dipendenti del progetto o l'utente finale.

Sono più o meno allo stesso modo. Ascolta quando le altre persone ti raccontano cose che hanno funzionato per loro, ma ignora chiunque ti dica cosa dovresti "fare" come se ci fosse un imperativo morale. Se trovi qualcosa che funziona per te, seguilo. Voglio dire, il risultato finale è ciò che è importante, no? A chi importa davvero del percorso che hai preso per arrivarci?

Ricorda: le persone sono diverse . È una buona cosa. Non ascoltare le persone che cercano di renderti simile a loro e resisti alla tentazione di rendere altre persone come te e farai bene.

Sembra che tu sia:

1. Provare cose per trovare l'approccio migliore (sperimentazione, progettazione incrementale)
2. Riscrivere il codice per renderlo più pulito (refactoring)
3. Scrivere costantemente test (sviluppo test driven)

Quello che stai facendo è fantastico! Sembra che tu lo stia facendo perfettamente bene, specialmente se l'hai capito da solo e non l'hai imparato da un (agile) libro di programmazione. C'è ovviamente di più in questo, ma hai i valori inchiodati. Ricorda solo di refactoring e migliorare il design mentre aggiungi il codice e non dovrebbe essere necessario un BDUF .

Hai pensato di concentrarti su una piccola funzione alla volta e di rilasciarla al termine di ogni funzione? Ciò potrebbe aiutarti a rimanere libero da qualsiasi problema di analisi con cui stai lottando e dimostra progressi reali per il tuo datore di lavoro.

Inoltre, non so di quale "comunità di sviluppo professionale" stai parlando, ma se lo fossi, direi loro di tornare alle loro torri d'avorio in modo da poter continuare con il tuo lavoro!

Brad, non sei solo. Conosco programmatori molto bravi che lavorano esattamente come tu descrivi. :)

Se ripulisci il tuo codice e sai come renderlo efficiente e leggibile, allora hai sicuramente sviluppato un senso su come scrivere codice pulito ed efficiente anche in anticipo.

Inoltre, nulla può essere completamente pianificato in anticipo e il percorso più breve per scoprire le sottigliezze è spesso quello di eseguire il codice e comprendere i dettagli trascurati.

Penso che tu stia andando benissimo e che lo stile di programmazione che descrivi sia perfettamente valido.

Penso che valga la pena di completare le risposte sopra con una citazione di Alan J. Perlis, dalla prefazione del noto libro del MIT "Struttura e interpretazione dei programmi per computer", comunemente chiamato "SICP":

Ogni programma per computer è un modello, nato nella mente, di un processo reale o mentale. Questi processi, derivanti dall'esperienza e dal pensiero umani, sono enormi in numero, intricati nei dettagli e in qualsiasi momento solo parzialmente compresi. Sono modellati per la nostra soddisfazione permanente raramente dai nostri programmi per computer. Pertanto, anche se i nostri programmi sono raccolte discrete di simboli, mosaici di funzioni ad incastro realizzate a mano, si evolvono continuamente: le cambiamo man mano che la nostra percezione del modello si approfondisce, si allarga, si generalizza fino a quando il modello alla fine raggiunge un posto metastabile all'interno di un altro modello con cui noi lottiamo ".

C'è buono intelligente e cattivo intelligente.

Buona intelligenza: elevato rapporto tra linee di codice intelligenti e linee di un'alternativa non intelligente. 20 righe di codice che ti salvano dalla scrittura di 20000 sono estremamente intelligenti. Bravo intelligente, ti risparmia il lavoro.

Bad Clever: basso rapporto tra righe di codice scritte e righe di codice salvate. Una riga di codice intelligente che ti salva dalla scrittura di cinque righe di codice è Bad Clever. La cattiva intelligenza riguarda la "masturbazione sintattica".

Solo per notare: Bad Clever non viene quasi mai chiamato "Bad Clever"; viaggerà spesso sotto gli alias "bello", "elegante", "conciso" o "succinto".

Posso sicuramente riconoscermi nel modo in cui descrivi il tuo flusso di lavoro. Ecco il punto: quando ho iniziato a lavorare in un ambiente di gruppo, quasi tutte quelle cose DEVONO cambiare.

Il lavoro che svolgo da circa 8 mesi è davvero la mia prima esperienza di lavoro in un team di sviluppatori in un singolo progetto. Fino ad ora, letteralmente tutta la mia carriera è stata come un programmatore di lupi solitari che non ha dovuto affrontare tutto ciò che riguarda il lavoro di squadra. Anche quando lavoravo in un gruppo, era sempre un lavoro piuttosto insensato - avevo il mio progetto che era MIO, o la mia sezione che era MIO, ecc. Era un'interessante curva di apprendimento mentre mi alzavo veloce con un ambiente di lavoro di squadra veramente collaborativo.

Ecco la cosa principale che ho capito: se non è dannatamente ovvio quello che stai facendo, probabilmente stai scrivendo il prossimo mal di testa di un collega. La maggior parte della pignoleria "orientata al processo" che vedi qui ha a che fare con il fatto che molti di noi sono STATI i colleghi con il mal di testa. E la maggior parte della teoria della gestione dei processi software ha a che fare con la riduzione al minimo di tale mal di testa.

Quindi cose come pianificare un piano concordato in anticipo, ecc ... Si tratta di avere una squadra a bordo e sincronizzata. Se sei la squadra, sei già sincronizzato con te stesso, e non è davvero necessario.

Non c'è niente di sbagliato nel tuo approccio come forma d'arte creativa. Se stai sviluppando per il beneficio personale, e quello che stai facendo funziona per te, e che ritieni divertente, probabilmente è importante tanto quanto il risultato finale del prodotto stesso.

In un ambiente di lavoro professionale, se i tempi del progetto sono brevi, forse circa 2-3 settimane o meno, il tuo approccio si chiama prototipazione rapida ed è abbastanza appropriato per le attività future.

Tuttavia, per progetti più lunghi, anche se si lavora da soli, tale approccio è probabilmente un lusso costoso per il proprio datore di lavoro. Trascorrere alcuni giorni del budget del progetto nella progettazione dell'architettura iniziale e quindi testare l'architettura rispetto a ciò che se la direzione decidesse di cambiare le specifiche di ... è normalmente tempo ben speso e svilupperà le tue abilità per diventare un programmatore / architetto più prezioso più avanti nella tua carriera.

Due prospettive:

1. Nessuno deve mantenere un dipinto.

2. Chiunque abbia mai visto Bob Ross dipingere un dipinto sa che i dipinti hanno una struttura. Se avessi preso una lezione di distanza da Bob Ross, sarebbe che pianificare in anticipo e lavorare in modo organizzato rende il processo regolare e semplice.

Codifico praticamente allo stesso modo. Inizierò a scrivere e mentre vedo emergere schemi, rifletto. Puoi dipingere te stesso in un angolo in quel modo, devi sapere quando sederti e pensare a un problema, ma a volte devi solo prenderlo per capirlo davvero .

Ma sono curioso di questo:

La comunità di persone qui e su Stack Overflow sembra rifiutare qualsiasi soffio di imperfezione. [..] Il mio processo sembra andare controcorrente di ciò che è accettabile nella comunità degli sviluppatori professionisti e vorrei capire perché.

In che modo qualcuno di Stack Overflow potrebbe conoscere il tuo processo? E cosa intendi con "rifiuto"? Naturalmente, il codice inviato a una comunità di programmazione verrà esaminato in modo critico. Ma se qualcuno individua aree in cui il tuo codice può essere migliorato, può essere solo una buona cosa, giusto?

Spero che, quando pubblichi una domanda su Stackframe, ripulisci il tuo codice e provi a ridurlo nella forma più semplice possibile, per rispetto dei tuoi lettori (a volte risolvi il tuo problema solo cercando di renderlo presentabile ad altri), in cui caso qualsiasi feedback è buono. Se pubblichi un codice che sai essere negativo e sai perché è negativo prima di pubblicarlo, non dovresti prenderlo sul personale se le persone lo notano .

Uso anche il tuo approccio. Funziona meglio per me, poiché riduce il rischio di ingegnerizzazione eccessiva.

Quello che faccio molto spesso è risolvere un problema con probabilmente il minor codice possibile, il che di solito porta a dipendenze evidentemente inutili o ad altri problemi di progettazione. Quindi trasformo il codice di lavoro in un bellissimo codice.
Ad esempio, riduco le dipendenze tra i diversi moduli per concedere interfacce e metto in discussione quali dati dovrebbero essere conservati dove, fino a quando ogni modulo non dipende solo da astrazioni molto minimaliste degli altri moduli. Si potrebbe dire che ho posticipato la decisione finale, quale modulo dovrebbe avere quale responsabilità. Rimando l'astrazione.
Mettere troppo pensiero nel separare un problema in responsabilità distinte, in astrazioni distinte, non è buono. Ti costringerà a piegare la tua implementazione per adattarla alle astrazioni che hai fatto. Il codice funziona, se produce i risultati desiderati e se è gestibile. Una progettazione funziona, se è possibile implementarla attraverso un buon codice. Se il codice non funziona, lo si modifica. Ergo, se un disegno non funziona, dovrai cambiarlo anche tu. Puoi vedere se una progettazione funziona, una volta implementata.

Quindi avere in mente un semplice schizzo è quasi abbastanza come un disegno, prima di iniziare a dargli vita. Riprogettazione, abstract e refactoring secondo necessità .

Penso che se sarai bravo a programmare, almeno a volte deve essere divertente, e questo significa essere creativi.

Sicuramente quando si programma in gruppo ci sono almeno standard minimi che dovrebbero essere seguiti, non per ragioni "morali", ma per quelli pratici, quando si applicano.

Al di fuori di questo, è interessante e divertente sondare i confini per vedere cosa si può trovare lì. Una volta, mentre lavoravo su una Mini in linguaggio assembly, ho scoperto che potresti creare delle routine che potrebbero passare dall'una all'altra con 1 istruzione. Poi ho capito come creare un'autocronutica che potesse fare due passi avanti, un passo indietro, ecc. Ti è stato utile? Ne dubito. Non è questo il punto.

Una volta ho sentito un discorso di Edsger Dijkstra, che parlava di creatività nella programmazione. Ha menzionato il modo in cui uno studente ha trovato il modo di eseguire una rotazione n-bit di una parola n + m-bit. È stato fatto con 3 bitswap. Prima si scambiano i bit n, quindi si scambiano i bit m, quindi si scambiano tutti i bit n + m. Utile? No. intelligente? Sì.

È bello sentirsi liberi di provare cose che nessuno nella loro mente giusta farebbe.

Questo può essere un caso di "una taglia non va bene per tutti". Hai fatto funzionare il tuo stile per i progetti in cui hai partecipato, quindi con chi discutere? Tuttavia, i critici che stai leggendo qui e su SO potrebbero lavorare su progetti più grandi o su progetti che richiedono un coordinamento complesso tra i membri del team.

Il tuo stile di sviluppo potrebbe diventare un problema se fossi mai stato coinvolto in progetti più grandi che prevedevano la cooperazione tra più sviluppatori. È difficile programmarlo, è difficile tenere traccia dei tuoi progressi e non c'è modo per i tuoi colleghi programmatori di pianificare quel po 'del loro lavoro che dipende dal sapere cosa sta facendo il tuo po' di lavoro.

Potresti essere interessato a leggere Dreaming in Code per vedere cosa può succedere quando un grande progetto adotta uno stile di sviluppo simile al tuo.

Molta rassicurazione che il tuo metodo non è sbagliato, ma lasciami aggiungere qualche esperienza personale. Ho iniziato a modo tuo, ma nel frattempo ho imparato in anticipo il vantaggio di pianificare almeno parte della struttura generale, e questo per una serie di motivi:

• il più grande extra è che è più facile vedere quale codice può essere riutilizzato se aggirato un po '. Scrivo spesso un pezzo di codice che, mentre scrivo, sembra improvvisamente utile per un'altra parte dello schema generale che ho appeso accanto al mio schermo (disegnato su carta in uno stile solo leggibile per me).

• Avere uno schema ti consente di refactorizzare non solo il codice, ma anche lo schema. A volte sono impegnato a scrivere una lezione che improvvisamente appare utile anche per qualche altra parte dello schema. Di conseguenza lo schema diventa più semplice quando il progetto viene eseguito

• Ogni volta aggiorno anche quello schema con l'input richiesto e l'output dato di funzioni / metodi e slot disponibili nelle classi. Questo è più veloce per il riutilizzo dei bit: non devo immergermi nel codice ogni volta per controllare esattamente cosa accade dentro e fuori. Anche se è nei commenti, devo comunque navigare per ottenere i commenti

Quindi effettivamente uso anche il tuo metodo. Comincio, provo, refatto, riprovo, cambio un altro po 'e così via, ma anche il mio ciclo include lo schema. E quando fatto, aggiungo le informazioni per il prossimo che funziona su quel codice.

Intendiamoci, questo è per progetti su cui lavoro da solo. Se lavori con più persone sullo stesso codice, pianificare in anticipo non è solo una logica, è essenziale. Ma suppongo che tu lo sappia già.

E come altri hanno detto: questo è il mio modo, il tuo chilometraggio può variare.