Stampa

Effettua l'accesso o una nuova registrazione.
1 ora 1 giorno 1 settimana 1 mese Sempre
Inserisci il nome utente, la password e la durata della sessione.

[Cherno]

Mi perplime usare strumenti inaffidabili per un processo che deve essere affidabile.

Io sono in ingegnere all'antica: meno parti si muovono e più il meccanismo è difficile che si rompa.

Mal che vada, si spacca tutto insieme. Nè?

[StM]

Mi perplime usare strumenti inaffidabili per un processo che deve essere affidabile.

Io sono in ingegnere all'antica: meno parti si muovono e più il meccanismo è difficile che si rompa.

I problemi che ho riscontrato sono solo delle noie, tipo il fatto che il plugin non gestisce commit di notevoli quantità di file contemporaneamente. Ma quanto all'affidabilità di mercurial non ho dubbi (probabilmente qualche volta si comporterà in modo inaspettato, visto che ha le sue abitudini strane, come ad esempio la copia di file tiene traccia del file di origine... ma non è un bug, è una feature ).

Il problema del fattore umano invece è più che altro l'atteggiamento di non avere voglia di imparare ad usare le cose e 1) rifiutare di usarle o 2) usarle con scazzo e odio cercando di sputtanare tutto.

[Id]

Mi perplime usare strumenti inaffidabili per un processo che deve essere affidabile.

Io sono in ingegnere all'antica: meno parti si muovono e più il meccanismo è difficile che si rompa.

I problemi che ho riscontrato sono solo delle noie, tipo il fatto che il plugin non gestisce commit di notevoli quantità di file contemporaneamente. Ma quanto all'affidabilità di mercurial non ho dubbi (probabilmente qualche volta si comporterà in modo inaspettato, visto che ha le sue abitudini strane, come ad esempio la copia di file tiene traccia del file di origine... ma non è un bug, è una feature ).

Certo che e' una feature
Considera che se copi un file A creando un file B, di fatto hai branchato A, e ne tiene traccia per non perdere lo storico. Non e' del tutto stupido

Il problema del fattore umano invece è più che altro l'atteggiamento di non avere voglia di imparare ad usare le cose e 1) rifiutare di usarle o 2) usarle con scazzo e odio cercando di sputtanare tutto.

Insisto con la graffetta. Funziona. Vedrai che alla terza volta, hanno imparato tutti.

[Ziggybee]

Il problema del fattore umano invece è più che altro l'atteggiamento di non avere voglia di imparare ad usare le cose e 1) rifiutare di usarle o 2) usarle con scazzo e odio cercando di sputtanare tutto.

Non credi che costringere la gente ad imparare workaround o accorgimenti aggiuntivi non faccia che esacerbare ancora di più la loro naturale ostilità ad uno strumento che gli viene imposto? Oltre che a fornire strumenti per dimostrarti che avevano ragione, mettendo in pratica il punto 2.

La mia esperienza mi ha insegnato che già di per sé è difficile far capire ai programmatori che una disciplina serve anche per migliorare la loro vita lavorativa, oltre che la qualità e l'affidabilità dello sviluppo (mi viene in mente quando qualche anno fa introdussi il test driven development per alcuni componenti di progetto, ci fu un ammutinamento di due mesi prima che gli sviluppatori stessi inziassero a riconoscere che gli rendeva la vita più semplice rispetto ai loro metodi da trial & error), se ci metti pure degli strumenti o delle metodologie che sono percepite come il proverbiale Dito Al Culo (altrimenti detto DAC) perché non funzionano perfettamente o obbligano la gente già negativa a pensarci su per farle andare, non c'è vantaggio o visione che tenga.

Io stesso funziono così.

[StM]

Ma quanto all'affidabilità di mercurial non ho dubbi (probabilmente qualche volta si comporterà in modo inaspettato, visto che ha le sue abitudini strane, come ad esempio la copia di file tiene traccia del file di origine... ma non è un bug, è una feature ).

