Come si mantiene una codebase di scarsa qualità?

https://stackoverflow.com/questions/642102

22-07-2019
|

Domanda

Per poter mantenere il codice che scrivo, devo nominare bene le variabili, documentare il mio codice, assicurarmi che nulla venga ripetuto, che le astrazioni funzionino in modo che non siano necessari hack.e commenta con parsimonia perché i commenti spesso mi interrompono nella lettura del codice.

Ma molte altre basi di codice che ho visto sono più simili a un vortice.I nomi delle variabili sono foobar, le cose vengono calcolate anche se non sono mai necessarie, vengono applicati molti hack e patch, le astrazioni falliscono, gli script di distribuzione falliscono...Il codice è una zuppa incomprensibile e quasi inutilizzabile.

COSÌ!Sono curioso.Come riesci a mantenere una base di codice di scarsa qualità?

Soluzione

Disciplina

Altri suggerimenti

Refactoring costante; quando apri un file di codice e vedi qualcosa di strano, puoi investire qualche minuto per migliorare il design del codice esistente.

Avere una serie di test unitari può esserti utile, poiché ti dà la certezza che il codice che stai modificando funzioni o si interrompe a causa della modifica.

È un po 'come la storia di avere una finestra rotta in una casa. Quando vedi una finestra rotta, dovresti ripararla. Se non lo risolvi, le cose inizieranno a disintossicarsi da lì, e si tradurrà in un disordine non mantenibile.

La maggior parte dei miei progetti sono anche messi in opera ContinuousIntegration; accanto alla costruzione e all'esecuzione di unittest, viene eseguita anche un'analisi del codice statico (fxcop). Di tanto in tanto, guardo i risultati e provo a correggere alcune violazioni che vengono segnalate.

Generalmente ciò che descrivi è la tendenza naturale di qualsiasi base di codice ad aumentare l'entropia. Succede in ogni progetto in virtù del suo sviluppo e mantenimento. Per combattere questo costante aumento, suggerirei quanto segue:

Qualcuno del team con sufficiente autorità deve occuparsene. Questa è la parte più importante Se a nessuno importa, non sarà fatto. Questo punto sembra ovvio, ma non lo è.
Stabilisci standard e best practice. La maggior parte delle lingue ha un libro scritto da qualcuno sulle migliori pratiche. Ad esempio in PERL c'è un ottimo libro Perl Best Practices di Damain Conway. A meno che tu non lo faccia, ogni persona del team ha il suo modo di scrivere codice, denominare le variabili, commentare e così via.
Recensioni di codice. Sarà necessario un elenco di controllo per le revisioni del codice. Non è sufficiente che la modifica funzioni, ma deve anche essere conforme all'elenco delle migliori pratiche. Abbiamo impostato una revisione del codice a due livelli, il primo livello è la revisione del codice peer e il secondo livello è un responsabile del rilascio che si preoccupa della qualità del codice.
Recensioni di design. Quando il bug o il miglioramento vengono inseriti nel sistema di tracciamento dei bug, è importante che venga esaminato da una scheda di controllo delle modifiche, che decide sulla pianificazione del lavoro e anche su chi deve rivedere la progettazione del lavoro. Qui è dove si mantengono le astrazioni del codice e ci si assicura che la modifica sia conforme ai documenti di progettazione e agli obiettivi del progetto. L'architetto del software del team o un lead designer dovrebbero far parte del CCB.
Trigger della qualità del codice di check-in. Alcune buone pratiche possono essere applicate direttamente dal codice. Scrivi piccoli script che controllano il tuo codice per cose come la formattazione, l'uso di schede / spazi e così via. Questo ti aiuterà a pensare alla qualità del codice in modo diverso.

Alcuni lettura per riferimento.

Le revisioni tra pari stabiliscono rapidamente una norma di qualità del codice che è difficile da quantificare su un pezzo di carta. I test unitari ti consentono di cambiare codice con poca paura. Disciplina, molto.

Una domanda correlata: in che modo le persone riescono a scrivere codice di scarsa qualità?

Ecco la risposta.

Una buona strategia per le persone incompetenti nel nostro settore è questa:

Sviluppa la capacità di suonare in modo impressionante soprattutto per le persone non tecniche e semi-tecniche. Essere in grado di sembrare abbastanza plausibile per il personale tecnico, abbastanza per tenerli sbilanciati.
Crea un pasticcio completo del codice che tocchi.
Ora questa è la parte cruciale: lasciare e trovare un lavoro migliore altrove prima di essere scoperto. Il miglior tempismo dipenderà dalle circostanze particolari.

Vorrei presentarvi un termine che ho sentito alcuni anni fa - Debito tecnico . Ecco una (1) voce Wikipedia e un'altra da (2) sito web .

In sostanza, non penso che le persone inizino a puntare a costruire software scadenti. Ciò che accade in genere è che i tempi sono compressi, i requisiti sono modificati o sostituiti a metà sviluppo e qualsiasi numero di altre realtà commerciali punge al centro dello sviluppo e del design di qualità.

Da Fowler:

" fare le cose in modo rapido e sporco ci pone con un debito tecnico, che è simile a un debito finanziario. Come un debito finanziario, il tecnico il debito comporta pagamenti di interessi, che venire sotto forma dello sforzo extra che dobbiamo fare in futuro sviluppo a causa del rapido e scelta di design sporca. "

Da Wikipedia:

" Attività che potrebbero essere posticipate include documentazione, test di scrittura, partecipare a commenti TODO e affrontare compilatore e codice statico avvisi di analisi. Altre istanze di il debito tecnico include la conoscenza che non è condiviso all'interno dell'organizzazione e codice troppo confuso per essere facilmente modificato. "

Quello che ho visto (e diretto diversi team di sviluppo a fare) è di refactoring e ripulire la base di codice nelle iterazioni di sviluppo, di solito all'inizio prima dello sviluppo di nuovi lavori.

Revisioni tra pari, unit test e tester software professionali aiutano tutti a rimborsare parte di tale debito tecnico, nonché buone previsioni (e buon riutilizzo del codice).

Se disponi del budget, i test automatici possono essere un investimento valido fintanto che sei disposto a pagare il mantenimento (tempo, impegno).

Oggi ci sono molti strumenti di qualità come fxCop (e altri simili), tuttavia devi scegliere attentamente quali approcci intendi intrattenere.

Lo sforzo nel mantenere la qualità nella progettazione e nella base di codice deve essere preso in considerazione, quindi pensa attentamente al modo più efficace e utile per il tuo team di sviluppo / prodotto / azienda / clienti ecc.

[(1) http://en.wikipedia.org/wiki/Technical_debt ]
[(2) http://martinfowler.com/bliki/TechnicalDebt.html ]

Questo è proprio il caso in cui tu scrivi il codice e altro la gente lo legge
1.Lasciato il cattive abitudini
2. Usa significativo procedura, funzione, nome di variabile
3. Utilizzare la documentazione su come funziona (procedura/funzione/calcolo/ecc.) e cosa è risultato da cosa, non fare commenti non necessari
4.Prova a dai stile alla tua codifica in modo che le persone possano saperlo (come usare il codice in stile GNU)
O
Usa l'abbellitore del codice per questo
5. Pensa a lavorare in squadra (anche se fossi solo) e non solo tu che leggerai il tuo codice (anche se lo fosse)
6. Codice di refactoring dovrebbe essere buono lo stesso
7. Consultati con i tuoi compagni di squadra riguardo al codice che stavi scrivendo, possono leggerlo?
8. Impara dalla comunità OpenSource, come funzionano e condividono codici e patch
9.Se puoi, usa SVN o CVS per mantenere il tuo codice

e ricorda BACIO principio (Keep IOT Ssemplice, Sstupido)

e naturalmente Semplice, snello, cattivo e bello

se fosse invertito (gli altri scrivono, tu leggi) non sapevo cosa dire :D (magari dare consigli alle persone sopra LOL)

Documentazione, controllo del codice sorgente, unit-test ed essere un buon programmatore.

Una suite completa di test unitari che consente modifiche e refactoring senza preoccuparsi di violare il codice esistente.

Consiglio di ritirare una copia di Michael Feather "Lavorando in modo efficace con il codice legacy".

Fridgemagnet dice: " I programmatori ottusi hanno basi di codice immacolate "

Puoi evitare di mantenere una base di codice male solo quando sei un team di sviluppo molto piccolo (meno di 10-20 persone in un singolo progetto). Se il tuo progetto cresce e il tuo team cresce, le tue pratiche aumenteranno o fallirai.

Il cambiamento che stai chiedendo è essenzialmente il passaggio dall'hacking alla programmazione e infine all'ingegneria del software.

Con Software Engineering riconosci che non tutti nel team sono perfetti. Esamini il codice, ti assicuri che gli altri testino, ti controlli reciprocamente.

Inizi a vedere la necessità di un architetto in grado di digerire i desideri dei clienti e tradurli in un documento di progettazione. Questo può facilmente consumare un mese prima che chiunque altro venga aggiunto al progetto (ma nel corso del tempo di sviluppo può risparmiare mesi o addirittura anni!). Si assicura che tutto abbia un senso e si adatterà ragionevolmente bene insieme.

Hai documenti di progettazione, generalmente basati su UML, in modo che diverse parti del team possano comprendere i punti di integrazione. Riconosci che tutto ciò che è stato fatto, potrebbe essere necessario rifarlo senza le persone che lo hanno fatto, quindi documentalo.

Il tuo processo di qualità diventa molto più rigoroso e iniziano a far rispettare le regole come se tu controllassi solo le modifiche che affrontano bug specifici durante il test.

Test, refactoring, ecc. sono ovviamente fondamentali e rafforzati da peer e revisione del team.

Non sto dicendo che questo tipo di cose è sempre necessario, ovviamente non lo è, ma nella tua domanda, discuti basi di codice crufty, e queste buone pratiche sono spesso la soluzione a questo problema.

Di solito queste buone pratiche sono implementate dopo un progetto GIANT che fallisce completamente perché la base di codice fa schifo così male. Quindi licenziano chiunque non riesca a schivare la colpa, assumono alcuni manager che si spera abbiano qualche esperienza con progetti più grandi e (se non finiscono i soldi) ricominciano da zero.

Almeno questa è la mia esperienza. YMMV

Hai solo bisogno di pratica, buoni strumenti e abilità e volontà di spezzare le cattive abitudini e imparare.

La codifica è molto simile alla scrittura a mano. Ognuno ha il proprio stile distinto. Una delle maggiori sfide che ho dovuto affrontare mantenendo il codice legacy, è cercare di capire cosa sta succedendo. Di solito si riduce alla mancanza di coerenza nella base di codice.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow