Open Source - Primo progetto [duplicato]

Per il controllo del codice sorgente, devi solo scoprire cosa stanno utilizzando. Probabilmente sarà SVN, se devo indovinare.

Per quanto riguarda l'etichetta, ti racconterò i miei due più grandi pet peeves nei miei pochi anni di programmazione "professionale" e diversi anni di progetti di gruppo a scuola. Li elencherò come due cose, ma generalmente vanno insieme, come di solito si provoca l'altro.

1. Mancanza di comunicazione.

• Non sapere dove si trova qualcuno da parte di ciò che è stato loro dato quando arriviamo a una scadenza / milestone / ecc. Questo è ovviamente meno di un grosso problema per te quando sei lavorare su un progetto come questo invece di cercare di fissare scadenze per il tuo cliente e / o professore, ma ancora. È bello sapere dove sono tutti e come stanno facendo.
• Non far sapere a qualcuno se hai problemi con qualcosa su cui stai lavorando. Preferisco trascorrere un giorno a rispondere a 100 e-mail che chiedono informazioni sulle specifiche, su come funzioni una lingua o qualcosa del genere quello di trascorrere qualche ora cercando di rintracciare dove qualcuno era troppo timido per chiedere e ha appena provato senza dire nulla - se non sei sicuro, google. Se non sei ancora sicuro, chiedi. Se devo tornare indietro e correggere il tuo codice in un secondo momento, probabilmente sarà ancora shakey.

Considero entrambe queste forme estremamente povere, perché inevitabilmente lasciano la tua squadra fuori dal gioco.

2. Invio del codice bacato non verificato, non completato o noto al repository.

• Non penso nemmeno di doverlo spiegare. Se la mia classe si basa sulla tua classe e tu commetti modifiche non completati, e io aggiorno e ora non riesco a compilare ...

Sai cosa, sto aggiungendo un po 'di enfasi al test ..

2b. Mancanza di test approfonditi.

• Verifica il tuo codice. Prova ogni funzione Provalo per gli strani insani che nessun umano ragionevole vorrebbe mai provare. Provalo per cose che una scimmia al computer con una mazza non avrebbe nemmeno provato. Avere un piano di test per ogni funzione con criteri chiaramente definiti per il successo, e prima di impegnare il codice, assicurarsi di avere un grande PASS verde nella colonna Pass / Fail. A nessuno piace scorrere la parte del codice e andare in crash perché la tua classe non è stata testata correttamente.

Buoni punti da tutte le risposte. Aggiungerò solo ...

1. Inizia con l'invio della documentazione. Migliora la documentazione su come installare e utilizzare il software o come utilizzare le API. È incredibile quanto valore puoi aggiungere qui senza toccare il codice.
2. Aggiungi casi di test al codice esistente. Questo ti aiuterà a scoprire l'intento del codice esistente. Ti insegnerà anche a scrivere casi di test.

Fai queste 2 cose e costruirai fiducia, e poi sarai in grado di fare di più.

BTW, questo è lo stesso metodo utilizzato da IBM per iniziare a contribuire alla comunità del software libero / open-source. Hanno iniziato con la documentazione, i test e la creazione della base Apache. E ora sono una parte importante della community FOSS.