Come mantenere un prodotto software grande e complesso mantenibile negli anni?

L'unica vera soluzione per evitare la decomposizione del codice è codificare bene!

Come codificare bene è un'altra domanda. È già abbastanza difficile anche se sei un eccellente programmatore che lavora da solo. In una squadra eterogenea, diventa molto più difficile ancora. In outsourcing (sotto) progetti ... solo pregare.

Le solite buone pratiche possono aiutare:

1. Mantieni la semplicità.
2. Mantieni tutto semplice. Questo vale soprattutto per l'architettura, la "grande immagine". Se gli sviluppatori hanno difficoltà a ottenere il quadro generale, stanno andando a codificarlo contro di esso. Quindi, semplifica l'architettura in modo che tutti gli sviluppatori la ottengano. Se l'architettura deve essere meno che semplice, allora gli sviluppatori devono essere addestrati per capire quell'architettura. Se non lo interiorizzano, non dovrebbero codificarlo.
3. Punta su basso accoppiamento e alta coesione . Assicurati che tutti nel team comprendano questa idea. In un progetto costituito da parti unite e non coesive, se alcune parti diventano disordine non modificabili, è sufficiente scollegare e riscrivere quella parte. È più difficile o quasi impossibile se l'accoppiamento è stretto.
4. Sii coerente. Quali standard da seguire contano poco, ma per favore segui alcuni standard. In una squadra, tutti dovrebbero seguire gli stessi standard di corso. D'altra parte, è facile diventare troppo attaccati agli standard e dimenticare il resto: per favore capisci che mentre gli standard sono utili, sono solo una piccola parte del buon codice. Non fare un gran numero di esso.
5. Le revisioni del codice possono essere utili per far lavorare una squadra in modo coerente.
6. Assicurati che tutti gli strumenti - IDE, compilatori, controllo di versione, sistemi di compilazione, generatori di documentazione, librerie, computer , sedie , ambiente generale ecc. ecc. - sono ben mantenuti in modo che gli sviluppatori non debbano sprecare tempo con problemi secondari come la lotta ai conflitti di versione dei file di progetto, gli aggiornamenti di Windows, il rumore e qualsiasi cosa banale ma irritante. Dover sprecare ripetutamente tempo considerevole con cose così poco interessanti riduce il morale, che almeno non migliorerà la qualità del codice. In una squadra numerosa, potrebbero esserci uno o più ragazzi il cui compito principale è mantenere gli strumenti di sviluppo.
7. Quando prendi decisioni tecnologiche, pensa a cosa ci vorrebbe per cambiare la tecnologia; quali decisioni sono irreversibili e quali no. Valuta attentamente le decisioni irreversibili. Ad esempio, se decidi di scrivere il progetto in Java , questa è una decisione decisamente irreversibile. Se decidi di utilizzare un formato binario auto-bollito per i file di dati, è anche una decisione abbastanza irreversibile (una volta che il codice è uscito allo scoperto e devi continuare a supportare quel formato). Ma i colori della GUI possono essere facilmente regolati, le funzionalità inizialmente escluse possono essere aggiunte in seguito, quindi sottolinea meno questi problemi.

Test unitari sono tuoi amici . Implementandoli costringe l'accoppiamento basso. Significa anche che le parti "hacky" del programma possono essere facilmente identificate e rielaborate. Significa anche che qualsiasi modifica può essere testata rapidamente per garantire che non interrompano la funzionalità esistente. Questo dovrebbe incoraggiare i tuoi sviluppatori a modificare i metodi esistenti piuttosto che duplicare il codice per paura di rompere le cose.

I test unitari funzionano anche come ulteriore documentazione per il tuo codice, delineando ciò che ogni parte dovrebbe fare. Con numerosi test unitari, i tuoi programmatori non dovrebbero conoscere l'intera architettura del tuo programma per apportare modifiche e utilizzare le classi / i metodi in uscita.

Come effetto collaterale, anche i test unitari potrebbero ridurre il numero di bug.

