Newsgroup: it.lavoro.informatica
Titolo: Code review _sistematiche_

Gerrit, anyone? Altro integrato in quello che già usate? Preferenze?

 Gerrit, anyone? Altro integrato in quello che già usate? Preferenze?
 
Mai usato. Nel tempo ho usato Crucible (anche se in azienda usavamo 
GitLab) e le pull requests in BitBucket, GitHub. Di Crucible mi piaceva 
l'integrazione con FishEye che consentiva di usare gli 'smart commits' 
(
https://confluence.atlassian.com/fisheye/using-smart-commits-960155400.html
)
 
Di tutti quelli che ho usato, GitHub forse e` stato il migliore.
 
Noi comunque ci stiamo allontanando dall'idea di fare code review 
sistematiche. Una tendenza generale e` quella di non consentire nessun 
merge sul trunk principale di sviluppo (oggi quasi sempre 'master' visto 
l'onnipresente git) senza una pull request. Noi pero`, adottando il 
pair-programming come pratica standard, consideriamo il codice 
'reviewed' di default.
 
In sostanza, short-lived branches con merge diretto della coppia su 
master a fine lavoro, ed anche per funzionalita` incomplete (magari 
dietro un feature toggle se vanno nascoste).
 
Ovvio che se si ha bisogno di un terzo parere, si puo` creare comunque 
una Pull Request, pero` l'idea e` di adottare trunk-based development ed 
integrarsi in master il piu` frequentemente possibile.
 
Si tratta di due team di programmatori esperti, pero`, per cui non mi 
aspetto soprese. A volte facciamo mob-programming, che annulla del tutto 
la necessita` di code review.

 consideriamo il codice 'reviewed' di default. 
 
Plausibile. Io mi trovo in situazioni molto diverse tra loro, a volte anche agli estremi: gruppi piccolissimi con praticamente qualunque libertà d'azione (per dire, due o tre persone in collaborativa in remoto con client/server emacs), oppure organizzazioni immense con livelli gerarchici di review a volte un pò da impazzire (con la logica delle submit rules in Gerrit che è nu'trattato bibblico). Nel mezzo di tutto.
Io non sono tipo da morire sotto i tools e le conf, vorrei trovare un punto fermo da proporre nei casi micro-piccoli. O per i disorganizzati, perchè m'è capitato Perforce ad esempio, e andando di p4 shelve ce la siamo cavata ma non era l'ideale per me.
Penso che si GitHub potrebbe essere la soluzione più pratica (anche se non sopporto git e lo uso proprio perchè devo, ma questo è un altro discorso) e familiare per tanti, cosa non da poco.

 frequentemente possibile. 
 
Ecco questo per me è un dettaglio non da poco. Non è detto chd non mi servano anche n pareri (purtroppo, a volte). In certi casi codice+docs devono essere scrutinati a più livelli (High-Assurance realistico, altre volte invece solo parate di culo ma quell'è...). Gerrit lì con il suo engine in prolog ti fa modellare il flow necessario[*].
 
[*] Se poi anche quell'aspetto del development deve essere certificato a priori, come non detto.

 mob-programming
 
Mi era sfuggito: non sapevo avesse un nome wow. Mi ricorda conf e meets vari, un laptop, tanti A4 e gente che finiva prima a mano quello che in due lavoravano alla tastiera lol

Mi era sfuggito: non sapevo avesse un nome wow.
 
Il mob-programming e` fantastico. Non lo porterei ad estremi come in alcuni team[*], ma e` sorprendente quanto un gruppo di persone che lavori insieme su una funzionalita` possa essere piu` veloce delle singole persone, che lavorino indipendentemente. Piu` veloce anche perche` eviti lunghe code review. E` un approccio perfetto per il test-driven, produce codice di alta qualita` ed e` perfetto per condividere conoscenza.
 
[*] 
https://www.youtube.com/watch?v=SHOVVnRB4h0&t=848s
 

 A me git non dispiace, ma capisco che a molti possa non piacere. Tra l'altro, il piu` delle volte, lo uso tramite IntelliJ IDEA, quindi la linea di comando non la vedo neanche. 
 
hai mai provato un alternativa moderna? Io venivo da Mercurial, adesso mi tocca usare Git perche' sostanzialmente e' diventato lo standard di fatto. 
Sono rimasto sorpreso da come possa avere avuto successo, con una command line allucinante e impossibile da imparare, e un model (nel dettaglio intendo) che ancora oggi stento a capire.

 Sono rimasto sorpreso da come possa avere avuto successo, con una command line allucinante e impossibile da imparare, e un model (nel dettaglio intendo) che ancora oggi stento a capire.
 
Io mi limito ad usarlo per quelle poche operazioni che mi servono (clone, pull, merge/rebase, push, squash, e poco altro), ma di diventare un esperto di git proprio non ho voglia. Concordo, la quantita` dei comandi e la complicazione (non tanto la complessita`) lo rendono veramente antipatico.
 


Si pure io uso quei pochi comandi, ma anche una cosa basilare come stash ha svariati parametri (e fin qua ci sta) con nomi fuorvianti e comportamenti ridicoli. Da stackoverflow: 
 
git stash --include-untracked no longer touches ignored files 
 
LOL quindi dovrei aggiungere un parametro di 17 caratteri per una cosa che dovrebbe esserci di default, e in ogni caso se lo facevi una volta ti trovavi i target/* dentro? 
 
Fuori di testa :P

 LOL quindi dovrei aggiungere un parametro di 17 caratteri per una cosa che dovrebbe esserci di default, e in ogni caso se lo facevi una volta ti trovavi i target/* dentro?
 
Si`, non e` agevolissimo. Personalmente, lo stashing di git lo evito 
volentieri. Cerco di usare IDEA e la sua shelf. O, al limite, committare 
su un branch.
 


Mi pare poco fattibile nel momento in cui si è spesso in remoto, o sbaglio?
 
  ngw


Che la CLI faccia cagare è sicuro, ma è anche molto potente.
Alla fine in un modo o nell'altro riesco a fare letteralmente tutto quel che voglio, specialmente se faccio delle cazzate (e le faccio *sempre*) riesco sempre a recuperare.
Mercurial piaceva anche a me.
 
  ngw

 Mi pare poco fattibile nel momento in cui si è spesso in remoto, o sbaglio?
 
Intendi il pair-programming? Noi lo facciamo anche da remoto.


E come fai? Hangouts?
 
  ngw

 E come fai? Hangouts?
 
Anche. Noi usiamo Microsoft Teams, ma anche Slack o Skype. 

 ti trovavi i target/* dentro?
 
mmm... non so dove hai trovato quella doc ma non c'entrano niente gli 
ignored. quella opzione serve per includere gli untracked file, ovvero i 
file nuovi che non sono ancora aggiunti allo stage.
se non la specifichi semplicemente non li tocca.