Newsgroup: it.lavoro.informatica
Titolo: Da dove partire?

Mi serve documentazione o suggerimenti da chi ha più esperienza di me.
 
Ho per le mani del software, scritto una decina di anni fa, che _devo_ ristrutturare, che così com'è è difficile (impossibile) da manutenere. Funziona, per funzionare, ed è pure parecchio - molto - grosso, ma tant'è.
 
Il brutto è che non posso nemmeno prendermela più di tanto con chi l'ha scritto dato quel qualcuno sono io. Certo, dovevo essere in un periodo di depressione profonda, che 'spaghetti code' a 'sto livello ne ho visto poco.
 
Ecco: da dove suggerite di partire, sapendo che poi, alla fine, deve essere fatto tutto come Dio comanda (test compresi)? Intendo, come dicevo, documentazione ("pirla, non fare così!!") o suggerimenti di esperienza.
Sto seriamente pensando che riscriverlo a pezzi sia la soluzione più indolore.
 
Grazie.
 
-- 
Ciao!
Luca

 Sto seriamente pensando che riscriverlo a pezzi sia la soluzione più indolore.
 
Da qui, innanzitutto: 
http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672/ref=sr_1_1?ie=UTF8&qid=1456161764&sr=8-1&keywords=refactoring+martin+fowler
 
 
 

 Da qui, innanzitutto: 
http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672/ref=sr_1_1?ie=UTF8&qid=1456161764&sr=8-1&keywords=refactoring+martin+fowler
 
 
Visto estratto. Interessante, domani lo prendo. Grazie.
Però, li fanno pagare parecchio meno i libri da Amazon, a voi britannici...
 
-- 
Ciao!
Luca
 
 

 Però, li fanno pagare parecchio meno i libri da Amazon, a voi britannici...
 
Non so quanto costino le versioni tradotte, non le ho mai comprate. In questo caso si tratta di Fowler, i cui libri di solito conservano un valore alto per via del prestigio e dei contenuti che faticano a tramontare.

 Non so quanto costino le versioni tradotte
 
Non credo manco esista la versione tradotta. Sto parlando dello stesso identico libro. Al link che mi hai dato la versione Kindle costa poco più di 21 sterline (a cambio corrente, circa 28 EUR). Nel sito italiano di Amazon (all'url basta sostituire .
co.uk
 con it) si sale a 38.47 EUR!
 
For the record, non ricordo nemmeno l'ultimo libro che ho comprato in versione tradotta. Ricordo solo che era pieno di errori di traduzione, per cui da quel punto in avanti ci ho rinunciato.
 
-- 
Ciao!
Luca


 
Compralo da Amazon UK.
Tantissime cose nel sito UK costano meno rispetto a quello Italiano e non si 
capisce il motivo, perfino la spedizione costa meno (se non hai il Prime)!
 
Gabriele
 


Lascia stare la ristrutturazione generica
Ristruttura al massimo i pezzi che ti interessano per correggere bachi o 
aggiungere funzionalità
 


I libri non possono essere scontati piu' del 15% in Italia, almeno se quella legge e' rimasta. Il tutto per aiutare le piccole librerie. 
 
Una legge che a te dovrebbe piacere :)

 Sto parlando dello stesso identico libro.
 > Al link che mi hai dato la versione Kindle costa poco più di 21 sterline
 > (a cambio corrente, circa 28 EUR). Nel sito italiano di Amazon 
(all'url basta sostituire .
co.uk
 con it) si sale a 38.47 EUR!
 
Ho letto l'ultimo libro tradotto 17 anni fa. Era la versione italiana di 
"Programming Applications for Microsoft Windows" di Richter.
 
Illeggibile in italiano; uno dei migliori libri che abbia mai letto, in 
inglese. Da allora in poi, solo libri in lingua originale.
 
-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)
"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 
http://goo.gl/1nrkkX
 

 
 
 
non penso di aver compreso sino in fondo lo scenario, perché sei stato
un po' vago, non ho nemmeno capito di quale ambito stai parlando.
 
 
Quello che posso suggerirti io vale per il web, ma secondo me è un
approccio che può essere valido in generale.
 
 
Secondo me ti conviene per prima cosa tenere un backup della
vecchia versione, quella che hai scritto 10 anni fa e che, come dici tu,
fa schifo ma funziona.
Che se c'è una cosa che ho ben assimilato, è che prima di modificare
un software che funziona guai non conservare una copia della
versione che si deve modificare, ma questo lo saprai meglio di me.
 
Detto questo, io progetterei per bene le funzionalità che devo
riscrivere, prevedendo i possibili scenari e i metodi da scrivere di
conseguenza.
Insomma, ti scrivi con carta e penna (o con un programma, se sei
più comodo così) cosa deve fare la funzionalità, come devono
essere le classi/i metodi, ecc.
 
