Come fare un passo indietro e guardare il codice con occhi nuovi? [chiuso]

Modi per avvicinarti a questo:

• Trova qualcuno che abbia familiarità con la tecnologia e il problema aziendale e parlagli. Questo può essere difficile in una squadra composta da una sola persona, ma è generalmente l'opzione migliore.
• Lavora su un progetto diverso per un po '. Anche questo può essere difficile, ma anche prendere una pausa di una settimana può darti una nuova prospettiva.
• Guarda progetti o prodotti simili, come i prodotti open source, se esistenti. Fai attenzione a non copiare il codice, ma potrebbero essersi avvicinati all'idea in modo completamente diverso.
• Impara una nuova lingua, libreria o struttura. Le tecniche coinvolte potrebbero fornirti informazioni su come affrontare gli stessi problemi che hai in modo diverso.
• Leggi un buon libro / blog / rivista sul design o sulla lingua / struttura. Non sono sicuro di quale livello di abilità tu sia, ma ci sono molte alternative in altre risposte su questo sito.

Se hai degli esempi specifici che vuoi indirizzare, magari pubblicali qui.

Debugging anatra di gomma : sedersi con un pezzo di codice o un modulo o un funzione e spiegarlo, ad alta voce. Quando ti ritrovi a dire qualcosa che sembra sbagliato, sciocco o semplicemente non giusto, scrivilo come un problema da investigare.

Continua ad apprendere e amplia le tue capacità. È difficile sapere cosa non sai, ma quando lo vedi, quel momento "aha" ti colpirà. Potrebbe venire dall'apprendimento di un'altra lingua o di un modello di progettazione.

Ti verrà chiesto di apportare una modifica. Potresti trovare parti del tuo codice che non sono così flessibili e richiederanno molte modifiche. Questo non è necessariamente un fallimento perché all'inizio non puoi pensare a tutto.

Gli utenti inizieranno a lamentarsi. Proprio quando pensi che tutto sia ottimo ...

Una memoria corta aiuta. Sono stato conosciuto per lamentarsi del "cretino" che ha cambiato qualcosa una settimana fa, solo per scoprire dal controllo del codice che ero io.

Un buon primo passo è identificare il codice che potrebbe essere migliorato. Cerca nel tuo controllo sorgente i file che cambiano più spesso. Con quale codice è più difficile lavorare? Quale codice produce la maggior parte dei bug? Quali tipi di modifiche causano un effetto a catena lungo tutto il codice? In questa fase, non devi sapere perché il codice è problematico, solo che è problematico.

Una volta identificate le aree su cui lavorare, prova a capire qual è il problema. Esistono libri che adottano un approccio sistematico per classificare i problemi di progettazione. Guarda il Refactoring di Martin Fowler, gli standard di codifica C ++ di Herb Sutter , il Codice pulito di Robert Martin, ecc. Hanno un sacco di "regole" che lasciano guardi il tuo codice in modo obiettivo.

Una volta identificato il problema probabile, prova diversi modi per risolverlo. Ad esempio, se la regola che hai interrotto è "preferisci la composizione sull'ereditarietà", quindi modificala in composizione e guarda come ci si sente.

Ovviamente, può essere utile che qualcun altro guardi il codice, ma non è sempre così utile come potresti pensare, perché sei molto più familiare con i tipi di problemi che il codice causa di chiunque altro, e le ragioni del design. Imparare alcuni modi per valutare oggettivamente il tuo design pagherà grandi dividendi.

Fai in modo che un'altra persona guardi il tuo codice. Se non riesci a trovare un'altra persona per guardarla, scrivi una descrizione completa dell'interazione come se la mostrassi a un'altra persona. Il processo di provare a spiegare le tue decisioni a un'altra persona (anche se è solo per la pratica) può aiutarti a pensare veramente PERCHÉ stai facendo le cose in un certo modo e ti aiutano a vedere buchi nella tua logica.

Conosco molto bene questa situazione. Quando rimango bloccato in questo modo cerco di prendere diversi punti di vista sul progetto.

1.) Punto di vista utente / cliente - usa il feedback

Purtroppo siamo presi nel nostro codice in un modo che non siamo in grado di vedere i nostri difetti perché utilizziamo le nostre applicazioni nel modo in cui le abbiamo codificate. Guarda come la gente lo usa e cerca di capire quale sarebbe la guida per l'utente più intuitiva. Gioca con i prototipi UI. Questo sembra essere divertente, ma se scopri che sarai costretto a ricodificare parti enormi del tuo codice semplicemente cambiando la logica di utilizzo di quanto non sia il momento di iniziare un ciclo di riprogettazione.

2.) Effettua un'analisi funzionale del tuo codice e visualizzalo

