Come possono avere successo i progetti open source senza documentazione sulla loro progettazione o architettura?

Voglio migliorare le mie capacità di programmazione studiando famosi progetti open source, ma trovo che sia facile perdersi semplicemente saltando nel loro codice sorgente.

Così ho deciso di leggere la loro documentazione sulla loro progettazione o architettura (come i diagrammi UML) per avere prima un'idea generale sull'organizzazione del loro codice. Con mia sorpresa, tuttavia, non riesco a trovare alcuna documentazione architettonica per grandi progetti open source come Hibernate, Spring, ASP.NET MVC, Rails, ecc.

Quindi ho iniziato a chiedermi: come può un progetto open source avere successo se gli sviluppatori di nuovi arrivati ​​non hanno documentazione architetturale / di progettazione da leggere o se il project manager ha appena aperto il codice sorgente ma ne ha chiuso la documentazione?

perché un progetto open source può avere successo se uno sviluppatore nuovo arrivato non ha documenti di architettura / design da leggere?

Si presuppone invariabilmente che tu sappia cosa stai facendo e abbia una comprensione ragionevolmente intima di ciò che stai (e ti aspetti) di vedere.

Se osservi il codice PHP del framework Symfony, ad esempio, dovresti già sapere dell'iniezione di dipendenza, degli eventi, del modello / vista / modello del controller e così via.

Allo stesso modo, se ti immergi nel codice C del kernel Linux, il presupposto è che sarai realisticamente competente in modularità, segnali, processi, thread e cosa no. Dovresti anche avere un talento per mangiare esadecimale tutto il giorno e scavare attraverso le discariche centrali con una pala gigante.

I manutentori non dovranno affrontare il problema di documentare l'architettura perché è roba di fatto. A volte, troverai uno schema di ciò che si trova nella struttura ad albero sorgente. Più in genere, tuttavia, il modo in cui è organizzato l'albero dei sorgenti rende le cose autoesplicative.

In breve, se ti manca qualcuna delle competenze che i manutentori si aspettano che tu sappia nel momento in cui dai un'occhiata al loro codice, probabilmente stai scavando in cose che sono ampiamente al di sopra del tuo grado di remunerazione. Familiarizzare con i concetti prima di tutto - Cos'è il modello MVC? Che cos'è l'iniezione di dipendenza? Ecc. Quindi immergersi.

La maggior parte dei progetti open source di successo ha avuto successo perché innanzitutto il programma era impressionante o faceva qualcosa che nessun altro programma poteva fare in quel momento. Ciò non significa necessariamente che la fonte sia ben documentata, poiché 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 per esprimere interesse in esso.

Poiché gli sviluppatori open source di solito hanno talento e scelgono anche progetti nella loro area di competenza, hanno già "documentazione" nei loro teschi. Con poca esagerazione è necessaria un'attenta documentazione solo se manca qualcuno di questi: o)

Ad essere sincero, non leggo davvero la "documentazione" di fronte a una base di codice sconosciuta. Una breve introduzione, forse alcuni schizzi concettuali e direttamente nel codice! Sperimenta, prova piccoli cambiamenti. Funziona perfettamente per un codice ben progettato. Se mi trovo ad affrontare un disastro orribile, il modo migliore per impararli è di refactoring poco a poco per migliorare la chiarezza (idealmente con l'aiuto del test unitario).

Ulteriori motivi potrebbero essere le semplici radici organiche di questi progetti. L'architettura è quindi una visione piuttosto evoluta nella mente degli sviluppatori piuttosto che un'entità "documentata" dichiarata.

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

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