Tutti qui menzionano rapidamente il codice del codice e sono completamente d'accordo e in accordo con questo, ma manca ancora l'immagine più grande e il problema più grande qui a portata di mano. Il codice rot non si verifica solo. Inoltre, vengono menzionati i test unitari che sono buoni, ma in realtà non risolvono il problema. Si può avere una buona copertura del test unitario e un codice relativamente privo di bug, tuttavia hanno ancora codice e design marcati.

Hai menzionato che lo sviluppatore che lavora su un progetto ha difficoltà nell'implementazione di una funzionalità e perde l'immagine più grande dell'architettura generale e quindi implementa un hack nel sistema. Dov'è la leadership tecnica per imporre e influenzare il design? Dove sono le revisioni del codice in questo processo?

In realtà non soffri di decomposizione del codice, ma stai suffragando da Rotazione team . Il fatto è che non dovrebbe importare se i creatori originali del software non sono più nella squadra. Se il capo tecnico del team esistente comprende appieno il design di base e non ha alcun valore nel ruolo di lead tecnologico, questo sarebbe un non-problema.

Ci sono molte cose che possiamo fare:

Assegna a una persona la responsabilità generale dell'architettura. Quando scegli quella persona, assicurati di avere la visione e l'abilità per sviluppare e mantenere un'architettura, e che hanno l'influenza e l'autorità per aiutare altri sviluppatori a seguire l'architettura. Quella persona dovrebbe essere uno sviluppatore esperto che ha fiducia nella gestione e che è rispettato dai suoi pari.

Crea una cultura in cui tutti gli sviluppatori diventano proprietari dell'architettura. Tutti gli sviluppatori devono essere coinvolti nel processo di sviluppo e mantenimento dell'integrità architettonica.

Sviluppa un ambiente in cui le decisioni architettoniche siano facilmente comunicate. Incoraggia le persone a parlare di design e architettura - non solo nel contesto del progetto attuale, ma anche in generale.

Le migliori pratiche di codifica rendono l'architettura più facile da vedere dal codice: prendi tempo per il refactoring, per commentare il codice, per sviluppare test unitari, ecc. Cose come convenzioni di denominazione e pratiche di codifica pulita possono aiutare molto nella comunicazione dell'architettura, così come team di cui hai bisogno per prendere tempo per sviluppare e seguire i tuoi standard.

