In che modo i progetti open source mantengono la qualità? Che cosa impedisce ai progetti di persone con una scarsa esperienza di programmazione di verificare i codici di scarsa qualità?
What keeps the projects from people with relatively little programming experience checking in poor quality codes?
Di solito, non tutti hanno il diritto di cambiare il codice sorgente. Molto spesso c'è solo un piccolo gruppo di sviluppatori fidati che hanno il diritto di modificare il codice sorgente. Se qualcun altro desidera apportare modifiche, può inviare patch, ma queste vengono controllate e aggiunte dagli sviluppatori con commit access .
Alcuni progetti consentono ad altri sviluppatori di unirsi al gruppo fidato, se inviano diverse patch di qualità sufficiente.
In che modo i progetti a codice chiuso mantengono la qualità? Che cosa impedisce ai progetti di persone con una scarsa esperienza di programmazione di verificare i codici di scarsa qualità?
Allo stesso modo:
Ma veramente la risposta è: la maggior parte no. In entrambi i casi, fonte aperta e chiusa. Dopotutto, la programmazione è soggetta al Principio di Pareto e alla Rivelazione di Storione ("Il novanta per cento di tutto è grezzo") proprio come tutto il resto.
In Linux, ad esempio, in quasi il 100% di tutti i casi in cui un'azienda rilascia un driver sorgente precedentemente chiuso come open source, quel driver ha bisogno di una quantità considerevole di lavoro prima di poter essere unito a l'albero del kernel, semplicemente perché la sua qualità è così cattiva. In alcuni casi, è così cattivo che il codice è fondamentalmente invalicabile e deve essere riscritto da zero.
Quindi, in Linux, il modo in cui viene mantenuta la qualità è che i contributi di bassa qualità vengono rifiutati, ma esiste un processo di mentoring che aiuta le persone a scrivere un codice di qualità migliore.
Dipende molto dalle dimensioni della base di sviluppatori e da quale back yard ti capita di giocare.
Il modo in cui uno di questi è determinato dipende in gran parte dalle abilità degli sviluppatori fondatori.
In primo luogo, rendersi conto che scrivere codice e spingerlo in libertà per il mondo intero alla critica e alla revisione richiede un tipo speciale di persona. Quella persona potrebbe non essere molto fiduciosa nelle sue capacità, ma sono comunque disposte a pubblicare il loro codice. Qualcun altro potrebbe essere estremamente fiducioso. Entrambe le persone hanno gli stessi obiettivi:
Potrebbero esserci motivi finanziari sottostanti, ma quanto sopra tende ad essere vero.
Potrebbero esserci altre motivazioni nel mix. Conosco persone che trascorrono un'enorme quantità di tempo a riscrivere applicazioni proprietarie con una licenza approvata OSI (di solito la clausola 3 BSD o GPL). Conosco altre persone che non sopportano le librerie GPL2 + e lavorano per riscriverle per poterle rilasciare con una licenza meno restrittiva.
In ogni caso, ci sono molte persone che scrivono e pubblicano il codice per vari motivi.
Nella mia esperienza, il codice (veramente) errato viene commesso per i seguenti motivi:
Consente di suddividerli un po ':
Sul primo punto, l'autore originale probabilmente sperava di imparare qualcosa nel processo di rilascio del proprio lavoro. Non è in alcun modo cattivo, ma se hai una piccola comunità di sviluppo può diventare tossico. Pensaci, hai una pelle abbastanza spessa per liberare la tua roba, ottieni una patch che ti fa esplodere la mente, la tua pelle ora è abbastanza spessa da ammettere che non hai idea di cosa sia effettivamente la patch? Questo succede un bel po '. Se hai più occhi a guardare le cose, aiuta. Quindi diciamo che la prima radice delle modifiche tossiche è ego .
Inoltre, potresti semplicemente stancarti di combattere un altro grande contributore su un singolo punto e di dire semplicemente "fanculo", anche se comprendi le patch.
Sul secondo punto, le cose scritte per riempire un vuoto idealistico (almeno all'inizio) sono di qualità inferiore rispetto a qualcosa scritto per riempire un vuoto tecnico, almeno nella mia esperienza. Per la maggior parte, il progetto GNU è un'eccezione a questa regola, hanno prodotto software che funziona in modo prevedibile e coerente su una varietà di architetture per anni.
Non vedrai un sacco di revengeware in natura, non dura molto a lungo. Ho fatto parte di progetti che sono stati avviati esplicitamente a stick it to the man e li ho abbandonati rapidamente. Questo ci porta alla seconda fonte di modifiche tossiche, nessun vero focus .
Infine, arrivi al punto che un progetto è davvero decollato. L'autore originale non è solo abbastanza esperto, ma si fida delle proprie capacità abbastanza per scongiurare le patch tossiche. Il progetto cresce, cresce la base di codice e sempre più fidati luogotenenti vengono aiutati a gestire i contributi. L'autore originale ha l'ultima parola, se lo vuole, ma si fida della cerchia ristretta per curare efficacemente le parti che mantengono.
Le persone fanno cose strane. Non riesco a contare il numero di esaurimenti nervosi che ho visto su mailing list pubbliche con entrambe le mani. Le persone si bruciano, sviluppano problemi di alcol, a volte problemi di droga o spariscono tutti. I loro coniugi li lasciano, le loro case bruciano, le feci si verificano. Tuttavia, a questo punto, dovresti avere abbastanza occhi critici su cose da catturare.
Questo ci porta alla terza ragione (almeno nella mia esperienza) per cui il codice tossico viene messo in circolazione - una mancanza di supervisione della comunità . Ciò si verifica soprattutto nei progetti in cui gli utenti superano di gran lunga i contributori effettivi di 100: 1 o più. Hai un sacco di palle per gli occhi, ma nessuno di loro sa cosa stanno guardando.
Non elencato, ma alla fine lo sviluppatore originale potrebbe essersi bruciato anni fa. Quando / se ciò accade, un progetto perde passione.
Oltre a ciò, accadono altre cose. Le aziende vengono comprate (ne vediamo le conseguenze ora con OpenOffice / OpenSolaris).
I progetti open source ben eseguiti utilizzano gli stessi set di strumenti e modelli di comportamento che fanno i buoni progetti a codice chiuso. La differenza è che nel modello open source puoi avere molti più occhi sul design e sul codice.
Quindi per i due progetti open source con cui sono pesantemente coinvolto, noi:
Vedi link per una guida su come eseguire un progetto open source di successo
Alcuni non lo fanno.
Quelli che lavorano hanno una singola persona (o un gruppo molto grande con responsabilità ben definite) che controllano tutto e lasciano solo ciò che soddisfa i loro standard nella base di codice ufficiale. (Filiali private = problemi privati).
Se hai un'applicazione con più di uno (esperto) sviluppatore, il codice errato non entrerà nel ramo principale, dal momento che non avrai accesso in scrittura se non dimostrerai di rispettare i loro standard.
La maggior parte dei progetti dispone di sistemi di controllo della versione, in cui lo sviluppo del codice va alle filiali. Le nuove funzionalità sono accettate per rami instabili o anche in modalità branch-per-feature o branch-per-fix. Quando viene testato un nuovo ramo ed è chiaro che il codice è di buona qualità, può essere unificato nel ramo principale, o nel ramo beta-testing, da dove, dopo le correzioni se necessario, va in o diventa esso stesso il ramo di produzione.
Ulteriori informazioni su Mercurial link e su Git link sistemi di controllo della versione.
Leggi altre domande sui tag open-source