Come possono i progetti open source avere successo senza documentazione sul loro design o architettura?

why an open source project can become successful if new-comer developer have no architectural/design document to read?

L'ipotesi è invariabilmente fatta di sapere cosa stai facendo e di avere una comprensione ragionevolmente intima di ciò che stai andando (e in attesa) di vedere.

Se si esamina il codice PHP del framework Symfony, ad esempio, si è già in grado di conoscere l'iniezione della dipendenza, gli eventi, il modello / modello di visualizzazione / controller e così via.

Allo stesso modo, se ti immergi nel codice C del kernel linux, l'ipotesi è che sarai realisticamente competente in modularità, segnali, processi, thread e cosa no. Ci si aspetta anche che tu abbia un talento per mangiare esadecimale tutto il giorno e scavare nelle discariche principali con una pala gigante.

I manutentori non passeranno la briga di documentare l'architettura perché è roba pragmatica. Occasionalmente, troverai una descrizione di ciò che si trova nell'albero della fonte. Più in generale però, il modo in cui è organizzato l'albero dei sorgenti rende le cose auto-esplicative.

In breve, se non possiedi le competenze che i manutentori ti aspetteranno, saprai prima di sbirciare nel loro codice, probabilmente stai scavando attraverso cose che sono ampiamente superiori al tuo grado di paga. Familiarizza prima con i concetti: qual è il modello MVC? Cos'è l'iniezione di dipendenza? Ecc. Quindi immergersi.

I progetti open source di maggior successo hanno avuto successo perché, in primo luogo, il programma è stato impressionante o ha fatto qualcosa che nessun altro programma poteva fare al momento. Ciò non significa necessariamente che la fonte sia ben documentata, dal momento che i programmatori che hanno iniziato il progetto iniziano a conoscere il codice abbastanza bene da non averne bisogno. È una sfortunata realtà che i progetti open source non debbano essere ben documentati. O deve essere un buon programma o essere un programma mediocre ma ben documentato per i programmatori di esprimere interesse in esso.

Poiché gli sviluppatori open source hanno solitamente talento e scelgono anche il progetto nella loro area di competenza, hanno già "documentazione" all'interno del loro cranio. Con poca esagerazione è necessaria una documentazione approfondita solo se non ne hai nessuna: o)

Per essere onesti, non leggo realmente la "documentazione" di fronte a codebase sconosciuti. Una breve introduzione, forse alcuni schizzi concettuali e direttamente nel codice! Sperimenta, prova piccole modifiche. Funziona perfettamente per un codice ben progettato. Se affronto un pasticcio orribile, allora il modo migliore per impararli è rifattorizzare a poco a poco per migliorare la chiarezza (idealmente con l'aiuto del test unitario).

Un motivo in più potrebbe essere la radice del design organico di questi progetti. L'architettura è quindi una visione piuttosto evoluta nelle menti degli sviluppatori rispetto a un'entità "documentata".

La ragione per cui tali documenti spesso non esistono è piuttosto semplice: ai programmatori piace programmare, non scrivere documentazione. Soprattutto con progetti open source, che gli sviluppatori contribuiscono spesso durante il loro tempo libero / libero.

Fondamentalmente, scrivere documentazione non è divertente. E se non vengono pagati per questo, chi vuole passare il tempo libero a fare qualcosa che non è divertente?