Naturalmente questa fase preliminare, se il software è molto
complicato, può richiedere molto tempo, non è cose da fare in 2 ore,
e nemmeno in un giorno, almeno questa è l'idea che mi faccio io
dalla tua descrizione.
 
Poi, una volta convinto della progettazione, inizierei la riscrittura.
 
 
Più di questo, non avendo informazioni più specifiche sul problema,
non mi viene in mente.
 

 essere le classi/i metodi, ecc.
 
Non e` il modo migliore di procedere. Se il software e` complesso, come 
immagino, concentrarsi sulla gerarchia di classi significa focalizzare 
l'attenzione su un livello di granularita` troppo alto e potrebbe 
portare fuori strada. Bisogna invece estrapolare la logica di business, 
identificare i "behaviours", scrivere degli acceptance test e procedere 
da li`. Ovviamente non conosco il caso concreto, per cui quel che scrivo 
va preso cum grano salis, ma l'approccio e` corretto. Queste sono 
situazioni in cui adoperare una tecnica test-driven/behaviour-driven 
(non solo di sviluppo, ma anche di acceptance) e` una buona strada.
 
Un po' di spunti:
 
https://en.wikipedia.org/wiki/Test-driven_development
 
https://en.wikipedia.org/wiki/Acceptance_test-driven_development
 
https://en.wikipedia.org/wiki/Specification_by_example
 
https://en.wikipedia.org/wiki/Behavior-driven_development
 



parti dal valutare se conviene, in termini di tempo, riscriverlo da zero
 
-- 
Soprano


ma adesso
è scritto in ?
cosa fa ?
perchè fare un refactoring?
forse non hai un cazzo da fare?
 
 
-- 
Quando la dittatura è un dato di fatto, la rivoluzione diventa un diritto.
(Victor Hugo)

 'spaghetti code' a 'sto livello ne ho visto poco.
 
prima di mettere mano al codice, dovresti fare un'analisi seria (ed onesta) a 360 gradi, non solo del codice, ma anche delle specifiche e del testing che hai fatto 10 anni fa. Potresti, ad esempio, scoprire che hai scritto codice alla pene di segugio non per la "depressione profonda" ma per un profondo "scope creep", e magari il riscrivere il codice con le stesse specifiche dell'epoca ti porterebbe ad ottenere lo stesso risultato di 10 anni fa, se non peggiore.
 
Devi anche tenere in conto il fattore tempo, probabilmente 10 anni fa era il tuo progetto principale, quindi avevi tempo da dedicarci. Immagino che ora sia un lavoro marginale, e quindi il riscriverlo è tempo che sottrai agli altri progetti (e/o) al tuo tempo libero. Saprai meglio di me che non c'è solo lo sviluppo da tenere in conto: l'analisi delle specifiche prende tempo, il testing prende tempo. Il riscrivere da zero un progetto complesso porta via tempo, e tanto, e se il tempo non lo pianifichi per bene (i.e. con stime pessimistiche, che tengono conto del tempo libero e dei tuoi progetti principali), c'è rischio concreto che tu produca una versione di qualità di gran lunga inferiore a quella originale, che non utilizzerai mai.


Esistono da una vita i  control version
Si da per scontato per qualunque sviluppatore ne usi almeno uno.
 

 forse non hai un cazzo da fare?
 
Non credo ti renderai conto da solo circa l'inutilità di queste domande.
 
-- 
Ciao!
Luca

 e quindi il riscriverlo è tempo che sottrai agli altri progetti (e/o) al tuo tempo libero. 
 
Riscriverlo era una boutade. Non ha senso, ne in termini di tempo ne di denaro: non mi pagano abbastanza. Pero' una bella revisione - magari non di tutto, ma delle parti principali - è assolutamente necessaria.
 
-- 
Ciao!
Luca

 legge e' rimasta. Il tutto per aiutare le piccole librerie. 
 
Legge a cui erano contrarie le piccole librerie...
 
Ciao
  Francesco


E tu ci credi? Complimenti.

 Non ne sono convinto. Saranno magari i 10 anni di più e l'aver studiato di più, ma non riscriverei MAI una roba del genere in quel modo, per quanto fumose possano essere le specifiche.
 
Mai dire mai. Quando riscrivi un software, sei pieno di buone intenzioni. Il problema e` mantenere quelle buone intenzioni nel tempo e non "sbracarsi". Qui dentro c'e` gente che considera del tutto lecito scrivere codice a cazzo se sei stretto con i tempi. E io dico che dopo 10 anni i risultati si vedono.

 E tu ci credi? Complimenti.
 
Conosco piuttosto bene il mondo della piccola editoria e ti posso garantire che gli unici che hanno guadagnato con quella legge sono le grosse catene di franchising librario.
 
Le piccole librerie ed i piccoli editori erano soliti usare forti scontistiche per avere visibilità e questa legge gli ha tolto anche questa possibilità.
 
Ciao
  Francesco

 Esistono da una vita i  control version
 
Semmai i Version Control Systems. E se tu imparassi a quotare, non sarebbe male.


Ma cosa vuoi garantire. Adesso salta fuori che nel tuo mondo le GDO fanno meno sconti del negozietto che stenta a tirare avanti.
 
https://leggesulprezzodellibro.wordpress.com/
 
 
"Il consiglio dei ministri che oggi ha varato il disegno di legge sulla Concorrenza ha deciso di stralciare la parte che avrebbe praticamente abrogato la legge Levi, quella che fissa un tetto massimo di sconto sui libri al 15%. La protesta e la mobilitazione dei giorni scorsi, soprattutto da parte di librai ed editori indipendenti, oltre che di attori istituzionali come il Centro per il libro e la lettura attraverso la voce del suo presidente Romano Montroni, ha bloccato una misura dissennata che avrebbe portato un colpo mortale al pluralismo culturale e alla effettiva possibilità di concorrenza. L'Odei si rallegra del ripensamento del governo"
 
 
librai ed editori indipendenti...ha bloccato una misura dissennata...L'Odei si rallegra
 
Mamma mia che contrari che erano questi editori indipendenti!
 

 Mamma mia che contrari che erano questi editori indipendenti!
 
Se invece che leggere quattro cose raccogliticce su internet avessi seguito la questione sapresti di cosa stai parlando.
 
Ciao
  Francesco

 Se invece che leggere quattro cose raccogliticce su internet avessi seguito la questione sapresti di cosa stai parlando.
 
Non ho raccolto un bel niente. So, per logica, che fa comodo ai piccoli e guarda a caso mi sono subito imabattuto nel "Osservatorio degli editori indipendenti" che plaude con gioia al blocco degli sconti.
 
Tu questo sai spiegarlo, oppure ribatterai ancora che io non so niente e tu sai tutto?


ma se una grande catena di distribuzione, per non far nomi comincia per 
"a" e finisce per "mazon", avesse avuto opportunità di fare dumping, le 
piccole librerie avrebbero chiuso bottega e anche il franchising librario 
avrebbe subito una bella sfoltita.
perché era quello il rischio.
 

 perché era quello il rischio.
 
Concordo rootkit infatti all'epoca si chiese che valesse per i grandi ma non per i piccoli editori.
 
Ciao
  Francesco


Dal punto di vista della "cultura" francamente non sarebbe stato affatto un male. Avrei avuto maggiore accesso in termini di prezzi ai libri. 
 
Invece l'idea portata avanti da alcuni secondo cui le piccole librerie offrirebbero chissa' quale servizio alternativo, e' francamente ridicola: nelle piccole librerie ci trovi di meno e a maggior prezzo.

 essere le specifiche.
 
Lo scope creep era solo un'ipotesi tra le tante possibili, per sottolineare come alle volte la qualità del software può non dipendere dalla preparazione tecnica del programmatore, ma da tanti altri parametri legati al progetto in se'. Io non ne sarei tanto convinto che con gli anni puoi solo migliorare. Se una cosa è andata male la prima volta  e non si capisce/razionalizza perché è andata male, andrà male anche la seconda, la terza, e anche la quarta volta. Da come scrivi sopra ha giocato un ruolo principale la relativa inesperienza di 10 anni fa. Bon, in tal caso se in questi 10 anni hai fatto training strutturati di ingegneria del software&refactoring, hai IMHO probabilità di far meglio, altrimenti IMHO hai probabilità di far peggio. Purtroppo le cattive abitudini sono le più difficili da togliere e le più semplici da automatizzare perché il più delle volte sono solo scorciatoie per raggiungere in fretta uno short-term goal. Ovviamente concordo con 4andre4 sul fatto che bisognerebbe cercare di perseguire il best practice, perché paga (e appaga) nel lungo termine. my 2 cents.
 
 

On 23/02/2016 08:23, Luca Menegotto wrote:
 
[...]
Ti consiglio anche "Working Effectively with Legacy Code" di Feathers. 
Me ne sono ricordato perche` l'ho visto tra i suggerimenti al testo di 
Fowler, su Amazon. E` un testo abbastanza vecchiotto, pero` i principi 
che espone sono validi ancora oggi.


 Grazie.
 
IMO una strategia di refactoring seria comporta anche avere una copertura al test completa. Quindi se non hai tutto ciò io inizierei da qui. Test automatizzati e copertura completa. Che è un lavoraccio. 


 
 
questo è poco ma sicuro.
 
Riscrivere un progetto, o comunque parte di esso, scritto 10 anni
fa e molto grosso.
Riscriverlo dopo così tanto tempo è lo stesso che scriverlo
per la prima volta.
 
Io dico che per fare una cosa come questa bisogna avere un motivo
davvero valido.
 
E in ogni caso, come ho già detto, in una situazione come questa
è fondamentale conservare un backup della vecchia versione,
sennò son dolori.
 

 sennò son dolori.
 
Aridaglie. 
Il consiglio ti assicuro appare ridicolo. Piu' che "conservare il backup", il progetto va messo sotto controllo di versione.

 Il consiglio ti assicuro appare ridicolo. Piu' che "conservare il backup", il progetto va messo sotto controllo di versione.
 
Concordo: il controllo versione in una situazione come questa salva la vita.
 
Ciao
  Francesco

 Concordo: il controllo versione in una situazione come questa salva la vita.
 
"in una situazione come questa"? 
 
Perche`, tu, in altre situazioni, lavori senza VCS?
 
 
 
 


mah io spero vivamente sotto vcs ci sia già.

 mah io spero vivamente sotto vcs ci sia già.
 
Oddio essendo di dieci anni fa ed in una realtà piccola non ci conterei tantissimo purtroppo.
 
Vedo realtà da diversi centinaia di milioni di fatturato all'anno non averlo.
 
Ciao 
  Francesco

 Vedo realtà da diversi centinaia di milioni di fatturato all'anno non averlo.
 
Si`, e io vedo la gente morta. Al giorno d'oggi non c'e` *UNA* azienda di informatica che non sia obbligata ad usare un vcs. Non e` giustificabile sviluppare software senza un vcs, neanche se si sviluppa per conto proprio.
 

 mah io spero vivamente sotto vcs ci sia già.
 
Magari si, ma dipende quale. 
 
Io ad esempio attualmente devo lavorare con SVN dopo tanti anni in cui ho usato Mercurial. E devo dire che mi fa cagare.

 Si`, e io vedo la gente morta. Al giorno d'oggi non c'e` *UNA* azienda di
informatica che non sia obbligata ad usare un vcs. Non e` giustificabile
sviluppare software senza un vcs, neanche se si sviluppa per conto proprio.
 
Tu dimentichi che qui siamo in Italia.
 
 


Non posso che darti ragione. L'uso di sistemi di versioning del codice 
non è molto diffuso... tempo da cercai di farlo inserire come un obbligo 
contrattuale per una fornitura importante ma ho avuto forti opposizioni 
e la richiesta non passò...


Esattamente: nessuno dice che sia la cosa migliore da fare anzi è di gran lunga la peggiore ma purtroppo è ancora estremamente diffuso anche in realtà decisamente grandi.
 
Ciao
  Francesco
 

 Magari si, ma dipende quale.
 
visto che è lui che se la canta e se la suona non vedo quel gran 
problema, migrerà a git piuttosto che mercurial se lo ritiene opportuno.
 
 

 Tu dimentichi che qui siamo in Italia.
 
Io in Italia ci ho lavorato per diversi anni e non c'e` una sola azienda in cui io sia stato in cui non si usava un sistema di versioning del codice. Nel tempo ho usato CVS (insegnando peraltro alla gente che non era un sistema di backup di file .zip), Visual Source Safe, SVN, git. Credo che qualunque posto di lavoro in cui non si lavori con un vcs sia da evitare come la peste. E` ormai un requisito indispensabile. Sembra anche banalisimo dirlo.
 

 banalisimo dirlo.
 
Su questo non ci piove.
 
 

 mah io spero vivamente sotto vcs ci sia già.
 
Adesso si (è la prima cosa che ho fatto), allora no.
 
-- 
Ciao!
Luca

 Si`, e io vedo la gente morta. Al giorno d'oggi 
 
Ecco, appunto. 10 anni (che poi in realtà a 'sto punto son 11) son quasi un'era geologica. Pensa, ero ancora biondo...
 
:-D
 
-- 
Ciao!
Luca

 attente di tante altre...
 
Togli pure il "puo` darsi". Il punto e` che non riesco a capire come si possa concepire di gestire un progetto software senza un controllo versione. Mi piacerebbe vedere come lavorano, le aziende di cui parlate, e che campioni sono quelli che scrivono software in quei posti.

 Ecco, appunto. 10 anni (che poi in realtà a 'sto punto son 11) son quasi un'era geologica.
 
Il punto e` che i vcs esistono da molto prima. Non scherziamo. Lavorare senza vcs, anche 10 anni fa, non era accettabile. CVS era lo standard per tutti gli anni '80 e parte dei '90. SVN raccoglieva l'eredita` di CVS, ed oggi git e` praticamente uno standard.
 

 Il punto e` che i vcs esistono da molto prima. Non scherziamo. Lavorare senza vcs, anche 10 anni fa, non era accettabile. CVS era lo standard per tutti gli anni '80 e parte dei '90. SVN raccoglieva l'eredita` di CVS, ed oggi git e` praticamente uno standard.
 
Io ho iniziato a usare SVN (e Tortoise) nel 2008. Prima non se ne sentiva la necessità - sto dicendo che era profondamente sbagliato, però quello era, almeno dove e con chi lavoravo io, l'andazzo.
 
Devo peraltro dire che con SVN non mi son mai trovato particolarmente bene. Mentre GIT... beh, ci ho messo un po' a capirlo, ma alla fine l'epifania è arrivata, ed è un altro pianeta.
 
-- 
Ciao!
Luca

 sono quelli che scrivono software in quei posti.
 
Meglio per te evitare di entrare in contatto con entità/soggetti simili...
Ti potrebbero far venire un esaurimento nervoso :-D
 
 

Prima non se ne sentiva la necessità 
 
Non se ne sentiva la necessita`, chi? *TU*, forse. Ecco: "dove e con chi lavoravi tu". Non lavorare con un vcs prima del 2008 era da folli.

 Meglio per te evitare di entrare in contatto con entità/soggetti simili...
 
Non ho detto che non ci sono mai entrato in contatto. Ho detto che non ci ho mai lavorato dentro. E` diverso.

 Non lavorare con un vcs prima del 2008 era da folli.
 
Io credo che l'eventuale quantità di follia dipendesse dal numero di persone che ci lavorano e dai possibili fork di un progetto. E anche dal progetto stesso.
 
Se a) lavori su un progetto da solo, b) il progetto è una commessa (si chiude su se stesso e a tempo determinato) la follia si riduca a una maledettamente enorme scomodità.
 
