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

Ho trascorso l'ultimo anno come team one-man a sviluppare un'applicazione rich-client (35.000+ LoC, per quello che vale). Attualmente è stabile e in produzione. Tuttavia, so che le mie capacità erano arrugginite all'inizio del progetto, quindi senza dubbio ci sono problemi importanti nel codice. A questo punto, la maggior parte dei problemi riguarda l'architettura, la struttura e le interazioni: i problemi facili, anche quelli di architettura / progettazione, sono già stati eliminati.

Sfortunatamente, ho trascorso così tanto tempo con questo progetto che sto facendo fatica a pensare al di fuori di esso - affrontandolo da una nuova prospettiva per vedere i difetti profondamente sepolti o inerenti al design.

Come posso uscire dalla mia testa e fuori dal mio codice in modo da poter avere un aspetto nuovo e migliorarlo?

Modi per avvicinarsi a questo:

• Trova qualcuno che abbia familiarità con la tecnologia e il problema aziendale e parlane. Questo può essere difficile in un team di una sola persona ma è generalmente l'opzione migliore.
• Lavora su un progetto diverso per un po '. Anche questo può essere difficile, ma anche fare una pausa di una settimana può darti una nuova prospettiva.
• Guarda progetti o prodotti simili, ad esempio prodotti open source, se presenti. Fai attenzione a non copiare il codice ma potrebbero aver affrontato l'idea in modo completamente diverso.
• Impara una nuova lingua, libreria o framework. Le tecniche coinvolte possono darti un'idea di come affrontare gli stessi problemi che hai in modo diverso.
• Leggi un buon libro / blog / rivista sul design o sul linguaggio / quadro. Non sono sicuro del tuo livello di abilità, ma ci sono molte alternative in altre risposte su questo sito.

Se hai esempi specifici che desideri vengano indirizzati, magari pubblicali qui.

Debug di paperelle di gomma : siediti con un pezzo di codice o un modulo o una funzione e spiegalo ad alta voce. Quando ti ritrovi a dire qualcosa che sembra sbagliato, sciocco o semplicemente non giusto, scrivilo come un problema da indagare.

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

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

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

Un breve ricordo aiuta. Sono stato conosciuto per lamentarmi dell '"idiota" che ha cambiato qualcosa una settimana fa, solo per scoprire dal controllo della fonte sono stato io.

Un buon primo passo è identificare il codice che potrebbe essere migliorato. Cerca nel controllo del codice sorgente i file che cambiano più spesso. Con quale codice è più difficile lavorare? Quale codice produce il maggior numero di bug? Quali tipi di modifiche causano un effetto a catena in tutto il codice? A questo punto, non devi sapere perché il codice è problematico, solo che è problematico.

Dopo aver identificato le aree su cui lavorare, prova a capire quale sia effettivamente il problema. Ci sono libri che adottano un approccio sistematico alla categorizzazione dei 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 ti permettono di guardare il tuo codice in modo obiettivo.

Una volta identificato il problema probabile, prova diversi modi per risolverlo. Ad esempio, se la regola che hai infranto è "preferisci la composizione rispetto all'eredità", cambiala in composizione e vedi come ci si sente.

Ovviamente, può essere utile avere qualcun altro a guardare il codice, ma non è sempre così utile come si potrebbe pensare, perché hai molta più familiarità con i tipi di problemi che il codice causa rispetto a chiunque altro, e le ragioni dietro il design . Imparare alcuni modi per valutare obiettivamente il proprio progetto pagherà grandi dividendi.

Chiedi a un'altra persona di guardare il tuo codice. Se non riesci a trovare un'altra persona a guardarla, scrivi una descrizione completa dell'interazione come mostrerai a un'altra persona. Il processo di cercare di spiegare le tue decisioni a un'altra persona (anche se è solo per esercitarsi) può aiutarti davvero a capire PERCHÉ stai facendo le cose in un certo modo e ti aiuta a vedere eventuali buchi nella tua logica.

Conosco molto bene questa situazione. Quando rimango bloccato in quel modo, provo a prendere diversi punti di vista sul progetto.

1.) Punto di vista dell'utente / cliente: utilizzare il feedback

Purtroppo nel nostro codice siamo catturati in un modo in cui non siamo in grado di vedere i nostri difetti perché usiamo le nostre applicazioni nel modo in cui le abbiamo codificate. Guarda come le persone lo usano e cerca di capire quale sarebbe la guida utente più intuitiva. Gioca con i prototipi dell'interfaccia utente. Questo sembra essere divertente, ma se scopri che saresti costretto a ricodificare enormi parti del tuo codice semplicemente cambiando la logica di utilizzo di quanto sia tempo di iniziare un ciclo di riprogettazione.

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

Alcuni IDE e framework ti spingono ad esempio a mescolare l'interfaccia utente e il codice back-end. Se lasci che ciò accada, un giorno affronterai la situazione che difficilmente la tua base di codice può essere mantenuta a causa di dipendenze nebulose e difficili da spezzare. Soprattutto la miscelazione del codice UI con altri codici può portare a spaghetti code e funzionalità ridondanti. Dividi il tuo codice in blocchi funzionali come ad es. Classi di database, classi di comunicazione, classi UI, classi core ecc. E dai ai blocchi funzione pronunciando nomi. Quindi visualizza la funzionalità con uno strumento grafico (utilizzo 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 puoi sostituirli con 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 di codice sembra un cluster completo ***, allora è il momento di agire. Se non è ancora successo, dovresti pensare a una convenzione di denominazione adatta che rappresenti la tua struttura di codice in un modo in cui non devi pensare a come chiamarlo e a cosa fa.

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

La mia preferita è la FMEA. In termini di codifica ciò significa non solo analizzare cosa è andato storto in passato, ma anche pensare a cosa potrebbe andare storto. Un esempio abbastanza comune è una connessione di rete improvvisamente interrotta. Dopo aver effettuato l'operazione, è possibile classificare le condizioni di errore in base a conseguenze quali perdita di dati, crash, calcoli errati e valutare l'impatto sull'utente. Se non ancora fatto, la definizione di classi e routine di errore semplificate e di eccezioni può aiutarti a mantenere il codice pulito e chiaro. Il modo migliore è implementare quelli in ogni nuova pace di codice prima ancora di iniziare a scrivere qualsiasi altra cosa. (Beh, sono colpevole non sempre a seguire questo consiglio da solo.)

