Come registrare la configurazione o il comportamento del codice in modo non distruttivo [chiuso]

Se il tuo team trova la posta elettronica dirompente o la sintonizza, qualcosa non va (hanno impostato le loro notifiche in modo troppo diretto, o ricevono troppe e-mail private o non hanno impostato filtri / trigger correttamente). L'e-mail è, a mio parere, lo strumento perfetto per questo. Impostalo correttamente e servirà al suo scopo.

Potresti fare qualcosa di stupido e complicato, come usare una pagina wiki, impostare un feed RSS appositamente per questo, o dare al team un account Twitter bizzarro, ma quando ti fermi a pensarci, l'email può già fare cosa vuoi.

Penso che una buona pratica sia quella di impostare un hook di post-commit per inviare via e-mail il diff delle modifiche. Imposta un prefisso dell'oggetto fisso e l'indirizzo del mittente [email protected] per facilitarne il filtraggio, quindi non è intrusivo.

Lo abbiamo fatto in tutti i miei luoghi di lavoro passati, ed è sempre popolare. Molti sviluppatori leggono regolarmente i diff e raccomandano miglioramenti l'un l'altro. È un buon modo per tenere tutti ben informati sui cambiamenti che si verificano nel progetto. Alcuni sviluppatori potrebbero non essere troppo felici all'inizio, ho sentito lamentele di "qualche strano spam", riferendosi alle e-mail diff, ma anche gli scettici tendono a scaldarsi all'idea dopo un po '. Lo consiglio vivamente.

per quanto riguarda l'aggiunta di un file di testo "compatibility_issues.txt" in cui le modifiche alla configurazione o al codice vengono aggiunte insieme alle informazioni sulla versione / datetime e aggiungere questo file al repository sourcecode. In questo modo i problemi non si perdono e puoi trovare i frammenti del codice sorgente correlati alle modifiche attraverso la cronologia del repository sourcecode.

tuttavia terrei comunque via email questi problemi.

Hai una convenzione di denominazione per queste e-mail. Se io come sviluppatore non sono intrstested in questo "compatible-change-spam" posso impostare un filtro email per questo.

Presumo che tu abbia cambiato qualcosa perché hai avuto un difetto da correggere o una funzionalità implementata. Il modo corretto per far sapere alle persone di questi cambiamenti è il tuo sistema di tracciamento delle modifiche.

Se l'e-mail è il tuo sistema di tracciamento delle modifiche e le persone non leggono le e-mail, non farà molta differenza se invii uno o non ........

Applica (idealmente automaticamente) la creazione di commenti di controllo nel tuo sistema di controllo del codice sorgente. In questo modo le persone possono facilmente vedere un riepilogo delle modifiche che sono state apportate di recente.

Facciamo questo in 2 modi. Innanzitutto, per la maggior parte delle app, i file di configurazione sono versionati usando SVN. Quindi puoi sempre andare a svn log e forse ottenere un contesto. In secondo luogo, utilizziamo un tracker dei problemi come record ufficiale di richieste e modifiche. Le persone possono gestire le proprie impostazioni da sole in quel sistema per gestire il proprio spam. In entrambi i casi sei coperto: hai informazioni tecniche locali e forse un contesto nel tracker dei problemi e nulla ti viene in faccia a meno che non lo desideri in questo modo.

Nel nostro team facciamo revisioni di codice con Gerrit ora, e da quando abbiamo iniziato è diventato più facile tenere tutti in attesa di modifiche al codice. Il team è relativamente piccolo e tutti esaminano tutti gli altri cambiamenti, quindi la consapevolezza di questi è piuttosto alta. Abbiamo concordato di iniziare una giornata con le revisioni del codice, e il codice non è andato al master branch prima di essere revisionato, quindi di solito c'è una spinta dall'autore del codice per ottenere la fusione della sua modifica e il processo di revisione non è bloccato. Immagino che introdurre una revisione del codice potrebbe essere un cambiamento troppo grande nel tuo processo di sviluppo per prendere questa come risposta, ma questo sicuramente aiuta.