Certo che e' una feature
Considera che se copi un file A creando un file B, di fatto hai branchato A, e ne tiene traccia per non perdere lo storico. Non e' del tutto stupido

Infatti è molto interessante, però è uno dei modi in cui mercurial si stacca molto dal modo di pensare lineare di chi pensa in termini di filesystem.

Il problema del fattore umano invece è più che altro l'atteggiamento di non avere voglia di imparare ad usare le cose e 1) rifiutare di usarle o 2) usarle con scazzo e odio cercando di sputtanare tutto.

Non credi che costringere la gente ad imparare workaround o accorgimenti aggiuntivi non faccia che esacerbare ancora di più la loro naturale ostilità ad uno strumento che gli viene imposto? Oltre che a fornire strumenti per dimostrarti che avevano ragione, mettendo in pratica il punto 2.

La mia esperienza mi ha insegnato che già di per sé è difficile far capire ai programmatori che una disciplina serve anche per migliorare la loro vita lavorativa, oltre che la qualità e l'affidabilità dello sviluppo (mi viene in mente quando qualche anno fa introdussi il test driven development per alcuni componenti di progetto, ci fu un ammutinamento di due mesi prima che gli sviluppatori stessi inziassero a riconoscere che gli rendeva la vita più semplice rispetto ai loro metodi da trial & error), se ci metti pure degli strumenti o delle metodologie che sono percepite come il proverbiale Dito Al Culo (altrimenti detto DAC) perché non funzionano perfettamente o obbligano la gente già negativa a pensarci su per farle andare, non c'è vantaggio o visione che tenga.

Io stesso funziono così.

Innanzitutto non c'è imposizione. Io ho fatto una proposta, qualcuno si è detto d'accordo, finora nessuno ha detto "no, manco morto". Penso che anni di sfiancamento a causa dei problemi di un certo modo di fare sviluppo abbiano fatto nascere il desiderio di un miglioramento.

L'unica cosa che è un "workaround" è la, forse temporanea, mappatura generica del progetto con eventuale utilizzo di symlink (con eclipse non sono necessari); ma questo perché così nessuno è costretto a un particolare IDE, visto che ogni IDE ha i suoi bei punti deboli irrisolti da anni ed è inutile imporne uno a tutti se nessuno fa bene TUTTO.

Per il resto mi sembra che i vantaggi superino ampiamente gli svantaggi e il (poco) lavoro in più. Ma metto le mani avanti perché mi rendo conto che non tutti, avendo raggiunto un alto livello di produttività con i propri strumenti (per carità, più che sufficienti se si lavora da soli), ha voglia di abbassarla per una giornata intera per imparare qualcosa di nuovo con la *dovuta pazienza*.

Non vedo la divergenza tra "cose che vanno perfettamente" e "pensarci su per farle andare". Per un normale workflow mercurial è *facile*. Il branching e merge è appena appena più complicato. Per finezze particolari come modificare la release 14 e riportare il bugfix alle release successive magari c'è un po' da leggere, ma se l'alternativa è andare a scavare nei backup zippati una particolare versione del progetto, di cui hai solo i tuoi sorgenti e non quelli degli altri, compilare alla speraindio... be', direi che è grasso che cola.

(sto esagerando... ma non troppo )

[StM]

