Come applicare buone / migliori pratiche di controllo del codice sorgente?

Ho il sospetto che mi sto concentrando sul problema sbagliato, quindi descriverò prima cosa penso sia il problema prima di presentare la soluzione forse non ottimale che immagino.

Situazione attuale:
Attualmente i miei colleghi commettono le loro modifiche al codice solo dopo lunghi periodi di tempo in enormi blocchi con modifiche che si diffondono in tutto il progetto. È un progresso, immagino, perché non molto tempo fa hanno messo archivi .zip su alcune condivisioni di rete. Tuttavia, la fusione è un incubo - e francamente ne ho avuto abbastanza. E sono anche stanco di parlare, spiegare e chiedere l'elemosina. Questo deve solo finire - senza che io sia costantemente "il cattivo".

La mia soluzione:
dal momento che sembra non esserci consapevolezza e / o nessun interesse per i problemi e non posso aspettarmi che gli sforzi durino più di qualche giorno ... Colpisco che, ore, vorrei che il server Subversion facesse il fastidioso.

La mia domanda:
sono fuori base o sto guardando il problema sbagliato? Sembra che mi manchi qualcosa e penso che sto chiedendo la cosa sbagliata guardando gli strumenti per risolvere il mio problema.

Dovrei cercare uno strumento per risolvere questo problema o cosa devo fare per risolvere questo problema?

Stai cercando una soluzione tecnica a un problema umano. Funziona raramente.

Il motivo è che se i membri del team non accettano qualcosa (né comprendono le implicazioni), invece di seguire le regole, tenteranno di aggirarli. Questo è esattamente il motivo, ad esempio, per cui gli sviluppatori dovrebbero accettare e comprendere le regole di stile invece di essere costretti a rispettare un controllore.

Qui ci sono alcuni approcci che ho usato in passato o che ho in mente senza averne avuto l'opportunità nella pratica. Alcuni potrebbero non essere applicabili al tuo caso, a seconda della posizione che hai in una squadra (se sei un leader di squadra con eccellente reputazione, è probabile che avrai una migliore opportunità di far valere la tua opinione rispetto a se sei un laureato che appena entrato in una squadra per la durata del tuo tirocinio).

1. Discuti il ​​problema con i tuoi colleghi e spiega le conseguenze di grandi impegni. Forse semplicemente non capiscono che complicate fusioni sono una conseguenza diretta di commit rari e che piccoli e frequenti commit renderanno le fusioni (relativamente) facili.

   Conoscevo molti programmatori che erano semplicemente convinti che le fusioni fossero sempre complicate. Hanno eseguito al massimo un commit al giorno, hanno evitato di utilizzare strumenti potenti come la differenza e l'unione automatica di Visual Studio e avevano una scarsa pratica di fusione manuale (a meno che "Prendere il mio" senza ulteriori ispezioni diff sia in realtà una buona pratica). Per loro, questo non aveva nulla a che fare con loro , ed era la natura intrinseca di una fusione.

2. Fornisci esempi concreti di ciò che sta accadendo in altre aziende (in particolare quelle per cui i tuoi colleghi hanno un profondo rispetto). Potrebbero semplicemente non essere consapevoli del fatto che si tratta di un problema ed essere convinti che un massimo di un commit al giorno è ciò che ogni squadra fa.

   Alcune persone non sono consapevoli del fatto che ci sono team di 5-10 membri che effettuano fino a 50 spinte alla produzione, il che si traduce in una media di 5-10 impegni al giorno per persona. Potrebbero non capire né come è possibile, né perché qualcuno dovrebbe farlo.

3. Dare l'esempio. Fai abbastanza piccoli impegni. Se possibile, fai una breve presentazione che mostri loro e le tue fusioni fianco a fianco per una settimana (non sono sicuro che estrarre questo tipo di informazioni sia facile da un controllo di versione). Sottolinea gli eventuali errori che hanno commesso durante le loro fusioni e confrontali con il numero di errori che hai commesso (che dovrebbe essere vicino allo zero).

4. Utilizzare la tecnica "Te l'ho detto", quando appropriato . Quando vedi i tuoi colleghi soffrire per una dolorosa fusione, commenta a gran voce che piccoli e frequenti impegni potrebbero rendere le fusioni (relativamente) indolori.

