È normale / accettabile scrivere note, pensieri, algoritmi, decisioni durante la codifica e la manutenzione? [chiuso]

Alcune persone hanno questo problema che non possono pensare senza parole. E scrivere i loro pensieri e decisioni è il modo più efficace per procedere.

Quindi - è normale e accettabile che scrivo i miei pensieri e le mie decisioni in alcuni file Notepad ++ durante la codifica?

A volte dovrebbe essere accettabile, ad esempio quando si ricrea documentazione tecnica o ragionamento su algoritmi più complessi, ma a volte può essere strano, ad esempio quando sto prendendo in considerazione le opzioni di progettazione e provando a dare un giudizio.

L'impatto di questa pratica sulla produttività non è chiaro. Da un lato - il ragionamento con le parole interiori può essere più veloce che con le parole scritte. Dall'altro lato - problemi più complessi richiedono la scrittura. Inoltre, se uno è bloccato con più opzioni di design, allora la sensazione è migliore quando viene scritta la decisione, quindi aumenta il morale.

Non solo è normale, è una buona idea.

C'è una citazione famosa

"Dammi sei ore per abbattere un albero e passerò i primi quattro a affilare l'ascia".

Prendersi il tempo di organizzare i propri pensieri e pianificare il proprio lavoro prima che la programmazione sia tempo ben speso. Mettere quei pensieri sulla carta ti darà il tempo di riflettere sui tuoi piani, criticarli e organizzarli in modi che sarebbero molto difficili se fatti solo "nella tua testa".

Sì, questo è perfettamente accettabile e normale.

Documentare il processo decisionale è spesso utile quando si rivisita il codice, per aiutare a determinare perché il codice è stato scritto in un certo modo.

Queste note possono essere incluse direttamente nel codice come commenti, se abbastanza brevi. I commenti estesi sono spesso conservati come parte di un documento di progettazione tecnica esterno.

È una dannatamente buona idea. Fino a quando non diventa un modo per procrastinare.

La chiave è l'equilibrio. Trovo di essere più produttivo se non inscatolo me stesso ma catturo idee come vengono.

Se sto macinando a un livello basso e arriva un'idea di alto livello, lo annoto e torno più tardi.

Pianificare il lavoro è una buona idea, ma a meno che non si debba comunicare o presentare davanti a un pubblico gli strumenti migliori sono penna e tovagliolo. Cattura l'idea. Non perdere tempo a renderlo carino.

In qualsiasi situazione professionale, non è solo "normale e accettabile", è obbligatorio. Il tipico ciclo di sviluppo consiste in due fasi di documentazione prima ancora che inizi qualsiasi codifica:

1. Documento sui requisiti funzionali: in genere scritto da analisti aziendali, specificando la funzionalità da implementare.

2. Detail Document Document: che è praticamente ciò di cui stai parlando, solo più formale, che specifica la decomposizione funzionale (factoring) del sistema, algoritmi, ecc. Alcuni dei miei (molto) vecchi sono online, ad esempio questo .

Per una documentazione meno formale, concordo al 110% con le osservazioni precedenti sui commenti in linea. Questa è l' unica strada da percorrere; in un modo o nell'altro, tutto il resto alla fine si perde. Ma il commento in linea pulito e ponderato è un'abilità di codifica separata, sviluppata attraverso lo sforzo e la pratica come qualsiasi altra abilità. Puoi vedere alcune delle mie (molto) vecchie cose su, ad esempio questo . Questo stile può o meno piacere a te. Ti consiglio di trovare prima un codice ben commentato con uno stile che ti piace e di emularlo nel tuo codice. Dopo un po ', adattalo come meglio credi.

Un ottimo posto per inserire questo tipo di informazioni è direttamente nel messaggio di commit del sistema di controllo della versione (SVN, git, ecc.). In questo modo puoi vedere le modifiche e il ragionamento per loro nello stesso posto.

Oltre alle altre buone risposte, aggiungerò che scrivo spesso i miei pensieri su ciò che sto cercando di fare.

Essere molto esplicito sull'articolazione di ciò che sto cercando di fare mi aiuta a realizzare presunzioni, ipotesi e / o requisiti che non necessariamente valgono.

Questo poi suggerisce delle alternative, che posso poi rimuginare meglio a turno; quella scrittura aiuta a salvare il mio posto se penso a qualcos'altro.

Prendo appunti rapidi per esplorare respiro e profondità, quindi funziona in modo ricorsivo, aiutandomi a elaborare, navigare e valutare un albero di soluzioni, eseguendo il backup, esplorando, scoprendo, realizzando e decidendo.

Annotare tutto ciò che può salvarti / (nuovi) membri della squadra Il tempo è tempo ben speso. Assicurati solo che sia qualcosa di cui qualcuno potrebbe aver bisogno in seguito e non pensare troppo a meno che non sia un vero progetto a lungo termine.

Inoltre, non dovrebbe volerci del tempo. Se passi il tempo a pensare, puoi scrivere i tuoi pensieri da 1 a 1 (purché possano / possano essere utili a qualcuno).

Il vero problema potrebbe essere il ripensamento di ciò che scrivi. Solo perché stai scrivendo non significa che devi aderire a un formato già esistente o devi andare fino in fondo per creare una documentazione completa.

Se la tua scelta è tra non scrivere nulla e scrivere semplicemente note non formali su un blocco note, allora scrivi solo note non formali.

Dici: "Alcune persone hanno questo problema che non possono pensare senza parole. E scrivere i loro pensieri e le decisioni è il modo più efficace per procedere."

Se scrivere i tuoi pensieri e le tue decisioni è il modo più efficace di procedere, perché non sarebbe normale e accettabile procedere nel modo più efficace? Fai ciò che funziona meglio per te. Potrebbe non essere quello che funziona meglio per qualcun altro. In tal caso non lasci che qualcun altro ti dica ciò che è meglio per te e non dici loro ciò che è meglio per loro. Tutti fanno ciò che è meglio per loro.

Gli umani possono contenere solo sette "cose" contemporaneamente. Questa è la ragione per i numeri di telefono a sette cifre. Affinché i programmatori possano lavorare in modo efficiente, devono trovare una sorta di sistema per scaricare le cose dalla loro memoria e recuperarle rapidamente in seguito, se necessario. Prendere appunti è un modo ovvio e diretto, ma tutti coloro che lavorano su qualcosa di moderatamente complesso devono farlo in qualche modo . Quando abbini un programma a qualcuno, cerca di cercare il suo metodo.

Un modo comune è lo sviluppo guidato dai test. In questa metodologia, scrivi un test non riuscito, scrivi solo il codice sufficiente per far passare quel test non riuscito, quindi rifletti il ​​tuo codice per renderlo più bello mantenendo tutti i test esistenti. Questa metodologia mantiene tutte le "note" codificate all'interno dei test. Le persone possono lavorare molto rapidamente in questo modo senza sembrare prendere appunti, perché sono solo focalizzate sul prossimo test.

Un altro modo comune è semplicemente scrivere le note nel codice come commenti o stub pseudocodici, quindi sostituirle gradualmente con la cosa reale. È così che di solito scrivo algoritmi. La mia prima bozza è solo una funzione principale con pseudocodice, poi gradualmente si riempie di livelli sempre più profondi di astrazione.

Non sentirti male nell'utilizzare qualsiasi metodo che funzioni per te, ma cerca di notare quali metodi stanno usando i tuoi colleghi "efficienti". Hanno gli stessi limiti umani che hai tu.