Ciò detto, oggi, proprio perché è maledettamente comodo, anche nel caso in cui sono da solo, un eventuale bel repository su BitBucket (se non ne uso uno già presente) e passa la paura!
 
-- 
Ciao!
Luca
 

 Io credo che l'eventuale quantità di follia dipendesse dal numero di persone che ci lavorano e dai possibili fork di un progetto. E anche dal progetto stesso.
 
No.
Il numero di persone e gli eventuali fork sono totalmente irrilevanti ai fini della gestione di un progetto con un vcs. Un vcs e` utile ad un gruppo come ad uno solo: nessuna differenza. Se lavori su un progetto da solo, hai ugualmente bisogno di un repository per i sorgenti, dove sei sicuro di poter recuperare qualcosa se fai uno sbaglio, dove eventualmente puoi creare un feature branch per testare uno sviluppo in parallelo, dove puoi "taggare" una release. Usare un vcs non e` *MAI* scomodo ed e` *SEMPRE* utile. I vcs non sono mai stati maledettamente scomodi. Questa e` la solita resistenza di chi e` troppo pigro per seguire le best practices, e a cui sta bene lavorare alla cazzo di cane.

 Usare un vcs non e` *MAI* scomodo ed e` *SEMPRE* utile. I vcs non sono mai stati maledettamente scomodi. 
 
Guarda che hai capito il contrario di quel che ho scritto (mi sono riletto, per sicurezza).
 
-- 
Ciao!
Luca
 

 Guarda che hai capito il contrario di quel che ho scritto
 
Se affermi "l'eventuale quantità di follia dipendesse dal numero di persone che ci lavorano e dai possibili fork di un progetto", stai affermando che, innanzitutto, la follia e` eventuale (e non lo e`), e che usare un vcs e` piu` o meno folle, dipendentemente dal numero di persone che lavorano sul progetto, i possibili fork e il progetto. A questo ho risposto. Se poi volevi dire un'altra cosa, e` un altro discorso.
 

 e la richiesta non passò...
 
opposizione da parte di chi, del fornitore? immagino che l'opposizione 
fosse per non mettere i sorgenti a casa vostra, non sotto vcs.
non conosco nessuna azienda di software, piccola o grande che sia, che 
non ne faccia uso, ne francamente riesco nemmeno ad immaginarmela.


perchè sei sempre così incazzato ?
 
-- 
Soprano

 perchè sei sempre così incazzato ?
 
Ma io non sono affatto incazzato. Se ti metto una faccina :) sei piu` felice?


si, grazie
 
-- 
Soprano

 non ne faccia uso, ne francamente riesco nemmeno ad immaginarmela.
 
Neanche io, onestamente. Non riesco proprio a immaginare come si possa lavorare su un progetto mediamente complesso, senza un vcs. Io ho lavorato in aziende in cui gli sviluppatori non avevano capito come usare CVS, e si ostinavano a zippare i sorgenti e commmittare il binario, per cui ho dovuto prenderli per un orecchio e spiegargli come stavano veramente le cose, ma almeno si sforzavano di usare un vcs, e l'azienda glielo imponeva. Queste aziende, invece, dove c'e` una qualche entita` oscura che "fa opposizione" all'uso di metodologie di lavoro e di tecnologie che costituiscono i fondamenti, mi fanno terrore. E` come se a un chirurgo venisse imposto di arrangiarsi con un coltello da cucina o ad un gommista di svitare le ruote coi denti.

Solo che 'eventuale' e 'eventuale quantità' sono cose diverse. Peraltro io DEVO contestare un'affermazione che hai fatto. 
 