5. Spiega che non esiste una durata minima per effettuare un commit. Un commit può anche corrispondere a una piccola modifica apportata in pochi secondi. Rinominare un file, rimuovere un commento obsoleto, correggere un refuso sono tutti compiti che possono essere impegnati immediatamente.

   I programmatori non dovrebbero temere di fare un piccolo commit, ma piuttosto di aggregare molti cambiamenti in un unico commit.

6. Lavora con le persone invece che con una squadra, se del caso. Se c'è una persona che rifiuta particolarmente di fare piccoli e frequenti impegni, parla con questa persona individualmente per capire perché la rifiuta.

   Possono fornire motivi perfettamente validi che possono darti il ​​suggerimento su cosa sta succedendo in una squadra. Alcuni motivi per cui mi sono sentito:

   • "Il mio insegnante / mentore mi ha detto che la migliore pratica è quella di fare un impegno al giorno." Non mi sorprende, dato quello che dovevo sentire dai miei insegnanti al college .

   • "I miei colleghi mi hanno detto che avrei dovuto impegnarmi di meno." Mi è stato detto anche in alcune squadre e capisco il loro punto. Avevamo un diario che era praticamente pieno dei miei impegni (non difficile da fare quando quattro compagni di squadra non ne fanno nemmeno uno al giorno), il che ha frustrato i miei colleghi.

   • "Pensavo che piccoli commit rendessero difficile trovare una revisione." In qualche modo punto valido, anche quando il team si impegna a scrivere messaggi di log descrittivi.

   • "Non voglio sprecare troppo spazio sul nostro server di controllo della versione". La persona ovviamente non capisce come vengono memorizzati i commit (né quanto sia economico lo spazio di archiviazione).

   • "Penso che un commit debba corrispondere a un compito specifico". Dato che spesso, un compito corrisponde a un lavoro da svolgere in un giorno (come nei pannelli di gestione visiva), questa non è una coincidenza. La persona dovrebbe quindi imparare a fare la differenza tra un'attività in un backlog (da 2 a 8 ore di lavoro) e una modifica logicamente isolata che dovrebbe essere impegnata (da pochi secondi a poche ore di lavoro). Ciò è anche correlato al punto 5.

7. Cerca il motivo per cui il team non si impegna più frequentemente. Potresti essere sorpreso dai risultati.

   Di recente, ho menzionato in una risposta diversa che la velocità di un commit è importante e persino centinaia di millisecondi possono spingere gli sviluppatori a impegnarsi su base meno frequente.

   Altre ragioni possono includere:

   • Regole troppo complicate per scrivere un messaggio di commit.

   • La regola che impone allo sviluppatore di collegare il commit a un'attività da un sistema di tracciamento dei bug.

   • La paura di rompere la build.

   • La riluttanza a fronteggiare il rischio di interrompere la build in questo momento: se fai un commit venerdì sera prima di partire, puoi rimandare la gestione della build interrotta fino a lunedì.

   • La paura di fare una fusione.

8. Determina se gli sviluppatori comprendono che ci sono altri vantaggi da impegnare spesso . Ad esempio, una piattaforma di integrazione continua è un grande incentivo ad avere impegni frequenti , poiché consente di individuare con precisione dove è stata introdotta la regressione .

   Preferirei preferire la piattaforma CI che mi dicesse che ho rotto la build nella revisione 5023 che consiste in una modifica di due metodi in un file che ho fatto quindici minuti fa, piuttosto che nella revisione 5023 consistente in modifiche che si estendono su quattro dozzine di file e rappresentano 13 ore di lavoro.

Un'organizzazione per la quale ho stipulato un contratto in passato voleva risolvere questo stesso problema e ha trovato una buona soluzione sociale: gli sviluppatori non hanno i propri computer. Lo sviluppo TEAM ha dei computer, ma a qualsiasi persona può essere chiesto e ci si aspetta che lavori su qualsiasi computer di sviluppo in un dato giorno. Quindi, il check-in è l'unico modo per assicurarti di poter continuare a lavorare su quello che stavi facendo ieri!

La direzione quindi ha fatto il giro e ha annullato di nascosto le modifiche sui computer dopo ore in modo che tutto ciò che non era stato archiviato andasse perso. Questi "guasti simulati al computer" dovevano verificarsi solo poche volte prima che gli sviluppatori entrassero a bordo.

Naturalmente, è importante spiegare il "perché" delle regole e il "cosa". A meno che il "perché" non sia chiarito, potrebbero semplicemente memorizzare la loro fonte su unità USB o qualcosa del genere.