Perché alcune librerie open source mancano di commenti?

Scrivere il codice sorgente è divertente.

Scrivere documentazione e commentare il codice è meno divertente.

Quando uno sviluppatore lavora in una società che applica buoni commenti e documentazione, non c'è scelta: o questo sviluppatore scrive quelli o è a rischio di licenziamento.

Quando uno sviluppatore contribuisce a un progetto open source, lo fa gratuitamente e soprattutto per divertimento. Non c'è nessuno che costringa questo sviluppatore a fare cose che non è disposto a fare, come scrivere documentazione e commenti.

Ecco perché molti progetti open source mancano di un'ampia documentazione e commenti.

In che modo le persone possono ancora contribuire a progetti open source senza documentazione o commenti?

• Se il codice sorgente è di alta qualità, i commenti non sono necessari troppo. I commenti delle interfacce pubbliche e della documentazione sono particolarmente utili per i consumatori del progetto, cioè gli sviluppatori che semplicemente usano le librerie, non contribuiscono a loro.

• Non sono coinvolti fattori di produttività. Sto lavorando in un'azienda in cui il codice effettivo non ha test unitari, documentazione e commenti. Trascorro molto tempo a capire cosa stia facendo un metodo 600-LOC oa codificare cose già fatte, ma non rilevabili a causa della mancanza di documentazione, quindi la maggior parte delle volte, sto semplicemente sprecando i soldi della compagnia invece di fare qualcosa prezioso.

  D'altra parte, per un progetto open source, non importa se uno dei contributori ha perso una settimana a causa della mancanza di documentazione o di commenti appropriati. La cosa peggiore che può succedere è che questo contributore lascerà il progetto.

  Scoprire il codice senza commenti o documentazione può anche essere impegnativo, cioè attirare alcuni contributori, invece di scoraggiarli.

• Nei progetti aziendali, non è insolito che uno sviluppatore sia costretto a lavorare su ogni aspetto di un prodotto e, pochi anni dopo, debba conoscere quasi l'intero sistema. In un progetto open source, nessuno ti obbliga a conoscere l'intera faccenda. Puoi semplicemente contribuire a una piccola parte di esso e avere un'ottima conoscenza di questa parte, senza bisogno di documentazione.

Diversi motivi.

• Scrivere la documentazione non è divertente, e per molti progetti, la base di utenti è il gruppo di programmazione; tutti sanno di cosa tratta il codice, quindi la documentazione non è vista come un aspetto importante del progetto.
• La documentazione può (e lo sarà) diventare obsoleta e la documentazione obsoleta è peggio di nessuna. Ciò significa che la documentazione è una responsabilità extra e può avere un impatto sulla flessibilità della tua base di codice (più documentazione significa che per ogni modifica dovrai aggiornare il codice e la documentazione). Soprattutto per progetti open source molto specifici, questo è in realtà un argomento valido per puntare a una documentazione minima e scrivere invece un codice leggibile.
• L'economia del software open source è diversa. Mentre è bello avere dei contributori sul tuo progetto, molti progetti sono progetti di tipo "scratch-an-itch" che l'autore ha scritto per risolvere un particolare problema e che poi sono stati buttati allo scoperto, così com'è. Dal momento che stai praticamente mangiando briciole di qualcun altro, l'atteggiamento è che non sei nella posizione di chiedere qualcosa, per non parlare della documentazione.

How can people collaborate to these opensource with very few comments

Supponevo che intendessi "Come può la gente collaborare a questo codice opensource che è difficile da leggere"? Beh, suppongo che un progetto open source con codice errato abbia semplicemente meno contributori di quello che avrebbe potuto avere con un buon codice. Ma non dimenticare che la leggibilità del codice si trova sempre negli occhi di chi guarda, e la maggior parte del codice open source non è così male che non puoi capire almeno un po 'o le intenzioni di alcune funzioni e classi.

Spesso, quando si vuole contribuire con qualcosa a un progetto open source, non è necessario comprendere l'intera faccenda, ma solo le parti in cui si desidera aggiungere una funzione specifica. Quindi se uno sviluppatore ha bisogno di una caratteristica mancante, probabilmente morde il proiettile, identifica le parti che deve cambiare, "decodifica" quelle parti mentalmente e aggiunge le nuove funzionalità lì. Se è bravo, cercherà anche di rivedere e refactoring le parti "decodificate", ma immagino che in pratica ciò accada troppo raramente.