Tu dici (ed è l'affermazione cui facevo riferimento):
"Usare un vcs non e` *MAI* scomodo ed e` *SEMPRE* utile."
 
Scomodità a parte (in questo caso non facevo riferimento a si vs/ no ma a alcune operazioni macchinose con svn che invece ho trovato personalmente più lineari con git), io la estremizzerei: se in taluni casi è utile (appunto quello che citavo) in altri (progetto complesso, con tanta gente che ci lavora, e che dura molto nel tempo) non è utile, è indispensabile.
 
-- 
Ciao!
Luca


io la estremizzerei: se in taluni casi è utile (appunto quello che citavo)
 >in altri (progetto complesso, con tanta gente che ci lavora, e che 
dura molto nel tempo) non è utile, è indispensabile.
 
Non esistono progetti in cui non e` utile usare un vcs. Usare un vcs e` 
*sempre* utile. Non esistono progetti in cui non e` indispensabile usare 
un vcs. Un vcs e` *sempre* indispensabile.
 
 
-- 
4ndre4
"The use of COBOL cripples the mind; its teaching should, therefore, be 
regarded as a criminal offense." (E. Dijkstra)
"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 
http://tinyurl.com/z6y6gpd
 


 
 
ma sì, ho capito!
 
Volevo solo dire che mi sembra decisamente il caso di conservare
la versione attuale.
Sono d'accordo anch'io che si debba usare un cvs.
 


 
 
ma io non ho proprio questa impressione.
In 8 anni che faccio il programmatore un po' di ambienti ne
ho visti, e solo una volta ho sviluppato un progetto senza
vcs.
 
Ma era un progetto abbastanza piccolo, e praticamente lo sviluppavo
solo io.
Quando arrivavo a un punto stabile facevo l'ear e tramite chiavetta
usb lo passavo al collega che lo installava.
 
 
Ma questo, di tutti i contesti in cui ho lavorato, è l'unico in cui
non ho visto usare un vcs.
 
E comunque solo per quel progetto, voglio dire può essere che in
quel posto di lavoro per altri progetti invece venissero usati.

 Sono d'accordo anch'io che si debba usare un cvs.
 
Perche', tu usi CVS?

 
 
 
beh git è certamente più complesso, ed è molto facile fare dei
casini, cosa che a me è successa più di una volta.
 
Ma come mai non ti trovi bene con svn? Io con svn non ho mai
avuto problemi particolari, sinora.
 

 un punto a favore di eclipse.
 
Ma quando mai.
Con IDEA hai costantemente sotto controllo la lista dei file da 
committare e le differenze col repository:
 
https://www.jetbrains.com/idea/help/version-control.html
 


 
 
 
la lista dei file da committare lo so, infatti c'è una sezione apposta
che ti elenca tutti i files che devi committare con la possibilità
di vedere le differenze.
 
 
Però sinora non ho trovato la funzionalità inversa, cioè una sezione
in cui puoi vedere i files da aggiornare, cioè di cui puoi
fare update, con possibilità di vedere le differenze per ogni
singolo file, cosa che invece con eclipse ho visto.
 
Comunque se anche con idea si può fare tanto meglio, la prossima
volta che lo userò cercherò di capire dov'è quella funzionalità,
che è così comoda.
 
 
Ah, io parlo della versione free di idea, non di quella a pagamento.
 


 
 
sinceramente non si direbbe, dai toni che spesso usi nelle discussioni.
 
 

 un vcs. Un vcs e` *sempre* indispensabile.
 
"sempre utile" e "sempre indispensabile" secondo me sono degli overstatement, e' indispensabile per chi produce software con vita lunga, per software sperimentali che hanno vita molto breve sono spesso un impiccio.
 
Ad esempio, per alcuni miei progetti (quelli molto sperimentali e di sviluppo algoritmico) non uso un vcs, anzi mi sarebbe inutile/controproducente. 
Per questi progetti il prodotto finale e' una sequenza di formule, una spiegazione del perche' funzionano, e i dettagli dell'approccio di discretizzatione usato. Il vcs e' semplicemente un lab-book con date, formule, stampe dei risultati e appendici generate con doxygen e compilate in LaTeX. Per evitare errori sistematici capita spesso di riscrive il codice da zero, partendo dalle formule, che vengono prese dalla documentazione del lab-book. Nelle fasi finali, e' un co-autore a riscrivere il tutto, partendo dal draft dell'articolo in preparazione. Ovvio che una volta pubblicato l'algoritmo l'implementazione verra' distribuita e mantenuta con vcs, ma nelle fasi intermedie dipende sempre dal tipo di lavoro che c'e' dietro.

 Ah, io parlo della versione free di idea, non di quella a pagamento.
 
E` uguale.


software sperimentali che hanno vita molto breve sono spesso un impiccio.
 
Io parlo di progetti, non di software sperimentali.


 sinceramente non si direbbe, dai toni che spesso usi nelle discussioni.
 
Perche` qui dentro si dicono un mare di cagate. Ci vuole la pazienza di 
Giacobbe.



...anzi Giobbe. Giacobbe era un altro.


 Io parlo di progetti, non di software sperimentali.
 
A vita breve, ad alto rischio, ma pur sempre progetti, che hanno bisogno di pianificazione, implementazione, testing, analisi e documentazione dei risultati. Certo, son parte di progetti piu' grossi, la cui componente informatica e' solo una frazione, e quella software una sottofrazione (anch'essa sperimentale, ma ovviamente mantenuta con cvn). Era solo per sottolineare che ad essere troppo rigidi con le categorizzazioni si rischia di considerare solo l'erba del proprio orto, tutto qui.

Secondo me sei tu che stai guardando solo al tuo orto. Per qualche strana ragione, ogni qual volta si discute qual è il metodo migliore per fare certe cose, c'è sempre qualcuno che esordisce dicendo che "no, io sono l'eccezione, il caso speciale, la best practice nel mio caso non si può applicare". Per qualunque tipo di progetto, fosse anche sperimentale, l'uso di un vcs è utile (non capisco come possa mai essere controproducente) non fosse altro perché tiene una storia del sorgenti che può tornarti utile in qualunque momento. Con un sistema come Intellij IDEA, ad esempio, l'integrazione con il vcs è del tutto trasparente. Non devi fare nulla di particolare. Lavori come lavoreresti senza vcs e committi le tue changelist sul repository. I progetti di cui parlo io, comunque, quando dico che un vcs è sempre utile, sono quelli che rispondono alla definizione di progetto più classica, ovvero un sistema software potenzialmente sviluppato in team e che deve essere mantenuto rilasciato nel tempo. Un sistema del genere, senza vcs non si può mettere in piedi.

 Ma che stai dicendo? Ma sei serio? I vcs si usano da almeno 40 anni!
 
"Si usano" e' impersonale (non c'e' un soggetto definito).
 
Io ti posso dire senza tema di smentite che in Ericsson 
Italia(soggetto), sede di Roma, nel 2001-2002 non si usava una mazza,
ne' come VCS ne' per il Configuration Management.
No so se in qualche divisione usassero qualcosa, in quella
dove ero io sicuramente no. Hanno iniziato ad usare qualcosa
per il Configuration Management nel 2003 (clearcase se non ricordo male) 
ma il primo progetto a cui ho lavorato e per il quale
era richiesto un VCS (Subversion) e' stato nel 2006 (esattamente 10 anni 
fa). Dopo non so comme hanno proseguito perche' nel 2007 ho cambiato lavoro.
 
Ciao,
Marco.
 
 
 
 
 
 
 

 si può mettere in piedi.
 
e qui non posso che quotare.

 Ah, io parlo della versione free di idea, non di quella a pagamento.
 
Oh bella, esiste una versione free?
Per PyCharm esiste una versione Community, dedicata ai progetti OS, e le versioni a pagamento. Per Idea è diverso?
 
-- 
Ciao!
Luca

 Giacobbe.
 
A parte che è Giobbe e non Giacobbe, permettimi una critica costruttiva: est modus in rebus. Rilevi qualcuno che ha detto una cosa non corretta? c'è modo di dire le stesse cose, anche con la stessa efficacia, se non maggiore, senza iniziare a insultare a destra e a manca. In fondo, nessuno di noi è assoluto depositario della verità.
 
-- 
Ciao!
Luca

 I progetti di cui parlo io, comunque, quando dico che un vcs è sempre utile, sono quelli che rispondono alla definizione di progetto più classica, ovvero un sistema software potenzialmente sviluppato in team e che deve essere mantenuto rilasciato nel tempo. 
 
Ci ho lavorato molto ad inizio carriera, e devo dirlo, mi manca molto quel mondo. Oggi lavoro molto su commessa, con le commesse che hanno termine e che magari riprendi in mano, anche dopo anni. E' comunque utile un bel repository e un sistema CVS? si, perché hai le cose li e quando ti serve puoi andartele a prendere. Ti ci devi legare troppo? no, comunque, a fine commessa, un bel backup, che se per caso ti chiudono un Google Code a caso (avevo parecchia roba li) il trasferimento di corsa può essere non così trasparente.
 
-- 
Ciao!
Luca

 non ne faccia uso, ne francamente riesco nemmeno ad immaginarmela.
 
Purtroppo per me ne ho viste diverse e non delle più piccole purtroppo.
Devo anche dire che ne ho viste anche diverse usare mono branch, in pratica semplicemente per avere uno storico dei sorgenti ed anche quello fu difficile farlo digerire. 
 
Veniva percepito dalla dirigenza come "inutile complicazione" oppure "cosa da fighetti informatici".
 
Oggi come oggi conosco una sola SW di discrete dimensioni che si rifiuta ostinatamente di usarlo.
 
Ciao
  Francesco

 Son d'accordo sul fatto che sia indispensabile anche per progetti sperimentali. Però per progetti a vita breve può essere d'impiccio. E' d'impiccio perché se una cosa funziona e merita di essere archiviata la riscrivo (o la faccio riscrivere) per bene (partendo dalle formule, non dal codice vecchio) e la inglobo nel progetto più grosso, se non funziona viene archiviata in directory che molto probabilmente non verranno mai più aperte, ed è d'impiccio avercele tra i piedi. Per di più da noi esperimenti computazionali non possono essere memorizzati (fisicamente) fuori dal centro di calcolo (pena fustigazione in sala mensa), che me frega di mantenere un vcs di spazzatura?
 
Ma non devi mantenere proprio un bel niente. Con git e mercurial hai una cartella .hg (Mercurial) locale interna al progetto dove e' contenuto tutto lo storico. Che impiccio dovrebbe dare scusa? Al peggio non la usi.

 inutile/controproducente.
 
impiccio perché non sai bene di cosa parli (intendo dei vcs, sia chiaro).
 
da tanti anni ormai esistono i vcs distribuiti, impatto sull'operatività
pari a zero. poi se i co-autori ritengono più opportuno essere svincolati
e non avere un repository centralizzato possono farlo, ciò non toglie che
il versionamento costa zero.
sull'opportunità tout court di versionare sorgenti/documenti francamente 
mi pare ci sia ben poco da discutere.

 Devo anche dire che ne ho viste anche diverse usare mono branch, in pratica semplicemente per avere uno storico dei sorgenti ed anche quello fu difficile farlo digerire. 
 
E` il trunk. Non e` sbagliato lavorare su trunk per quanto possibile, e fare branch solo se strettamente necessario. I branch sono utilissimi, ma un numero anche limitato di essi puo` causare bei mal di testa.

 Ma non devi mantenere proprio un bel niente. Con git e mercurial hai una cartella .hg (Mercurial) locale interna al progetto dove e' contenuto tutto lo storico. Che impiccio dovrebbe dare scusa? Al peggio non la usi.
 
Infatti, non l'ho capito neanche io. Di fatto, con qualunque VCS lavori come lavoreresti senza. Le differenze col repository vengono scoperte in automatico. L'impiccio dove sarebbe, committare? Bah. Non capisco.
 

On Friday, 26 February 2016 03:56:23 UTC, askaholik  wrote:
 
[...]Però per progetti a vita breve può essere d'impiccio. E' d'impiccio perché se una cosa funziona e merita di essere archiviata la riscrivo (o la faccio riscrivere) per bene (partendo dalle formule, non dal codice vecchio) e la inglobo nel progetto più grosso, se non funziona viene archiviata in directory che molto probabilmente non verranno mai più aperte, ed è d'impiccio avercele tra i piedi.
 
Non mi hai convinto.

permettimi una critica costruttiva: est modus in rebus. Rilevi qualcuno che ha detto una cosa non corretta? 
 
permettimi una critica costruttiva (non a te, ma a tutti coloro che, qui dentro aprono spesso bocca per dire cagate): rilevi qualcuno che ti ha fatto presente che hai detto una cosa non corretta/illogica? Anziche` arrampicarti sugli specchi all'infinito, per difendere la cagata che hai detto, facendo di fatto la figura dell'idiota, comincia a pensare.

 Per PyCharm esiste una versione Community, dedicata ai progetti OS, e le versioni a pagamento. Per Idea è diverso?
 
E` la versione community.

 "Si usano" e' impersonale (non c'e' un soggetto definito).
 
"Si usano" significa che sono in giro da piu` di 40 anni.

 dei risultati. 
 
e quali sono le spiegazioni per cui dei progetti con queste 
caratteristiche non avrebbero bisogno di avere le revisioni delle 
modifiche?
 
 
 

Ti ci devi legare troppo?
 
Questa domanda non ha senso.


Eh, ma la versione Community è appunto per 'community'...
 
-- 
Ciao!
Luca

 rilevi qualcuno che ti ha fatto presente che hai detto una cosa non corretta/illogica? 
 
Il problema, vedi - e qui non sto parlando di te ma di altri personaggi del passato - è che c'è stata diversa gente che ha sparato cazzate a randa propalandole per verità di fede. Per cui devi capire, si parte sempre un po' prevenuti.
 
Detto questo, non so tu, io ho capito che non vale la pena di perderci tempo. Io so una cosa che tu non sai o sai male? ti dico come stanno le cose, poi decidi tu che peso darci. End of story.
 
-- 
Ciao!
Luca
 

 Eh, ma la versione Community è appunto per 'community'...
 
#include "giobbe.h"
 
Si tratta della versione che scarichi gratuitamente e usi liberamente sulla tua macchina. E` questo quello a cui si riferisce kojak. 
 

Si parte prevenuti.
 
E` un problema vostro.