è lo scenario che mi son trovato davanti quando sono entrato nell'azienda in cui lavoro...sono stato giorni a passare da un file all'altro cercando di ricostruirmi una mappa mentale delle varie inclusioni...ma erano tutti in una sola cartella (argh!!) e forse in numero inferiore alla tua infinita schiera

@demon3
E cosa hai fatto? Cioè immagino che adesso riesci ad apportare modifiche senza perdere più troppo tempo, giusto?

considera che il mio incarico era "sistemare una lista di bug"...quindi mentre cercavo di capire dove nascesse il bug, cercavo di farmi anche tale mappa mentale. Dopo 1-2 settimane riuscivo a muovermi abbastanza bene (a meno che non mi capitasse di dover mettere mano a qualcosa di nuovo e sconosciuto, ovvio) e, dopo un anno, ho avuto la possibilità di radere tutto al suolo e di riscriverlo da 0 ^^

...ora si che si ragiona =D

...i file sono sempre tanti (ma divisi tra frontend, backend, css, javascript, etc) e la documentazione (mea culpa) è sempre pari a 0, ma i nomi sono "autoreferenziali" e non esistono "doppioni" (prima c'era la bruttissima usanza di lasciare il vecchio file sul server, nella stessa cartella del nuovo, ma cambiandogli il nome...e magari a volte ci ripensavano ed usavano il vecchio, lasciando il nuovo a far confusione...insomma, il chaos!!!)

Purtroppo hai poco da fare, se devi studiarla e nun ce sta documentazione adeguata ti ci devi mettere con tanta pazienza e capirla.

Dopo un po come ha detto @demon3 inizi a districarti nella logica di chi l'ha fatta prima di te e quindi le cose cominciano ad esser più semplici.

il problema è che per entrare nella mente dell'assassino devi diventare come lui =D

A quanto ho capito, qui è coinvolta un'intera associazione a delinquere

ovvio

Grazie Vinc
Mi sono duplicato il codice e sto pian piano attraversando lo stack aggiungendo commenti qui e là

come ti hanno detto gli altri è un lavoro di m*erd*
IO solitamente trovo molto utile rimappare il tutto via UML in modo tale da avere una chiara visione delle dipendenze.

Mi è capitato moltissime volte, applicazioni che andavano vanti da anni, migliaia di file di codice (programmazione batch o a eventi), anche su ambienti (Remedy) che non conoscevo affatto.
Rimboccata le maniche, speso ore e ore a studiare i codici e capire come collegarli (su Remedy soprattutto non c'è neanche un bastardo di debug e non c'è collegamento alcuno tra le maschere).
Poi pedalare, pedalare, perché tanto ti mettono a lavorarci sopra e non puoi dire "un moment, so' arrivato ieri".
Personalmente mi ha salvato la memoria e la cazzimma, non avevo neanche il tempo per fare le mappe, solo in testa

Ah, e soprattutto, individuato chi dei colleghi potesse saperne di più, arruffianato e ottenuto consigli e collaborazione. Provvidenziale la pausa caffè

Vedo solo ora. Quando capita, lancio Doxygen su tutti i sorgenti e mi faccio generare tutto quello che riesce a capire e trovare nel codice: trovo i diagrammi con le dipendenze - anche in stile UML (via dot) - e gli hyperlink nei file generati veramente ottimi per capire come funziona un progetto.

Il trucco è generalmente utile con qualunque codice di terze parti, ma Doxygen semplicemente spacca quando si affronta l'ignoto e per giunta caotico.

Poi refactoring per gradi, provando via via a raggruppare codice in un numero più contenuto e malleabile di file, se possibile. Nel refactoring includo anche un'operazione per uniformare lo stile: nulla di più difficile che comprendere codice "variegato".

Indi si riparte con Doxygen...

PS: ti/vi serve un post?

Grazie a tutti per il sostegno e per i consigli

Ho cominciato dal Db e pian piano mi sto rimappando tutto, lasciando anche un po' di documentazione a chi ci sarà dopo di me.

@rejected i tuoi post sono sempre illuminanti: certo che mi serve!!

Ma secondo voi suggerire una riscrittura in parallelo (avendo le risorse) di un software che funziona per opera e virtù di un'entità superiore è un'idea totalmente malsana? (Joel Spolsky mi ucciderà, lo so)

se hai tempo ovviamente si ...

@JustB: Spolsky rulez, anche in questo caso...

L'unico modo per rifare un qualcosa è avere chiaro cosa faceva quello precedente. A parte che, come dice Spolsky, non è garantito che il nuovo tentativo riesca meglio del precedente, ma se poi il codice da rifare è di terzi...

Come rifare e meglio qualcosa che non è neppure stato compreso?

Uhm non sono completamente d'accordo.
Se io so che bisogna fare A ma i terzi, per fare A, sono passati per B,C,D,E ed F (essendo queste ultime operazioni non necessarie) allora la riscrittura è un modo per semplificare, non trovi?

Se sei in grado di capire che invece di fare A sono passati da B,C,D,E allora significa che hai compreso il lavoro tortuoso fatto da A e allora puoi pensare di rifarlo... Il principio non è il rifare per il gusto di rifare, ma rifare perchè non c'è altra alternativa, dopo averla debitamente compresa. Non mi pare che siamo in disaccordo, o sbaglio? o_O

Muhuahauhau scusa @rejected sto troppo fuso oggi
Hai ragione, siamo d'accordo

ma figurati!

@justb: pronto e schedulato per domani.

Chissà se @castle conosce Selenium

Mai visto, interessante...

@justb lo conosco ma ammetto di non averlo mai provato. Quando ne ho avuto bisogno ho usato con successo la 'combo' WatIn+NUnit.