Il controllo della versione dovrebbe contenere il codice e la configurazione necessari per creare l'applicazione.
Questo significa che:
-
Cose temporanee introdotte per un breve periodo di tempo (il tempo necessario per individuare la posizione di un bug o per sperimentare una funzionalità di una lingua, ad esempio) non dovrebbero essere in un controllo di versione : mantienilo finché non ne hai bisogno, quindi rimuovilo semplicemente quando esegui il commit .
-
I file locali che sono appropriati per una macchina particolare possono essere tenuti in un ramo.
Eviterei di tenerli solo localmente, dato che è troppo doloroso rifare tutto questo quando il tuo laptop viene rubato o un virus ti costringe a reinstallare il sistema operativo (e, a proposito, scopri che il tuo ultimo backup è stato fatto due anni fa).
D'altro canto, fai attenzione con la struttura dei file: la configurazione locale è OK, finché non diventa schiacciante e ti costringe a fare una singola modifica in ogni file di ciascuno dei 42 sviluppatori che partecipano al progetto.
Guarda l'opportunità di rimuovere le particolarità tra le macchine. Può significare:
-
Concedere l'accesso a un server SQL dev per sostituire le istanze locali sui computer degli sviluppatori,
-
Uso dei servizi di distribuzione dei pacchetti come Pypi o npm per i pacchetti pubblici e le loro controparti private per i pacchetti in-house,
-
Chiedi ai membri del team di installare le stesse versioni del software,
-
Rendi gli aggiornamenti software il più trasparenti possibile,
-
O consente di distribuire il sistema operativo e il software necessario su una macchina in un clic (più il tempo per ogni sviluppatore di installare il suo preferito Vim vs. Emacs, Chrome vs Firefox, ecc.)
Project files. Paths may need to be edited in order to reflect the layout on the current PC.
Perché non utilizzare lo stesso layout su ogni PC? I percorsi all'interno del progetto dovrebbero essere relativi al file di progetto, il che significa che non importa dove si trova il progetto. Le versioni di software e librerie sono le migliori per evitare errori criptici che appaiono solo su alcune macchine, e sono impossibili da riprodurre per gli altri membri del team.
Esempio:
In un progetto creato con Visual Studio, potresti trovare:
-
I file stessi. I percorsi sono relativi, non importa se sulla mia macchina, il progetto si trova in H:\Development\Hello World Project\ mentre altri membri del team hanno controllato il progetto in C:\Work\HelloWorld\ .
-
Le dipendenze, cioè le librerie di terze parti e interne. Entrambi i tipi devono essere gestiti da NuGet, il che rende obsolete tutte le discussioni relative ai conflitti. Se non hai la stessa versione della libreria che ho, chiedi a NuGet di aggiornare le dipendenze. Semplice come quello (quando funziona bene, che non è sempre il caso).
Si noti che è fondamentale mantenere le librerie interne anche in un NuGet privato. Avere un gruppo di librerie memorizzate in una cartella condivisa o inviato via e-mail attraverso un team porta a anarchy e depressivi server CI.
-
Le impostazioni. È fondamentale che il team condivida le stesse impostazioni. Se metà della squadra decide di trattare gli avvertimenti come errori e metà della squadra mantiene gli avvertimenti così come sono, i membri della prima parte del team passeranno il loro tempo a rimuovere gli avvertimenti generati dagli sviluppatori dalla seconda parte del team.
-
Le impostazioni relative alle utilità. Sono complicati, perché alcuni membri del team potrebbero aver installato alcune utilità, mentre altri non lo hanno fatto.
Si consiglia vivamente di installare lo stesso set di strumenti. Se alcuni programmatori vogliono usare StyleCop, ma altri no, il team non riuscirà a completare il lavoro. Se alcuni usano i contratti di codice ma altri no, avranno gli stessi problemi.
Makefiles. For example optimization may need to be turned off during debugging, but not for the CI server.
Mantieni più makefile nel controllo della versione. Non è raro creare una versione di debug sul server CI e inviarla a un client che presenta un bug insidioso.
Dirty ugly hacks. For example return 7 in the middle of a function, in order to test something, depending on the function, and suspected to break at value of 7.
Vorrei evitare tale codice in primo luogo. Per testare qualcosa, usa i test unitari. Se occorrono alcuni secondi per scambiare qualche codice allo scopo di debug , allora fallo, ma rimuovi questo codice in pochi minuti lo stesso, quindi non è necessario eseguirlo.
Come lo descrivi, dovresti scrivere un test. Ad esempio, se vuoi essere sicuro che:
class TemperatureConverter
{
public int CelsiusToFahrenheit(int temperature)
{
...
}
}
genera un'eccezione quando temperature è inferiore alla costante AbsoluteZero , non dovresti giocare con il codice stesso . Invece, crea un test unitario che:
- autocodifica il tuo codice,
- aumentare l'affidabilità del tuo codice,
- assicurati che i manutentori possano fare affidamento sui test di regressione quando modificano il metodo sopra,
- servire ad altri sviluppatori del tuo team che potrebbero dover eseguire lo stesso test.