In che modo le persone riescono a scrivere e mantenere un codice estremamente complesso e difficile da leggere? [chiuso]

La lettura del codice sorgente di SQLite è impossibile per la missione IMO. Eppure è un pezzo utilizzabile di software abbastanza complesso (dopo tutto è un database incorporato completo) che può essere scaricato, compilato e utilizzato da altri codici e viene costantemente aggiornato.

In che modo le persone riescono a scrivere e mantenere un codice estremamente complesso e difficile da leggere?

C'è una grande differenza tra Complesso e Complicato. Il seguente link su lo riassume. :)

http://codebetter.com/blogs/dru.sellers/archive/2009/09/25/complex-vs-complicated.aspx

Su una nota più personale, lavoro su una base di codice di oltre 1 milione di righe di codice. Ci sono stato dalla linea 1 al suo stato attuale. Più Farmilar sei (leggi più a lungo sei nel codice), più diventa facile. Non posso dirti cosa fa ogni linea, ma posso dire che dovresti iniziare a cercare un determinato compito o bug. Viene naturale.

La morale della storia è che come qualsiasi cosa nel mondo della programmazione ci vuole tempo. Se ti aspetti di guardare SQLite e di conoscerlo e capirlo, ti stai prendendo in giro. Ci vorrà del tempo per capire come tutto funziona insieme. La differenza tra buon codice e cattivo codice è quanto tempo impiega quel processo.

Infine, alcuni sviluppatori non hanno la possibilità di saltare in una base di codice e iniziare a capirlo. Molti si sentiranno sopraffatti dalle dimensioni o dall'architettura della base di codice. Altri non avranno problemi a saltarci dentro. Tutto dipende dai punti di forza degli sviluppatori.

Nel caso specifico di SQLite, lo strumento principale che hanno scelto di utilizzare nello sviluppo e nella manutenzione è il test automatizzato. Sono orgogliosi della copertura del 100% (copertura delle filiali, non copertura delle dichiarazioni) nella loro suite di test. Secondo loro, è uno dei prodotti software più testati al mondo. Quindi sanno subito quando qualcosa che hanno aggiunto o modificato provoca una regressione e, di conseguenza, possono svilupparsi senza paura.

http://sqlite.org/testing.html

Numeri piuttosto sbalorditivi: hanno circa 640 volte il numero di righe di codice di test rispetto al codice di produzione.

EDIT: Questa domanda è stata sollevata dai morti, a quanto pare! E poco più di un anno dopo, quella stessa pagina riporta che ha 1177 volte il numero di righe di codice di test della produzione!

• le funzionalità si evolvono nel tempo.
  • le nuove funzionalità sono guidate dalle nuove esigenze dei clienti.
  • Il vecchio codice è stato scritto in un modo che consente di aggiungere funzionalità future ancora da implementare senza rompere il vecchio codice.
• esperti di dominio (in questo caso, il database è un dominio ben noto in Informatica).
• feedback della comunità
  • bug
• la ripida curva di apprendimento non è stata un problema per i ben preparati e perseveranti. Potrebbero essere necessari 6 mesi, 1 anno o anche più per sentirsi a proprio agio, ed è ciò che alcune persone sono in grado di sopportare.
• motivazioni commerciali. senza supporto monetario, pochissime persone possono investire il tempo e l'energia nella ripida curva di apprendimento.

Non è necessario avere una comprensione intima dell'intero progetto per poterlo mantenere. Di solito con software complessi e di grandi dimensioni, le persone avranno le proprie "aree" particolari di cui si occupano e hanno solo una conoscenza "passante" del resto del sistema.

SQLite è in realtà relativamente piccolo sulla scala dei "grandi progetti software" ma se guardi qualcosa come il sistema operativo Windows, avrai persone che lavorano solo sul kernel, persone che lavorano solo sulla shell, persone che lavorano e basta su Internet Explorer, le persone che lavorano solo su Window Manager, ecc. ecc. Qualcuno che lavora nella "shell" non sarà in grado di correggere un bug nel kernel con un semplice clic.

C'è anche il vantaggio che questi progetti evolvono nel tempo: non sono sempre partiti così complicati. Ciò significa che un nuovo sviluppatore di solito può essere "addestrato" da sviluppatori più esperti.