Assicurati che tutta la documentazione necessaria sia chiara, concisa, aggiornata e accessibile. Rendi pubblici sia i diagrammi di architettura di alto livello sia quelli di basso livello (bloccandoli a muro può essere d'aiuto) e pubblicamente mantenibili.

Infine (come perfezionista naturale) ho bisogno di riconoscere che l'integrità architettonica è un'aspirazione degna, ma che ci possono essere cose più importanti - come costruire una squadra che può funzionare bene insieme e spedire effettivamente un prodotto funzionante.

Il modo in cui risolvo questo problema è di prenderlo alla radice:

La mia spiegazione utilizzerà i termini di Microsoft / .NET , ma sarà applicabile a qualsiasi piattaforma / toolbox :

1. Utilizza gli standard per la denominazione, la codifica, i check-in, il flusso di errori, il flusso di processo, in pratica qualsiasi cosa.
2. Non aver paura di dire addio ai membri del team che non aderiscono agli standard. Alcuni sviluppatori semplicemente non possono lavorare all'interno di un insieme definito di standard e diventeranno i nemici della 5a colonna sul campo di battaglia per mantenere pulito il codice
3. Non aver paura di allocare i membri del team con competenze più basse ai test per lunghi periodi di tempo.
4. Utilizza tutti gli strumenti del tuo arsenale per evitare il controllo del codice in putrefazione: questo include strumenti dedicati, nonché test test unitari che verifica i file di costruzione, i file di progetto, la struttura di directory, ecc.
5. In una squadra di circa 5-8 membri, chiedi al tuo miglior ragazzo di eseguire il refactoring quasi costantemente, ripulendo il disordine lasciato dagli altri. Anche se trovi i migliori specialisti del settore, avrai ancora un casino - è inevitabile, ma può essere limitato dal costante refactoring.
6. Scrivi i test unitari e mantienili - NON dipendere dai test delle unità per mantenere pulito il progetto, non lo fanno.
7. Discuti di tutto. Non aver paura di passare ore a discutere di cose nella squadra. Questo diffonderà le informazioni e rimuoverà una delle cause principali del codice errato: confusione su tecnologie, obiettivi, standard, ecc.
8. Siate molto attenti con i consulenti che scrivono codice: il loro codice sarà, quasi per definizione, la vera roba di merda.
9. Esamina preferibilmente la fase del processo prima del check-in. Non abbiate paura di eseguire il rollback.
10. Non utilizzare mai il principio di apertura / chiusura a meno che non sia nell'ultima fase precedente alla pubblicazione: porta semplicemente al codice di decomposizione viene lasciato odorare.
11. Ogni volta che si verifica un problema, prenditi il tempo necessario per comprenderlo al meglio prima di implementare una soluzione: la maggior parte del codice viene dall'implementazione di soluzioni a problemi non completamente compresi.
12. Utilizza le tecnologie giuste. Questi sono spesso disponibili in set e freschi: è meglio dipendere da una versione beta di un framework di cui si garantisce il supporto in futuro, piuttosto che dipendere da framework estremamente stabili, ma obsoleti, che non sono supportati.
13. Assumi le persone migliori.
14. Disattiva il resto: non gestisci un bar.
15. Se il management non è il migliore architetto e interferisce nel processo decisionale - trova un altro lavoro.

Pulisci il codice marcato eseguendo il refactoring, mentre scrivi i test unitari. Paga (questo) il debito di progettazione su tutto il codice che tocchi, ogni volta che:

• Sviluppa una nuova funzione
• Risolve un problema

Velocizza notevolmente il tuo ciclo di sviluppo di prova:

• Refactoring per convertire i moduli di codice in un linguaggio di scripting
• Utilizza macchine di prova veloci basate su cloud

Codice di refactoring per utilizzare l'accoppiamento basso (di unità altamente coesive internamente) di:

• Più semplice, (più) funzioni (routine)
• Moduli
• Oggetti (e classi o prototipi)
• Funzioni pure (senza effetti collaterali)
• Preferenza della delega, sull'eredità
• Livelli (con API)
• Collezioni di piccoli programmi one-purpose che possono operare insieme

La crescita organica è buona; il design in grande stile è pessimo.

Avere un leader che sia ben informato sul design attuale. In caso contrario, leggi il codice del progetto fino a quando non sei esperto.

Leggi i libri di refactoring.

Risposta semplice: non puoi .

Ecco perché dovresti mirare a scrivere piccolo e semplice software. Non è facile.

Questo è possibile solo se pensi abbastanza a lungo sul tuo problema apparentemente complesso per definirlo nel modo più semplice e conciso possibile.

La soluzione a problemi veramente grandi e complessi può spesso essere risolta costruendo su moduli piccoli e semplici.

In altre parole, come altri hanno sottolineato, la semplicità e l'accoppiamento lento sono gli ingredienti chiave.

Se ciò non è possibile o fattibile, probabilmente stai facendo ricerche (problemi complessi senza soluzioni semplici note o nessuna soluzione nota). Non aspettarti che la ricerca produca direttamente prodotti manutenibili, non è questo il tipo di ricerca.

Lavoro su un codice base per un prodotto che è stato in continuo sviluppo dal 1999, quindi come puoi immaginare ora è piuttosto complesso. La più grande fonte di hackiness nel nostro codebase è dalle numerose volte che abbiamo dovuto portarlo da ASP Classic a ASP.NET , da ADO a ADO.NET, dai postback a Ajax , passaggio a librerie UI, standard di codifica, ecc.

Nel complesso, abbiamo svolto un lavoro ragionevole nel mantenere la base di codici mantenibile. Le principali cose che abbiamo contribuito a questo sono:

1) Refactoring costante - se devi toccare un pezzo di codice che è macchinoso o difficile da comprendere, ci si aspetta che ci impieghi il tempo extra per ripulirlo e gli venga dato il margine di manovra il programma per farlo. I test unitari rendono questo molto meno spaventoso, perché puoi testare più facilmente le regressioni.

2) Mantieni un ambiente di sviluppo pulito - stai attento all'eliminazione del codice che non è più utilizzato e non lasciare copie di backup / copie di lavoro / codice sperimentale nella directory del progetto.

3) Standard di codifica coerenti per la vita del progetto - Ammettiamolo, le nostre opinioni sugli standard di codifica si evolvono nel tempo. Suggerisco di attenersi allo standard di codifica che hai iniziato per la vita di un progetto, a meno che tu non abbia il tempo di tornare indietro e aggiornare il codice per conformarsi al nuovo standard. È fantastico che tu abbia superato la notazione ungherese ora, ma applichi quella lezione a nuovi progetti e non solo passi a metà del flusso su quel nuovo progetto.

Poiché hai taggato la domanda con la gestione del progetto, ho provato ad aggiungere alcuni punti non codificati:)

• Pianifica il turnover - supponi che l'intero team di sviluppo sarà scomparso nel momento in cui ha raggiunto la fase di manutenzione - nessuno sviluppatore che valga la pena di essere aggiornato rimarrà bloccato per sempre. Inizia a preparare i materiali di consegna non appena hai tempo.

• La coerenza / uniformità non può essere sottolineata abbastanza. Ciò scoraggerà la cultura del "go-it-alone" e incoraggerà i nuovi sviluppatori a chiedere, se sono in dubbio.

• Mantieni mainstream - tecnologie utilizzate, schemi di progettazione e standard - perché un nuovo sviluppatore del team (a qualsiasi livello) avrà più possibilità di essere subito operativo.

• La documentazione, in particolare l'architettura, perché sono state prese le decisioni e gli standard di codifica. Inoltre, mantieni riferimenti / note / tabelle di marcia per documentare il dominio aziendale: rimarrai stupito di quanto sia difficile per le aziende spiegare ciò che fanno a uno sviluppatore senza esperienza di dominio.

• Definisci chiaramente le regole, non solo per il tuo attuale team di sviluppo, ma pensa ai futuri sviluppatori di manutenzione. Se questo significa mettere un collegamento ipertestuale alla progettazione pertinente e codificare la documentazione standard su ogni pagina, così sia.

• Assicurati che l'architettura e in particolare i livelli di codice siano chiaramente demarcati e separati - questo consentirà potenzialmente la sostituzione di strati di codice con l'arrivo di nuove tecnologie, ad esempio sostituendo un'interfaccia utente di Web Form con un HTML5 Interfaccia utente jQuery , ecc. ., che può acquistare circa un anno di longevità aggiunta.

Una proprietà di codice altamente raccomandabile è purezza della funzione .

Purezza significa che le funzioni dovrebbero restituire lo stesso risultato per gli stessi argomenti. Cioè, non dovrebbero dipendere dagli effetti collaterali di altre funzioni. Inoltre, è utile se non hanno effetti collaterali stessi.

Questa proprietà è più facile da vedere rispetto alle proprietà di accoppiamento / coesione. Non devi fare di tutto per ottenerlo, e personalmente lo ritengo più prezioso.

Quando la tua funzione è pura, il suo tipo è di per sé un'ottima documentazione. Inoltre, scrivere e leggere la documentazione in termini di argomenti / valore di ritorno è molto più semplice di uno che menziona alcuni stati globali (eventualmente accessibili da altri thread O_O).

Come esempio di utilizzo estremo della purezza per aiutare la manutenibilità, puoi vedere GHC . Si tratta di un grande progetto di circa 20 anni in cui vengono fatti grandi rifacimenti e sono ancora in fase di introduzione nuove funzionalità principali.

Infine, non mi piace troppo il punto "Keep it simple". Non puoi mantenere il tuo programma semplice quando stai modellando cose complesse. Prova a creare un semplice compilatore e il tuo codice generato risulterà probabilmente lento. Certo, puoi (e dovresti) rendere semplici le singole funzioni, ma l'intero programma non sarà semplice come risultato.

Oltre alle altre risposte, consiglierei i livelli. Non troppi ma sufficienti per separare diversi tipi di codice.

Utilizziamo un modello di API interno per la maggior parte delle applicazioni. C'è un'API interna che si collega al database. Quindi un interfaccia utente . Persone diverse possono lavorare su ogni livello senza interrompere o rompere altre parti delle applicazioni.