Alcuni IDE e framework ti spingono ad es. miscelazione dell'interfaccia utente e del codice back-end. Se lasci che ciò accada, ad un certo punto dovrai affrontare la situazione in cui la tua base di codice non può essere mantenuta a causa di dipendenze nebulose e difficili da rompere. Soprattutto la combinazione del codice UI con un altro codice può portare a codice spaghetti e funzionalità ridondanti. Dividi il tuo codice in blocchi funzionali come ad es. classi di database, classi di comunicazione, classi UI, classi di base ecc. e forniscono i nomi di lingua dei blocchi funzione. Quindi visualizza la funzionalità con uno strumento grafico (io uso uno strumento di mappatura mentale) per scoprire se la tua struttura è abbastanza logica e modulare da poter riutilizzare enormi blocchi di codice per diversi progetti e sei in grado di sostituirli con le versioni più recenti senza grande dolore.

Il modo migliore per farlo nella mia esperienza è creare un documento che visualizzi tutte le dipendenze tra le tue classi e le loro chiamate dal tuo codice. Il risultato è una visualizzazione del design dell'interfaccia. Se questa mappa del codice sembra un clusterf completo di ***, è ora di agire. Se non è ancora successo, dovresti pensare a una convenzione di denominazione adatta che rappresenti la struttura del codice in un modo in cui non devi pensare a come chiamarla e cosa fa.

3.) Utilizza approcci comuni per la garanzia della qualità

Il mio preferito è il FMEA. In termini di codifica ciò significa non solo analizzare ciò che è andato storto in passato, ma anche pensare a cosa potrebbe andare storto. Un esempio abbastanza comune è una connessione di rete improvvisamente caduta. Dopo averlo fatto, è possibile classificare le condizioni di errore in base a conseguenze quali perdita di dati, crash, calcolo errato e valutazione dell'impatto sull'utente. Se non si è ancora riusciti a definire un errore ottimizzato, le classi e le routine delle eccezioni possono aiutarti a mantenere il codice pulito e lineare. Il modo migliore è implementare quelli in ogni nuova pace di codice prima ancora di iniziare a scrivere qualcos'altro. (Beh, sono colpevole di non seguire sempre questo consiglio da solo.)