Quando ti unisci a un grande team di sviluppatori, ti verrà dato un aspetto particolare del progetto su cui lavorare (forse un bug o una nuova funzionalità) e avrai un altro sviluppatore che sarà il tuo "amico" per le prime iterazioni. Il tuo amico avrà una buona conoscenza dell'area in cui stai lavorando e può aiutarti a orientarti.

Per progetti open source come SQLite, in realtà è un po 'più difficile perché non c'è motivazione per gli sviluppatori esistenti a "formare" nuovi sviluppatori. Quindi scoprirai di essere da solo un po 'di più. Ma puoi ancora trovare aiuto sui forum degli sviluppatori o sulle mailing list (ad esempio, solo pubblicando una domanda come "Mi piacerebbe implementare tale e tale funzionalità" o "Ho trovato il bug XYZ, da dove comincio a cercare?" E probabilmente otterrai qualche forma di aiuto.

C'è una differenza tra progetti difficili da leggere e complessi. Se una persona non comprende a fondo la lingua in cui è stato scritto il progetto o il dominio del progetto, ciò non significa che il codice sia scritto male.

Il mio consiglio:

• Assicurati di aver capito la lingua del progetto. Non basta conoscere la lingua.
• Scopri tutti i dettagli sul dominio prima di mettere le mani sul codice.

Per me SQLite è molto complesso e nulla di complicato. Il dominio di questo progetto richiede una profonda conoscenza di concetti ampi.

Una cosa non menzionata nelle altre risposte è "Viene naturale per loro". Molte persone vogliono scrivere un buon codice ma sono sintonizzati per scrivere un codice cattivo. Alcuni dei programmatori che ho incontrato sono naturalmente pensatori LINEARI + alcune volte molto volutamente escogitano soluzioni complesse. Molte di queste persone non passano il tempo a leggere o imparare dal libro che imparano come e quando il lavoro lo richiede.

In che modo le persone riescono a scrivere e mantenere un codice estremamente complesso e difficile da leggere?

Se sono i programmatori originali e continuano a mantenerlo, non lo vedono come "complesso e difficile da leggere". Probabilmente lo vedono come "semplice e facile da leggere", poiché lo hanno scritto da soli.

Qualsiasi codice richiede tempo per capirlo. È solo che alcuni richiedono più tempo di altri :)

Puoi avvolgere la testa attorno a qualsiasi base di codice se lo hai - perseveranza, pazienza e un approccio metodico - ma principalmente perseveranza :-)

La gestione diventa molto più semplice se le cose vengono fatte sempre allo stesso modo. Non conosco il codice SQLite, ma sto lavorando in un ambiente in cui ci sono più progetti. Oltre a comprendere il business case (eq logic), dato che praticamente tutto viene fatto allo stesso modo ovunque (accesso al database, ecc.) È relativamente facile iniziare a lavorare su un altro progetto. Testo breve: le linee guida per la codifica - in modo appropriato - rendono la vita e tale codice molto più facili. Questo potrebbe essere uno degli aiutanti per i programmatori SQLite.

• Se sei l'autore originale del software e hai lavorato con esso per> 10 anni e sei un genio, allora potrebbe essere possibile capire tutto. Grandi pezzi di software complessi (come SQLite o il kernel Linux) di solito hanno esattamente un autore originale che ne ha una conoscenza completa e profonda, anche se altre persone hanno contribuito.
• Se l'architettura del software è sana (elevata coesione, basso accoppiamento), comprendere il tutto non è un prerequisito per apportare utili aggiunte e modifiche.
• Comprendere un RDBMS o un sistema operativo è casi alquanto speciali, che richiedono una profonda comprensione dei principi CS sottostanti. Non così con le applicazioni software "ordinarie".

Provano a scriverlo in modo semplice ma non in modo semplicistico.

Andare il più semplice possibile rende le cose più veloci da capire / leggere, anche se può richiedere del tempo.

L'algoritmo in fase di implementazione stabilisce un limite inferiore per quanto semplice può essere il codice per un'implementazione. Se una descrizione astratta dell'algoritmo da implementare è estremamente complicata e richiede che tonnellate di diversi pezzi di dati siano accoppiati tra loro, il codice che implementa tale algoritmo non può essere semplice, non importa chi lo stia scrivendo.

In altre parole, uno dei motivi per cui a volte scrivo codice imperscrutabile è perché, dato l'algoritmo che voglio implementare, non ho scelta.