Un altro approccio è far leggere a tutti comp.risks e The Daily WTF in modo che apprendano le conseguenze del cattivo design e della cattiva programmazione e temono di vedere il proprio codice pubblicato su The Daily WTF .

Dal momento che molte di queste risposte sembrano concentrarsi su team biggish, anche fin dall'inizio, inserirò la mia opinione come parte di un team di sviluppo di due uomini (tre se includi il designer) per l'avvio.

Ovviamente, i design e le soluzioni semplici sono i migliori, ma quando hai il ragazzo che paga letteralmente il tuo salario che respira al collo, non hai necessariamente il tempo di pensare alla soluzione più elegante, semplice e manutenibile. Con questo in mente, il mio primo grande punto è:

Documentazione Non commenti, il codice dovrebbe essere principalmente auto-documentante, ma cose come documenti di progettazione, gerarchie e dipendenze di classe, paradigmi architettonici, ecc. Tutto ciò che aiuta un programmatore nuovo, o persino esistente, a capire la base di codice. Inoltre, la documentazione di quelle strane pseudo-librerie che appaiono alla fine, come "aggiungi questa classe a un elemento per questa funzionalità" può essere d'aiuto, poiché impedisce anche alle persone di riscrivere la funzionalità.

Tuttavia, anche se hai un limite di tempo severo, trovo che un'altra cosa buona da tenere a mente è:

Evita gli hack e soluzioni rapide. A meno che la correzione rapida non sia la correzione effettiva, è sempre meglio capire il problema sottostante a qualcosa, e quindi correggerlo. A meno che tu non abbia letteralmente uno scenario "ottieni questo lavoro nei prossimi 2 minuti, o sei licenziato", fare ora la correzione è un'idea migliore, perché non hai intenzione di correggere il codice in un secondo momento, stai solo andando passa al prossimo compito che hai.

E il mio suggerimento preferito personale è più di una citazione, anche se non riesco a ricordare la fonte:

"Codice come se la persona che viene dopo di te è uno psicopatico omicida che sa dove vivi"

Un principio che non è stato menzionato ma che trovo importante è il principio aperto / chiuso .

Non dovresti modificare il codice che è stato sviluppato e testato: ogni pezzo di codice è sigillato. Invece, estendi le classi esistenti per mezzo di sottoclassi, o usale per scrivere wrapper, classi decoratore o utilizzare qualsiasi modello che trovi adatto. Ma non modifica il codice di lavoro .

Solo i miei 2 centesimi.

• Diventa uno scout . Lascia sempre il codice più pulito di quello che hai trovato.

• Correggi finestre rotte . Tutti questi commenti "cambiano nella versione 2.0" quando sei sulla versione 3.0.

• Quando ci sono importanti hack, progetta una soluzione migliore come squadra e fallo. Se non riesci a sistemare l'hack come una squadra, allora non capisci abbastanza bene il sistema. "Chiedi aiuto a un adulto." Le persone più anziane in giro potrebbero averlo visto prima. Prova a disegnare o ad estrarre un diagramma del sistema. Prova a disegnare o ad estrarre i casi d'uso particolarmente pericolosi come i diagrammi di interazione. Questo non risolve il problema, ma almeno puoi vederlo.

• Quali supposizioni non sono più vere che hanno spinto il design in una particolare direzione? Potrebbe esserci un piccolo refactoring che si nasconde dietro a qualche pasticcio.