Sembra funzionare piuttosto bene, l'amico Mercurial. Certo, la decentralizzazione aggiunge dei passaggi all'operazione di commit (che porta potenzialmente con sé un'operazione di merge ogni volta - operazione in genere automatica, comunque), ma spesso sviluppiamo sul campo e quindi è in realtà un valore aggiunto.

Magari è presto per cantare vittoria, ma la temuta negatività non è per ora pervenuta, sono stato pessimista

[Ziggybee]

Io sto avendo dei problemi di build management sul progetto del nostro nuovo prodotto... Piano tirennale, roba grossa.

Abbiamo circa 20 persone che sviluppano e non seguono alcuna logica umana.

I problemi sono anche di tipo organizzativo (non c'è alcuna pipeline di sviluppo: il mercato chiede e loro fanno). Nessuno è coordinato con niente. Se l'utente A implementa una feature, forka e la scrive. L'ultimo che finisce prima della release della milestone si becca il merge (mentre facevo l'auditing del vecchio processo uno è durato 4 ore e mezzo, la media è 1:10).

Siccome non c'è una persona una che ha una del totale del progetto (che non è concettualmente così complesso da non renderlo possibile è solo che in due anni di preliminari non hanno scritto un cazzo di documentazion e con il tempo l'analisi iniziale è diventata una leggenda urbana tramandata la sera dopo gli straordinari non pagati), chi fa il merge spesso non è che sa bene cosa sta facendo... Non vi dico cosa succede al testing (fatto a mano)...

Insomma morale della favola, stiamo cercando di riorganizzare tutto e si parte proprio dal source e dal build management. Al momento usiamo questa tecnica:

All'inzio di ogni sprint (al momento intese in senso molto lato) decidiamo le nuove feature e chi se ne occupa.

Ogni gruppo che si occupa di una feature brancha il proprio codice e a feature è conclusa fa il merge con il trunk di sviluppo. E' un merge di nome e non di fatto: il codice è separato, quindi i task sono verticalizzati in maniera tale che i vari gruppo di lavoro si occupano dello stesso subset di componenti, così ci sono collisioni minime. Il merge non lo fa un pincopallo a cazzo, lo fa un build manager (uno degli sviluppatori senior o io) che si fanno aiutare dal team leader del gruppo di lavoro. Questo non tanto per allineare versioni e dirimere collisioni quando per verificare che la qualità del codice sia garantita (usiamo i tool di visual studio ma non è sbagliato assicurarsi che i dev più giovani non stiano prendendo brutte pieghe).

A fine milestone, il trunk di sviluppo è tornato sano, si verifica che buildi e si passa tutto al trunk di release. Il build manager a quel punto dà luce verde a chi si occupa dei test che procedono da unit testing in su (sino a test automatizzati di VS, non tutto è testabile a quel modo ma è sempre meglio di far fare tutto a mano ad un pincopallo scazzato che deve scorrere un excel di casi di test), producendo un casino di report, tra cui uno stato di qualità del codice (molto utile quello di copertura del codice che ci fa capire se abbiamo impostato male i test o abbiamo codice morto).

A questo punto si riparte con un altro sprint, la cui prima attività (1 giorno circa) è decidere se bisogna modificare le frontiere (interfacce, web service, etc) dei vari sistemi per implementare le nuove feature. Se si, si procede alla modifica delle stesse e alla creazione di eventuali Stub per avere il codice buildabile, poi si parte con l'implementazione delle nuove cose. Ad ogni fine giornata, chiunque abbia lavorato deve committare tutto con merge automatico. Se non ci sono collisioni da sistemare a mano, di notte il server builda e il mattino sappiamo se ci sono problemi grossolani.

Devo dire che nonostante sembri tutto complicato funziona piuttosto bene (e abbiamo praticamente annullato i merge in senso stretto, anche se per arrivarci ho dovuto fare 2 sett e mezzo di refactoring praticamente da solo, perché quasi nessuno aveva idea di dove si potesse arrivare con un po' di disciplina).

Ora resta l'ultimo scoglio: passare il controllo ai quattro team da cinque per la definizione dei task negli sprint settimanali: si stanno letteralmente cagando sotto, anche se due settimane fa hanno dovuto subire la sottostima di un'attività (di solo il 637%, che volete che sia) fatta da terzi. Visto che la qualità del lavoro era bassa e i cazziatoni costanti, sono convinti che prendersi direttamente la responsabilità sul decidere cosa fare e per quando farlo sia errata. Al momento partiremo con i team leader che stimano le attività ma l'idea finale è che ogni sviluppatore diventi padrone della sua velocity e la usi al meglio, anche in funzione di impegni personali, etc etc...

[StM]

La mancanza di una "pipeline di sviluppo" è un nostro problema a cui stiamo cercando di mettere qualche pezza, ma nel nostro settore è impossibile pensare di non soddisfare immantinente il cliente mettendoci anche a 90, quindi alcune cose vengono fatte fast&furious. Tra gare di appalto, ricatti più o meno velati, direttori-dittatori che tengono i cordoni della borsa, project manager che devono far firmare il collaudo il prima possibile, non c'è proprio verso di dire "aspettate la prossima release" .

Oggi su mercurial ho sperimentato la rimozione di una revisione sbagliata ormai impilata sotto varie revisioni giuste (ovvero il backout... ha funzionato!) e il merge di un branch di sviluppo con il branch principale per tenerlo allineato con le ultime modifiche pur mantenendoli separati (e ha funzionato pure questo! Magggico!). Per quanto ci impegnamo pare difficile fare casini senza via d'uscita... ma prima o poi ci riusciremo . Oltretutto mi pare che non sia così difficile da usare nemmeno per sviluppatori junior (o almeno, mi sembra che si pongano domande e si diano risposte sensate).

[Ziggybee]

Considera che comunque MINIMO c'è un rilascio a settimana, quindi pure noi non è che siamo molto larghi con i tempi.

Il vantaggio è che se ti organizzi, tranne cause di forza maggiore a cui ti devi chinare, l'entropia che ti genera l'imprevisto a cui non puoi dire di no è molto ma molto minore... Il vantaggio è che alla fine tutti sono informati sullo stato, se non lo sono possono farsene un'idea chiedendo o visualizzando la dashboard del progetto. Sono sempre più convinto che più che fare le cose, in informatica, è opportuno mantenere ottime comunicazioni. Già con 4-5 persone è facile che la mano destra non sappia cosa faccia la sinistra, per non parlare che se poi ti capita un dev paraculo che insabbia le rogne è la fine!

[StM]

Una cose che detesto è ricavare indirettamente l'informazione che un collega sta facendo qualcosa che, se chiedeva a me, risolveva in 10 minuti e senza far casini. Magari lo scopri quando ti fanno domande misteriose e indirette, in buona fede per carità, ma tante volte m'è venuto da chiedere: "scusa, ho seguito questa cosa per 3 anni qui dentro, perché non mi hai detto nulla che dovevi usarla/farci degli aggiornamenti/altro?"; oppure, "perché hai reinventato la ruota invece di chiedermi il codice collaudato che la faceva e al massimo adattarlo alle nuove esigenze?". E parlo di quelli che per certo SANNO che possono chiedere a me, poi ci sono quelli che non lo sanno e allora è un altro problema*.

*=anche questo non indifferente perché già solo il gruppo di sviluppatori si sta avvicinando alla trentina di componenti; per fortuna non più di 5-6 lavorano allo stesso progetto, ma il lavoro di alcuni impatta sul lavoro di 10-15 altri (e spesso lo tiene parzialmente fermo, ma dopotutto sono persone quasi insostituibili)... non ci stiamo muovendo male, ma molte cose abbiamo dovuto e le stiamo riorganizzando.

[StM]

Un altro mese è passato, e a parte un caso di perdita del lavoro di 2 giorni di una persona (che ha forzato un update senza aver mai dato commit :sigh: - è un genio, ma a volte è un po' troppo "fai da te" quanto alle soluzioni per i problemi sconosciuti ), per il resto ce la stiamo cavando bene. Il merge di due rami che sono proseguiti paralleli per un mesetto ci ha preso 15 minuti per via di 3 file che erano stati modificati indipendentemente, ma il resto è filato liscio in automatico.

A quota 100 revisioni le dimensioni di uno dei repository non è aumentato visibilmente (tra una revisione e l'altra ci sono prevalentemente differenze testuali).

In definitiva se il fatto che sia distribuito è uno dei vostri requisiti direi che mercurial è un'ottima scelta. Altrimenti probabilmente ci sono scelte migliori.