Inoltre mi ha aiutato a generare e aggiornare frequentemente un "elenco di proposte di miglioramento" per il mio codice. (Ad essere sinceri, nei miei progetti c'è ancora molto codice di cui non sono assolutamente orgoglioso.) Cerco anche di prendermi il tempo per raccogliere e dare un'occhiata al codice delle migliori pratiche da documentazioni API, conferenze degli sviluppatori o riviste degli sviluppatori.

Fino a questo punto non è necessario toccare il codice. Si tratta semplicemente di rendersi conto di cosa non va e di trovare un modo per definire come migliorare il codice.

Finalmente alcuni consigli per il lavoro quotidiano di una vecchia scoreggia. Cerca di evitare di mordere più di quello che puoi mangiare. Questo porta a troppa pressione per una codifica pulita. Raramente hai il tempo di farlo bene, ma dovrai prenderti il ​​tempo per riparare i difetti in seguito.

Niente è di lunga durata come la soluzione provvisoria, ma quando si rompe spesso è troppo tardi per risolverlo in tempo. Esempi sono brutti hack o strane eccezioni che ho usato per far funzionare qualcosa, ad esempio un difetto nel framework o nel sistema operativo sottostante. E poi il difetto viene risolto o la nuova versione semplicemente lascia cadere 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 sempre di più 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. (Chi è senza peccato in mezzo a te, lascia che mi lanci il primo byte).

Non sudare le piccole cose.

Tutti potrebbero programmare 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 log dei bug e trova le routine che potrebbero causare problemi. Quando trovi i bug, puoi anche rivedere il codice e pensare a cosa potrebbe renderlo più efficiente. Il più delle volte, ti renderai conto che oltre a correggere il bug stesso, non sarai in grado di fare un notevole miglioramento, ma a volte ti renderai conto che c'è un modo migliore per fare qualcosa.

Parla con gli utenti e scopri dove stanno notando problemi, sia di UX che di velocità. Risolvi questi problemi, cercando di 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 che devi apportare. Quindi pensa a come avresti potuto rendere il sistema più flessibile, tramite API o sviluppo guidato dai test. In molti casi, scoprirai che puoi semplicemente iniziare a inserire queste API nel codice, senza una grande quantità di modifiche. In altri casi, ti renderai conto che lo sforzo di migliorare il codice non ne vale la pena.

I cambiamenti incrementali possono essere difficili. L'obiettivo è non riscrivere interamente la base di codice se non è necessario. Certo, sei un programmatore migliore ora di quanto non fossi un anno fa, ma quello che hai deve funzionare in questo momento. Tra 5 anni, quando un programmatore junior si lamenta con te del codice legacy, deve cercare di risolvere il problema, basta sorridere e annuire, e non ammettere di averlo scritto.

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

Le revisioni tra pari consentono a qualcuno che è già fuori di testa di dare il tuo consiglio. Stack Exchange Code Review potrebbe essere un buon posto per mettere in revisione un codice non particolarmente proprietario della tua azienda. Probabilmente non è in grado di gestire blocchi enormi, ma molti programmi sono costituiti da un sacco di codice semplice e da qualche altro codice che non è semplice e crea molti problemi. Se hai un esempio di un codice tipico, ma che 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 rivedere tutto il messaggio che passa, 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 proprio codice ma certamente facciamo del nostro meglio per farlo durante il test unitario. Leggere il proprio codice può essere un problema simile o peggiore. Molti settori utilizzano mentori, giudici competitivi, allenatori, ecc. Lo stesso vale se contiamo architetti, ingegneri di sistema e tester. I clienti con accesso a uno strumento per la segnalazione di bug o al reparto di assistenza clienti ti forniranno un feedback dall'esterno della tua testa una volta che il prodotto sarà 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 feedback al riguardo da una certa angolazione.

"È un problema più piccolo di quello che penso, o è un problema riscontrato anche da altri?"

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

Speriamo che tutti noi impariamo mentre andiamo. Ho scritto un sacco di codice di cui ero orgoglioso al momento in cui l'ho scritto, solo per decidere che è stato terribile uno o due anni dopo. In questo momento sto lavorando a un progetto pluriennale pieno di codice incredibilmente crufty, ma il codice funziona. Sto adottando un approccio molto conservativo per toccarlo.

E anche tu dovresti. Se non vedi alcun problema di architettura in questo momento, dopo un anno di lavoro, penso che potrebbe essere sicuro per te presumere, per ora, che non ci siano problemi importanti. Questa non è cattiva arte. Sta andando avanti.

Oltre ad altre risposte, consiglierei di andare a una conferenza degli sviluppatori.

Questo ti esporrà a molti 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 allora, e dei problemi che si presentano. È molto probabile che ci sia qualche sovrapposizione con la tua app.

Preferibilmente, impiega 3 giorni per questo. Ho scoperto che è abbastanza lungo da ottenere la distanza mentale necessaria per il mio lavoro e guardarlo attraverso gli occhi di una comunità più ampia (per così dire), piuttosto che la mia.

Per inciso, questo vale anche per le squadre di persone, poiché il pensiero di gruppo può accadere ovunque.

Infine, se non si ottiene l'approvazione per questo, diciamo una volta all'anno, cambiare lavoro.

• Pratica modelli di progettazione e buone pratiche
• Scegli un framework, strumenti, pacchetti ecc. In base ai requisiti e alle esigenze della tua app - per questo devi leggere molti blog etch e trovare soluzioni per ogni singolo problema tecnologico
• Crea bozze di design / architettura e discuti con qualcuno che è bravo in cose tecniche / architettoniche. Migliora questa bozza usando feedback e commenti. continua a farlo fino a raggiungere uno stato stabile.

• Implementa un codice in modo tale che tutto ciò di cui l'app abbia bisogno sia configurabile e gestibile

  la ri-architettura e la reimplementazione del progetto risulteranno sicuramente in app con una migliore coerenza, prestazioni, ecc.

Credo che aiutare a risolvere le preoccupazioni con alcune persone intelligenti. Ci devono essere informazioni specifiche. È un sito Web 24x7x365? App LoB? Dove è in esecuzione o ospitato?

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