• Se spieghi come funziona il sistema (anche solo un caso d'uso) e ti trovi a dover scusarti di un sottosistema più e più volte, è il problema. Quale comportamento renderebbe il resto del sistema più semplice (indipendentemente da quanto sia difficile da implementare rispetto a ciò che è presente). Il classico sottosistema da riscrivere è quello che inquina ogni altro sottosistema con la sua semantica operativa e implementazione. "Oh, devi annaspare i valori prima di inserirli nel sottosistema froo, quindi puoi annullarli di nuovo quando ottieni l'output dal froo. Forse tutti i valori dovrebbero essere groz quando vengono letti dall'utente e dall'archivio e il resto del sistema è sbagliato? Questo diventa più eccitante quando ci sono due o più grozifications differenti.

• Trascorri una settimana come squadra rimuovendo gli avvisi in modo che i problemi reali siano visibili.

• Riformatta tutto il codice nello standard di codifica.

• Assicurati che il sistema di controllo della versione sia legato al tuo bug tracker. Ciò significa che i cambiamenti futuri sono carini e responsabili, e puoi lavorare PERCHÉ.

• Fai qualche archeologia. Trova i documenti di progettazione originali e rivedili. Potrebbero essere su quel vecchio PC nell'angolo dell'ufficio, nello spazio ufficio abbandonato o nello schedario che nessuno ha mai aperto.

• Pubblica nuovamente i documenti di progettazione su un wiki. Questo aiuta a istituzionalizzare la conoscenza.

• Scrivi procedure tipo checklist per versioni e build. Questo impedisce alle persone di pensare, così possono concentrarsi sulla risoluzione dei problemi. Automatizza le build ovunque sia possibile.

• Prova integrazione continua . Prima si ottiene una build fallita, meno tempo il progetto può spendere dai binari.

• Se la tua squadra è in testa non fa queste cose, beh, questo fa male alla compagnia.

• Cerca di garantire che tutto il nuovo codice ottenga i test unitari corretti con una copertura misurata. Quindi il problema non può peggiorare.

• Prova a testare alcuni dei vecchi bit che non sono stati testati dall'unità. Questo aiuta a ridurre la paura del cambiamento.

• Se possibile, automatizza il test di integrazione e regressione. Almeno avere una lista di controllo. I piloti sono intelligenti e ricevono un sacco pagato e usano liste di controllo. Si sbagliano anche molto raramente.

Leggi e poi rileggi Codice completo di Steve McConnell. È come una bibbia di buona scrittura del software, dal progetto iniziale fino a una singola riga di codice e tutto il resto. Quello che mi piace di più è che è supportato da decenni di dati solidi; non è solo il prossimo stile di codifica migliore.

Sono venuto a chiamare questo "Winchester Mystery House Effect". Come la casa, è iniziato abbastanza semplice, ma nel corso degli anni molti lavoratori diversi hanno aggiunto tante caratteristiche strane senza un piano generale che nessuno lo capisce più. Perché questa scala non va da nessuna parte e perché questa porta si apre solo in un modo? Chi lo sa?

Il modo per limitare questo effetto è iniziare con un buon design realizzato dove è abbastanza flessibile da gestire l'espansione. Diversi suggerimenti sono già stati offerti su questo.

Ma spesso ti imbatti in un lavoro in cui il danno è già stato fatto, ed è troppo tardi per un buon design senza eseguire una riprogettazione e riscrittura costosa e potenzialmente rischiosa. In quelle situazioni, è meglio cercare di trovare il modo di limitare il caos mentre lo si abbraccia in una certa misura. Potrebbe infastidire la tua sensibilità progettuale che tutto debba passare attraverso una "manager" enorme, brutta, singleton o il livello di accesso ai dati sia strettamente collegato all'interfaccia utente, ma imparare ad affrontarlo. Codice difensivo all'interno di quel quadro e cerca di aspettarti l'inaspettato quando appaiono i "fantasmi" dei programmatori passati.

Rifacimento codice e i test unitari stanno perfettamente bene. Ma dal momento che questo progetto a lungo termine è in esecuzione su hack, questo significa che la gestione non sta mettendo il piede in basso per pulire il marciume. Il team è tenuto a introdurre gli hack, perché qualcuno non sta assegnando risorse sufficienti per addestrare le persone e analizzare il problema / richiesta.

Il mantenimento di un progetto a lungo termine è una responsabilità tanto del project manager quanto di uno sviluppatore individuale.

Le persone non introducono gli hack perché a loro piace; sono costretti dalle circostanze.

Voglio solo inserire un problema non tecnico e un approccio (forse) pragmatico.

Se al tuo manager non interessa la qualità tecnica (codice gestibile, architettura semplice, infrastruttura affidabile e così via), diventa difficile migliorare il progetto. In questo caso è necessario educare il manager e convincere a "investire" gli sforzi nella manutenibilità e nel rivolgersi a debito tecnico .

Se sogni con la qualità del codice trovata in quei libri hai bisogno anche di un capo che si preoccupi di questo.

O se vuoi solo domare un "progetto Frankenstein" questi sono i miei consigli:

• Organizza e semplifica
• Accorcia le funzioni
• Dare priorità alla leggibilità rispetto all'efficienza (quando è accettabile, naturalmente, e alcuni guadagni di efficienza sono troppo miseri per essere conservati)

Nella mia esperienza, la programmazione è entropica piuttosto che emergente (almeno nel paradigma popolare imperativo-strutturato). Quando le persone scrivono il codice per "funzionare" la tendenza è perdere la propria organizzazione. Ora organizzare il codice richiede tempo, a volte molto di più che farlo funzionare.

Oltre all'implementazione di funzionalità e correzioni di bug, prenditi il tuo tempo per la pulizia del codice.

Sono stato sorpreso di scoprire che nessuna delle numerose risposte ha evidenziato l'ovvio: il software consiste in numerose piccole librerie indipendenti. Con molte piccole librerie, puoi costruire un software grande e complesso. Se i requisiti cambiano, non è necessario buttare via l'intera base di codice o indagare su come modificare un codebase di grandi dimensioni per fare qualcosa di diverso da ciò che sta facendo attualmente. Decidi solo quali di queste librerie sono ancora rilevanti dopo che i requisiti sono cambiati e come combinarli insieme per avere la nuova funzionalità.

Utilizza qualsiasi tecnica di programmazione in quelle librerie che faciliti l'uso della libreria. Nota che ad es. qualsiasi linguaggio non orientato agli oggetti che supporta i puntatori di funzione supporta in realtà la programmazione orientata agli oggetti (OOP). Quindi, ad es. in C, puoi fare OOP.

Puoi anche prendere in considerazione la condivisione di quelle piccole librerie indipendenti tra molti progetti (i sottomoduli git sono tuoi amici).

Inutile dire che ogni piccola libreria indipendente dovrebbe essere sottoposta a test dell'unità. Se una determinata libreria non è testata dall'unità, stai facendo qualcosa di sbagliato.

Se usi C o C ++ e non ami l'idea di avere molti piccoli file .so, puoi collegare tutte le librerie insieme in un file .so più grande, o in alternativa puoi fare il collegamento statico. Lo stesso vale per Java, basta cambiare .so in .jar.

Semplice: riduce i costi di manutenzione della maggior parte del codice fino a zero fino a quando non si ha un numero di parti mobili che può essere mantenuto. Il codice che non deve essere modificato non comporta costi di manutenzione. Consiglio di puntare a fare in modo che il codice abbia veramente zero costi di manutenzione, non cercando di ridurre il costo di molte iterazioni di refactoring piccole e pignole. Rendilo subito zero .

Ok, bisogna ammettere che è molto, molto più difficile di quanto possa sembrare. Ma non è difficile iniziare. Puoi prendere una parte della base di codice, testarla, costruire una bella interfaccia su di essa se il design dell'interfaccia è un disastro, e iniziare a far crescere le parti della base di codice che sono affidabili, stabili (come in mancanza di ragioni per cambiare), mentre contemporaneamente restringendo le parti che sono inaffidabili e instabili. Codebase che si sentono come un incubo da mantenere spesso non distinguono le parti in movimento che devono essere cambiate lontano dalle parti che non lo fanno, dal momento che tutto è considerato inaffidabile e soggetto a modifiche.

In realtà ti consiglio di separare l'organizzazione della tua base di codice in parti "stabili" e "instabili", con le parti stabili che sono un enorme PITA da ricostruire e cambiare (che è una buona cosa, dato che non dovrebbero t devono essere cambiati e ricostruiti se appartengono veramente alla sezione "stable").

Non è la dimensione di un codebase che rende difficile la gestibilità. È la dimensione del codebase che deve essere mantenuta. Dipendo da milioni di righe di codice ogni volta che, ad esempio, utilizzo l'API del sistema operativo. Ma questo non contribuisce ai costi di manutenzione del mio prodotto, dal momento che non devo mantenere il codice sorgente del sistema operativo. Io uso solo il codice e funziona. Il codice che uso e non devo mai mantenere non comporta costi di manutenzione per la mia parte.