Inoltre mi ha aiutato a generare e aggiornare frequentemente un "elenco di proposte di miglioramento" per il mio codice. (Per essere onesti c'è ancora un sacco di codice nei miei progetti di cui non sono assolutamente orgoglioso.) Cerco anche di prendere il tempo per raccogliere e dare un'occhiata al codice di best practice da documentazioni API, conferenze per sviluppatori o riviste per sviluppatori.

Fino a questo punto non è necessario toccare il tuo codice. Si tratta semplicemente di capire cosa sta andando male e trovare un modo per definire come migliorare il codice.

Finalmente alcuni consigli per il lavoro quotidiano da una vecchia scoreggia. Cerca di evitare di mordere più di quanto tu possa mangiare. Ciò porta a troppa pressione per una codifica pulita. Raramente hai il tempo di farlo bene, ma dopo dovrai prendere il tempo per sistemare i difetti.

Nulla è più duraturo della soluzione provvisoria, ma quando si rompe è spesso troppo tardi per risolverlo in tempo. Esempi sono brutti hack o strane eccezioni che ho usato per ottenere qualcosa da lavorare nonostante, ad es. un difetto nel framework o nel sistema operativo sottostante. E poi l'errore viene risolto o la nuova versione semplicemente lascia l'API ...

Se sei bloccato e sei costretto a trovare una soluzione alternativa a fare commenti e prendere appunti che dovrebbero essere rivisti di volta in volta. Normalmente miglioriamo grazie all'apprendimento di qualcosa di nuovo. Se trovi un modo migliore di implementarlo il più velocemente possibile. Altrimenti potresti trovarti a codificare la soluzione alternativa per la soluzione alternativa e l'eccezione dell'eccezione un giorno. (Colui che è senza peccato tra di voi, lascia che lanci il primo byte contro di me.)

Non preoccuparti delle piccole cose.

Tutti potrebbero codificare meglio. Facciamo le cose velocemente e poi realizziamo un paio di settimane dopo che avrebbe potuto essere fatto in modo più efficiente. Il punto è che il 90% del tuo codice è probabilmente abbastanza buono.

Controlla i registri dei bug e trova le routine che potrebbero causare problemi. Quando trovi i bug, puoi anche rivedere il codice e pensare a cosa potrebbe rendere il codice più efficiente. La maggior parte delle volte capirai che oltre a correggere il bug stesso, non sarai in grado di ottenere un notevole miglioramento, ma a volte capirai che c'è un modo migliore per fare qualcosa.

Parla con gli utenti e guarda dove notano i problemi, sia UX che problemi di velocità. Risolvi questi problemi, prestando attenzione a migliorare il tuo codice.

Ad un certo punto, scoprirai che il tuo codice è diventato troppo fragile e che semplicemente non c'è modo di apportare le modifiche necessarie. Quindi pensa a come potresti rendere il sistema più flessibile, tramite API o sviluppo basato su test. In molti casi, scoprirai che puoi iniziare a inserire queste API nel codice, senza una quantità enorme di modifiche. In altri casi, ti renderai conto che lo sforzo di migliorare il codice non vale la pena.

I cambiamenti incrementali possono essere difficili. L'obiettivo è non riscrivere interamente la base del codice se non è necessario. Certo, sei un programmatore migliore ora di quanto lo fossi un anno fa, ma quello che devi lavorare adesso. Tra 5 anni, quando un programmatore junior si lamenta per te del codice legacy che devono provare a sistemare, sorridi e annuisci e non ammettere che l'hai scritto.

Hai pensato di andartene e di trovare un'azienda in cui poter far parte di una squadra? Ritengo strongmente che, isolato o in una squadra stagnante, gli sviluppatori perdano molto sulla professione che ha da offrire.

Le revisioni tra pari consentono a qualcuno che è già fuori dalla tua testa di dare il tuo consiglio. Il riesame del codice di scambio dello stack potrebbe essere un buon posto in cui inserire un codice che non è particolarmente riservato alla tua azienda per la revisione. Probabilmente non può gestire blocchi enormi, ma molti programmi sono fatti di un sacco di codice semplice e di un altro codice che non è semplice e crea molti problemi. Se si dispone di un esempio di codice che è tipico, ma viene ripetuto e modificato in molti punti, potrebbe anche essere un buon candidato per la recensione. Ad esempio, se si formattano i messaggi, non chiedere di avere rivisto tutto il messaggio, solo un messaggio di esempio abbastanza complesso.

Se vuoi essere più obiettivo sul tuo codice, suppongo che potresti confrontarlo con uno standard di codifica, eseguire controlli di codice statici o dinamici su di esso, o se sei scarsamente documentato, aggiungere commenti potrebbe aiutare.

Esiste una psicologia dei test che rende difficile testare il tuo codice, ma proviamo certamente il nostro meglio per farlo durante il test unitario. Leggere il proprio codice può essere un problema simile o peggiore. Molti campi usano mentori, giudici competitivi, allenatori, ecc. Anche noi contiamo architetti, ingegneri di sistema e tester. I clienti che hanno accesso a uno strumento di segnalazione dei bug o al servizio di assistenza clienti ti daranno feedback da fuori dalla tua testa una volta che il prodotto è stato messo in campo. Questa è un'altra grande ragione per l'approccio di Agile di rilasciare presto e spesso. Potresti essere l'unico sviluppatore della tua azienda, ma ci sono persone interessate dal tuo codice che possono darti un feedback su di esso da un certo punto di vista.

"Si tratta di un problema più piccolo di quello che penso che sia, oppure è un problema riscontrato anche da altri?"

Sheesh. Già abbastanza. Se il codice è in produzione, privo di bug e facendo ciò che dovrebbe fare, l'architettura non è importante. Almeno per ora.

Tutti noi speriamo di imparare mentre andiamo. Ho scritto un sacco di codice di cui ero orgoglioso al momento in cui l'ho scritto, solo per decidere che era orribile un anno o due dopo. In questo momento sto lavorando a un progetto pluriennale pieno di codice incredibilmente croccante, ma il codice funziona. Sto adottando un approccio molto conservativo per toccarne uno qualsiasi.

E così dovresti. Se al momento non riesci a vedere i principali problemi di architettura, dopo un anno di lavoro, penso che per te sia sicuro assumere, per ora, che non ce ne siano di importanti. Questo non è cattivo artigianato. Sta andando avanti.

Oltre alle altre risposte, ti consigliamo di andare a una conferenza degli sviluppatori.

Questo ti esporrà a un sacco di argomenti e persone che ti faranno pensare alla tua app e al tuo posto di lavoro. Soprattutto perché parleranno di ciò che funziona e non per quel momento, e dei problemi che emergono. C'è una grande probabilità che ci sia qualche sovrapposizione con la tua app.

Preferibilmente, impiegano 3 giorni per questo. L'ho trovato abbastanza lungo da ottenere la necessaria distanza mentale dal mio lavoro e guardarlo attraverso gli occhi di una comunità più ampia (per così dire), piuttosto che il mio.

Per inciso, questo vale anche per le squadre di persone, dal momento che il pensiero di gruppo può accadere ovunque.

Infine, se non ottieni l'approvazione per questo, per esempio una volta all'anno, cambia lavoro.

• Pratica modelli di progettazione e best practice
• Scegli un framework, strumenti, pacchetti ecc. in base alle tue esigenze e alle tue esigenze: per questo devi leggere molti blog di etch e trovare soluzioni per ogni singolo problema tecnico
• Crea una bozza di design / architettura e discuti con qualcuno che è bravo in questioni tecniche / architettoniche. Migliora questa bozza usando feedback e commenti. continua così fino a raggiungere lo stato stabile.

• Implementa il codice in modo che tutto ciò di cui l'app abbia bisogno sia configurabile e manutenibile

  La re-architettura e il reimplementing del tuo progetto porteranno sicuramente a un'app con coerenza, prestazioni, ecc.

Credo che "dare un calcio" alle preoccupazioni con alcune persone intelligenti aiuti. Devono esserci informazioni specifiche. È un sito web 24x7x365? App LoB? Dove è in esecuzione o ospitato?

Una volta raggiunti gli obiettivi principali e i risultati desiderati, gli altri possono aiutare a focalizzare e indirizzare la tua attenzione. Il tuo codice potrebbe essere il miglior codice mai scritto per un'attività specifica, o il peggiore. In realtà non importa: in che modo ciò influisce sull'obiettivo desiderato?