Ci si aspetta che le codebase grandi o vecchie siano facili da navigare?

Le grandi basi di codice non sono progettate, si evolvono. Un sacco di cose che non hanno senso quando si guarda a un'istantanea attuale, hanno perfettamente senso quando si tiene conto della storia. E non intendo solo la storia individuale della base di codice, intendo anche la storia delle pratiche di ingegneria del software in generale.

Il testing delle unità praticamente è sempre esistito fino ad un certo punto, ma non è mai entrato in uso diffuso fino a quando non sono stati "inventati" la programmazione estrema e lo sviluppo guidato dai test negli anni dal 1999 al 2003. Un sacco di basi di codice sono precedenti a questo, e di conseguenza non sono stati progettati in modo da rendere facile il test dell'unità.

C'è una storia simile dietro altre pratiche di ingegneria del software. Ad esempio, la rivoluzione DVCS del 2005 ha cambiato il modo in cui le persone pensano ai flussi di lavoro e ai modelli ramificati, anche con il controllo della versione non distribuito. Per un altro esempio, anche se esisteva, quasi nessuno aveva sentito parlare del pattern di progettazione MVC fino a quando Microsoft non creò un framework con quel nome, e ora il fallimento nel separare il modello e la vista è molto più scoraggiato di quanto non fosse, anche nei progetti che non usano la struttura di Microsoft.

La creazione e la divulgazione di strumenti di revisione tra pari online hanno essenzialmente interrotto la pratica di una revisione tra pari in un incontro formale, rendendoli molto più facili da eseguire e quindi più ubiquitari. La divulgazione dei linguaggi di raccolta dei rifiuti ha spinto le innovazioni di gestione della memoria in C ++ come puntatori intelligenti e RAII, che ora sono considerati pratica standard, ma non erano noti quando sono state avviate molte basi di codice correnti. Potrei andare avanti ancora.

Man mano che le aziende crescono, cercano di sfruttare il più possibile il riutilizzo del codice, quindi un'architettura di codice ideale per un prodotto potrebbe essere inserita in un altro progetto con poche modifiche, anche se l'architettura potrebbe risultare un po 'scomoda il nuovo contesto. Quando questo accade più volte su forse decenni, il quadro generale non ha più senso.

Non è che le aziende non vogliano cambiare con i tempi, ma le basi di codice sono come i transatlantici. Impiegano molto tempo e stanno pianificando attentamente di girarsi. Pertanto, è altamente improbabile che tu possa mai trovare una base di codice di grandi dimensioni che non sarebbe ridisegnata in un modo diverso se si inizia da zero oggi. La cosa importante da cercare è se un'azienda sta cercando di girare nella giusta direzione.

Certamente c'è un limite alla complessità che la mente umana può comprendere. Non puoi aspettarti che qualcuno conosca milioni di righe di codice. Ecco perché dovresti strutturarlo e documentarlo in modo ragionevole e comprensibile. Di solito, le possibilità di strutturare il codice sono lasciate fuori. Non troverai una classe di database nel pacchetto per un'interfaccia utente grafica. Ma potresti trovare una classe di database che fa qualcosa di molto diverso (ad es. Reporting). Le classi e i moduli tendono a crescere quasi organicamente. È preferibile organizzare il codice in classi più piccole ma con responsabilità singole, per rendere il codice più facile da capire. Il codice di facile comprensione è fondamentale per raggiungere gli obiettivi dell'ingegneria del software, ad es. software corretto, robusto, riutilizzabile ed estensibile.

Non troverai nessuno sviluppatore che voglia scrivere molto codice. L'idea è di scrivere solo tanto e averlo scritto in modo estensibile.

Sfortunatamente, gli sviluppatori devono raccogliere i requisiti di business / vendite / marketing e solitamente non sono mai specifici. Quindi hai casi d'uso che devono essere rattoppati in un codice che non è mai stato concepito per fare quello che sta facendo in primo luogo.

Non c'è modo di modificare questa situazione, a meno che tu non abbia un modo con le menti umane. Ciò che può farti risparmiare è una documentazione obbligatoria, una solida unità e un framework di test di integrazione, un sistema di tracciamento dei bug, una mailing list degli sviluppatori all'interno dell'azienda che può archiviare mail, peer review e apprendere tecniche di programmazione generica.

Inoltre, considera di utilizzare il più possibile da componenti open source poiché generalmente hanno una buona base di utenti e livelli moderati di documentazione. Ancora più importante, devi chiedere alle persone se il tuo lead tecnologico è in vacanza.

Anche i libri di progettazione di software su larga scala sono una gradita aggiunta.

Quando si affronta un'applicazione in campo scuro, il primo passo ideale è quello di scrivere test di unità per esso.

Questo porta a termine diverse cose:

1. Ti costringe a elaborare il codice e a comprenderlo
2. I test unitari servono come documentazione e codice di esempio per la funzionalità esistente e
3. I test unitari forniscono una rete di sicurezza per il refactoring.

Che l'organizzazione abbia o meno voglia di permetterti di farlo è un'altra questione. Hanno vissuto senza test unitari per così tanto tempo; far sì che siano d'accordo a ridurre il debito tecnico in questo modo sarà difficile.