Che male c'è nella codifica creativa? [chiuso]

Non c'è niente di sbagliato con la ripetizione del refact del test del codice, basta dire alle persone che stai creando un prototipo.

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

P.S .: Le tecniche di diagrammi ti aiutano ad apprendere le abilità di pensiero visivo, che sono preziose anche se nessuno, a parte te stesso, vede i tuoi diagrammi.

Preferisco sempre un codice chiaro, leggibile e semplice a qualsiasi codice presentato esteticamente, con design UMLed, in cui classe / interfaccia includa nomi di pattern come "ItemVisitor" (?!). Modelli di progettazione, tecniche OO e tutto il resto per formalizzare le regole. Queste regole provengono dal senso comune.

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

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

Prima di iniziare la codifica dovresti considerare i casi d'uso che il codice implementerà. Perché il software deve essere utilizzato e non sviluppato. Usabilità, utilità sono due obiettivi più importanti e non importa chi utilizzerà quel software: altri sviluppatori di parti dipendenti del progetto o dell'utente finale.

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

Ricorda: le persone sono diverse . È una buona cosa. Non ascoltare le persone che cercano di farti piacere, e resisti all'impulso di far piacere ad altre persone come te e andrai bene.

Sembra che tu sia:

1. Provare a trovare l'approccio migliore (sperimentazione, progettazione incrementale)
2. Riscrivere il codice per renderlo più pulito (refactoring)
3. Test di scrittura costante (sviluppo basato su test)

Quello che stai facendo è fantastico! Sembra che lo stai facendo perfettamente bene, specialmente se lo hai capito da solo e non l'hai imparato da un (agile) libro di programmazione. Ovviamente c'è di più in questo, ma hai i valori inchiodati. Ricordati di rifattorizzare e migliorare il design mentre aggiungi il codice e non ci dovrebbe essere bisogno di un BDUF .

Hai preso in considerazione la possibilità di concentrarti su one piccola funzionalità alla volta e rilascia dopo che ogni funzionalità è stata completata? Ciò potrebbe aiutarti a liberarti da qualsiasi problema di analisi con cui stai lottando e dimostra reali progressi per il tuo datore di lavoro.

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

Penso che valga la pena 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":

Every computer program is a model, hatched in the mind, of a real or mental process. These processes, arising from human experience and thought, are huge in number, intricate in detail,and at any time only partially understood. They are modeled to our permanent satisfaction rarely by our computer programs. Thus even though our programs are carefully handcrafted discrete collections of symbols, mosaics of interlocking functions, they continually evolve: we change them as our perception of the model deepens, enlarges, generalizes until the model ultimately attains a metastable place within still another model with which we struggle."

Brad, non sei solo. Conosco ottimi programmatori che lavorano esattamente nello stesso modo in cui descrivono. :)

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

Inoltre, nulla può essere 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 perfettamente bene e che lo stile di programmazione che descrivi sia perfettamente valido.

C'è una buona intelligenza e una cattiva intelligenza.

Good Clever: alto rapporto tra le linee intelligenti del codice e le linee di un'alternativa non intelligente. 20 righe di codice che ti evitano di scrivere 20000 sono estremamente intelligenti. Good Clever significa risparmiare il tuo lavoro.

Bad Clever - basso rapporto tra righe di codice scritte scritte e righe di codice salvate. Una linea di codice intelligente che ti evita di scrivere cinque righe di codice è Bad Clever. Bad Badver parla di "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 riconoscere me stesso nel modo in cui descrivi il tuo flusso di lavoro. Ecco cosa: quando ho iniziato a lavorare in un ambiente di gruppo, quasi tutte le cose HAD da cambiare.

Il lavoro che ho frequentato per circa 8 mesi è la mia prima esperienza lavorativa in un team di sviluppatori su un singolo progetto. Fino ad ora, letteralmente, la mia intera carriera è stata quella di un programmatore solitario che non aveva a che fare con tutto ciò che viene fornito con il lavoro di squadra. Anche quando lavoravo in un gruppo, era sempre un lavoro abbastanza silenzioso - avevo il mio progetto che era MINE, o la mia sezione che era MINE, ecc. Era una curva di apprendimento interessante mentre mi alzavo con un ambiente di lavoro di squadra davvero collaborativo.

Ecco la cosa principale che ho realizzato: se non è evidente quello che stai facendo, probabilmente stai scrivendo il prossimo mal di testa di un collega. La maggior parte della pignoleria "process-oriented" 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 del mal di testa.

Quindi cose come pianificare un piano concordato prima del tempo, ecc. Si tratta di avere una squadra a bordo e in sincronia. Se sei il team, sei già in sintonia con te stesso e questo non è realmente necessario.

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

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

Tuttavia, per progetti più lunghi, anche quando lavori per conto tuo, un simile approccio è probabilmente un lusso costoso per il tuo datore di lavoro. Trascorrere qualche giorno del budget del progetto su un'architettura dell'architettura upfront e poi testare l'architettura contro cosa succederebbe se la gestione decidesse di cambiare le specifiche per ... è 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 quadro sa che i dipinti hanno una struttura. Se stavi per prendere una lezione da Bob Ross, sarebbe che pianificare in anticipo e lavorare in modo organizzato rendesse il processo semplice e semplice.

Io codifico più o meno allo stesso modo. Comincerò a scrivere e, mentre vedo emergere degli schemi, mi rifatto. Puoi dipingere te stesso in un angolo in questo modo, devi sapere quando sederti e pensare a un problema, ma a volte devi solo provare a capire come capire il problema.

Ma sono curioso di questo:

The community of folks here and on Stack Overflow seem to reject any whiff of imperfection. [..] My process seems to go against the grain of what is acceptable in the professional developer community, and I would like to understand why.

In che modo qualcuno in Stack Overflow conosce il tuo processo? E cosa intendi per "rifiutare"? Naturalmente, il codice pubblicato in una comunità di programmazione verrà esaminato criticamente. Ma se qualcuno individua aree in cui è possibile migliorare il codice, può essere solo una buona cosa, vero?

Se tutto va bene, quando invii una domanda a Stackframe, ripulisci il tuo codice e prova a ridurlo nella forma più semplice possibile, per rispetto verso i tuoi lettori (a volte risolvi il tuo problema solo cercando di renderlo presentabile agli altri) , nel qual caso qualsiasi feedback è buono. Se scrivi un codice che conosci è sbagliato, e sai perché è brutto prima di postarlo, non dovresti prenderlo di persona se le persone notano che non va bene.

Uso anche il tuo approccio. Funziona meglio per me, dal momento che riduce il rischio di overengineering.

Quello che faccio molto spesso è risolvere un problema con probabilmente il minimo codice possibile, che di solito porta a dipendenze evidentemente inutili o ad altri problemi di progettazione. Poi rifatto il codice di lavoro in codice bello.
Ad esempio, riduco le dipendenze tra moduli diversi in interfacce concise e pongo il pensiero nella domanda su quali dati devono essere tenuti dove, fino a quando ogni modulo dipende solo da astrazioni molto minimaliste degli altri moduli. Si potrebbe dire, rinvio la decisione finale, quale modulo dovrebbe avere quale responsabilità. Rinvio l'astrazione.
Mettere troppi pensieri per separare un problema in responsabilità distinte, in distinte astrazioni, non è buono. Ti costringerà a piegare la tua implementazione per adattarla alle astrazioni che hai creato. Il codice funziona, se produce i risultati desiderati e se è mantenibile. Un progetto funziona, se è possibile implementarlo attraverso un buon codice. Se il codice non funziona, lo cambi. Ergo, se un design non funziona, dovrai cambiarlo. Puoi vedere solo se un progetto funziona, dopo averlo implementato.

Quindi avere in mente un semplice schizzo è sufficiente quanto un disegno, prima di iniziare a portarlo in vita. Redesign, abstract e refactor secondo necessità .

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

Sicuramente quando si programma in gruppo ci sono almeno degli standard minimi da seguire, non per ragioni "morali", ma per ragioni pratiche, quando si applicano.

Al di fuori di questo, è interessante e divertente sondare i confini per vedere cosa può essere trovato lì. Una volta lavorando su una Mini in linguaggio assembly, ho scoperto che si potevano creare delle co-routines che potevano passare da una all'altra con 1 istruzione. Poi ho capito come fare un auto-co-routine che poteva fare due passi avanti, un passo indietro, ecc. Era utile? Ne dubito. Non è questo il punto.

Una volta ho ascoltato un discorso di Edsger Dijkstra, parlando di creatività nella programmazione. Ha menzionato come uno studente abbia trovato un modo per fare una rotazione n bit di una parola n + m bit. È stato fatto con 3 bitwap. Prima si scambiano gli n bit, quindi si scambiano i m bit, quindi si scambiano tutti i n + m bit. Utile? No. intelligente? Sì.

È bello sentirsi liberi di provare cose che nessuno sano di mente farebbe.

Questo potrebbe essere il caso di "una misura non va bene per tutti". Hai fatto in modo che il tuo stile funzioni per i progetti in cui sei stato, quindi chi è che ne discute? 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 coinvolto in progetti più ampi che comportano la cooperazione tra più sviluppatori. È difficile programmarlo, è difficile tenere traccia dei tuoi progressi e non è possibile per i tuoi colleghi programmatori pianificare la parte del loro lavoro che dipende dalla conoscenza del lavoro svolto.

Potresti essere interessato a leggere Sognare nel codice per vedere cosa può accadere quando un grande progetto adotta uno stile di sviluppo simile al tuo.

Un sacco di rassicurazioni sul fatto che il tuo metodo non è sbagliato, ma lascia che aggiunga qualche esperienza personale. Ho iniziato la tua strada, ma nel frattempo ho imparato il vantaggio di pianificare in anticipo almeno parte della struttura generale, e questo per una serie di ragioni:

• il più grande extra è che è più facile vedere quale codice può essere riutilizzato se lavorato un po '. Scrivo spesso un pezzo di codice che, durante la scrittura, 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 consente di ridefinire non solo il codice, ma anche lo schema. A volte sono impegnato a scrivere una classe che improvvisamente sembra utile anche per qualche altra parte dello schema. Di conseguenza lo schema diventa più semplice quando il progetto gira su

• Ogni volta che aggiorno lo schema con l'input richiesto e l'output di funzioni / metodi e gli slot disponibili nelle classi. Questo è più veloce per riutilizzare i bit: non devo immergermi nel codice ogni volta per controllare cosa esattamente entra e chi esce. Anche se è nei commenti, devo ancora sfogliare per ottenere i commenti

Quindi, in realtà, anch'io uso il tuo metodo. Inizio, provo, refactoring, provo di nuovo, cambio un altro bit e così via, ma il mio ciclo include anche lo schema. E quando ciò è fatto, aggiungo le informazioni per il prossimo che funziona su quel codice.

Attenzione, questo è per progetti in cui lavoro da solo. Se lavori con più persone sullo stesso codice, pianificare in anticipo non è solo logico, è essenziale. Ma immagino che tu lo sappia già.

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