Manutenere codice altrui

di il
7 risposte

Manutenere codice altrui

Ciao ragazzi,
ho bisogno di un parere.
Cinque mesi fa il mio datore di lavoro, mi chiede di trasferire una sito manutenuto da una web agency su il nostro server. In pratica passaggio di consegna.
Conoscendolo, gli ho chiesto ma in cosa consiste la gestione e lui mi risponde che bisognerebbe ogni tanto modificare la home del sito ma niente di chè.
A questo punto confermo che si può fare e si procede con il trasferimento.
E qui iniziano le danze:
Dall'altra parte (ovvero chi mi cede il codice) non trovo una persona molto disponibile, il trasferimento da durare 1 giorno è durato 2 settimane, sono intervenuto persino sul codice in quanto non funzionava, tutto il backoffice del sito, senza uno stralcio di documentazione e nemmeno commenti nel codice. Dopo aver sbattuto la testa per settimane, il sw ha cominciato a rifunzionare.
Ma ieri dopo 1 mese di silenzio mi arriva l'ennesima notifica di malfunzionamento, a questo punto il datore di lavoro viene da me e dice: "bisogna trovare una soluzione in quanto ci sta mettendo la faccia con questi clienti".
A questo punto io non so più che fare. Posso pensare che i tizi che hanno ceduto il codice abbiano volutamente non trasferito parti di codici? Non lo so. Ma non è normale che il sw non funzioni più dall'oggi al domani.

So soltanto che ho due alternative:
- rimettermi a manutenere questo codice perdendo molto ma molto tempo in quanto non conosco il sistema.
- cedere la gestione a terze persone, oppure rifarlo da zero.

Resta il fatto che da questa esperienza sono rimasto scottato e prima di accettare codice altrui ci pensero due volte.

A tal proposito vi è capitato di manutenere codice altrui?
Come vi siete comportati?

Vi Ringrazio.

7 Risposte

  • Re: Manutenere codice altrui

    Rispondo per solidarietà... certo che più di questo nel Forum non potrai avere...
    Io scrivo codice da 25anni, ho iniziato con ASM(Z80), passato al VB6/VBA...(oggi sono stanco e non faccio più nulla... ), nel tempo mi è capitato di vedere un pò di tutto, ma l'unica cosa che ho sempre evitato è stata quella di LAVORARE su progetti fatti da altri.
    Lo sviluppo ha regole concettuali molto rigide, ed i programmatori seri(non quelli improvvisati) con una base tecnica concreta applicano regole e concetti di sviluppo.
    Negli ultimi 10÷15 anni tuttavia si sono inseriti nel processo di produzione del SW, gli appassionati di ufficio che scoprendo le applicazioni Office, si sono resi contro di riuscire a produrre "COSE" funzionanti.
    Il Dramma è che molti hanno creduto di essere PROGRAMMATORI.
    Per tutta la buona volontà(ed è tantissima) molti di questi appassionati non hanno i concetti solidi della programmazione a partire dall'ingegneria di un Database, fino ai più concreti concetti OOP di Polimorfismo ed Ereditarietà.
    Giustamente si sono ritagliati fette di mercato LOWCost che hanno portato avanti.

    Quando mi è capitato di ricevere richieste di MODIFICHE su SW Gestionali, definiti FUNZIONANTI mi sono ricreduto sulle mie capacità di ANALISI del SW.
    Il SW scritto da chi non comprende le basi della scrittura del Codice è oltre che poco comprensibile, poco DEBUGGABILE, poco LOGICO, poco FUNZIONALE, spesso inutilmente ridondante, privo dell'uso delle CONVENZIONI.
    In sostanza non è strutturato, ma accrocchiando funzionicchia...
    Senza sminuire nessuno, la mia scelta è stata di non prendere MAI in carico lavoro di altri.

    Detta così, a parte essere mandato a spigolare da molti dei lettori, uno dice... "Se puoi scegliere fai bene...ma..." ovviamente...
    In caso di impossibilità di scegliere purtroppo si fanno passi Formali di consegna con COMMISSIONING del prodotto verbalizzando tutto, in particolare le ANOMALIE o BUGS.
    Si definisce per ogni Segnalazione chi fa cosa ed in che tempi, oppure si va a decurtare in accordo la quota economica ritenuta necessaria alla sistemazione.
    Ovviamente questo è precauzionale per chi prende in carico lavoro di altri e tanto più un tecnico che fa COMMISSIONING di SW è esperto tanto meno sorprese finali si trova.

    Per il resto buon lavoro e non scoraggiarti.
  • Re: Manutenere codice altrui

    Ti ringrazio Alex ci hai azzeccato a pieno, opero ogni giorno con persone che adottano la pratica dell'accrocchio non rendendosi conto che sono sempre li a sviluppare le stesse cose. Pura programmazione a spaghetti.

    Per quanto riguarda i passi Formali di consegna con COMMISSIONING del prodotto, ci sono libri o corsi di formazione professionale a riguardo?

    Grazie
  • Re: Manutenere codice altrui

    @Alex ha scritto:


    Rispondo per solidarietà... certo che più di questo nel Forum non potrai avere...
    Io scrivo codice da 25anni, ho iniziato con ASM(Z80),
    Ooh ... lo Z80! Che bei ricordi!

    tldeveloper ha scritto:


    Dall'altra parte (ovvero chi mi cede il codice) non trovo una persona molto disponibile.
    Guarda, il tuo padrone avrà fatto girare le balle a quelli dell' agenzia, o non pagando o con pretese assurde o altro.

    tldeveloper ha scritto:


    So soltanto che ho due alternative:
    - rimettermi a manutenere questo codice perdendo molto ma molto tempo in quanto non conosco il sistema.
    - cedere la gestione a terze persone, oppure rifarlo da zero.
    Comincerei con lo stabilire se il codice è scritto bene o sè un brutto codice.
    Se il codice è buono ed è pure un lavoro impegnativo conviene tenerlo. In questo caso potreste chiedere a chi l' ha fatto di fare un corretto passaggio di consegne e un periodo di manutenzione, ovviamente a pagamento (la causa di tutti i problemi è sempre questa )

    Se il codice è brutto rifatelo.

    Comunque pure io in linea di principio evitò di mettere mano al codice altrui, se lo faccio, preventivo una grande dose di tempo e pazienza.

    Buon lavoro.
  • Re: Manutenere codice altrui

    barba59 ha scritto:


    @Alex ha scritto:


    Rispondo per solidarietà... certo che più di questo nel Forum non potrai avere...
    Io scrivo codice da 25anni, ho iniziato con ASM(Z80),
    Ooh ... lo Z80! Che bei ricordi!
    ...
    A chi lo dici... preferivo il 6502 per i miei giochetti, ma lavorativamente parlando l'automazione industriale anni 80÷90 era tutta a z80... meno male che ora lavoro con prodotti nuovi
  • Re: Manutenere codice altrui

    tldeveloper ha scritto:


    ....
    Per quanto riguarda i passi Formali di consegna con COMMISSIONING del prodotto, ci sono libri o corsi di formazione professionale a riguardo?
    Grazie
    Corsi di formazione non saprei, di solito il tutto viene inquadrato nel PCQ del lavoro ovvero il PIANO di CONTROLLO QUALITA'.
    Questo documento, semplificando i concetti, redatto da chi prende il lavoro(appaltatore) ma approvato dal committente, definisce "Chi fa cosa, come ed in che tempi".
    Aziende mediostrutturate applicano procedure più o meno complesse per gestire la parte di scambio.
    Il tutto chiaramente viene inquadrato da persone che abitualmente lavorano in regime di Qualità e spesso Certificata.

    Purtroppo questi processi mal si addicono a produzioni "artigianali" che per forza di cose sono gestite a livelli differenti soprattutto per questioni di convenienza economica.

    Tuttavia credo che [barba59] possa aver centrato il problema di base... ovvero la modalità di interfaccia tra il tuo titolare, che spesso per sottostima degli oneri tende a minimizzare le cose, e la parte opposta... con conseguente FLOP.
  • Re: Manutenere codice altrui

    Infatti [barba59] ha indovinato.
    Che dire ... grazie 1000 per i consigli.
  • Re: Manutenere codice altrui

    Ciao tldeveloper, hai anche la mia solidarietà
    Quando facevo il consulente e lavoravo onsite dai clienti, mi capitava di lavorare su progetti dove c'erano passati anche più di 10 sviluppatori prima di me: senior, junior, gente alle prime armi, cani, ... di tutto insomma. Ovviamente, spesso con analisi funzionali e tecniche discordanti dal realizzato.

    Riguardo al passaggio di consegne, per esperienza consiglio di:
    a - effettuare un incontro assieme al responsabile tecnico del software per vedere come è fatto e come funziona. In questo incontro un programmatore senior si rende conto di cosa gli stanno per mettere sulle mani e sul groppone.
    b - far sottoscrivere un documento che impegna chi fornisce il software a farsi carico economicamente di risolvere gli eventuali bux che si riscontreranno nel giro di 3 mesi (chiamiamola garanzia).

    Detto questo, da quanto scrivi, la frittata ormai è fatta.
    So soltanto che ho due alternative:
    - rimettermi a manutenere questo codice perdendo molto ma molto tempo in quanto non conosco il sistema.
    - cedere la gestione a terze persone, oppure rifarlo da zero.
    Rifarlo da zero: io proverei a fare tutti i fix necessari a quanto c'è già per farlo funzionare, visto che i vostri clienti lo stanno usando. Rifarlo da zero significa far utilizzare ai vostri clienti, per tutto il tempo necessario allo sviluppo, sempre il vecchio software.

    Cedere la gestione a terze parti: dipende dall'affidabilità della terze parti, dal vostro budget, ecc.

    rimettermi a manutenere questo codice: se te la senti e se ritieni di poterne venire a capo in base alle tue capacità ed esperienze (è una valutazione che puoi fare solo tu)

    Volendo sempre in base a quanto la tua azienda vuole investire su questo sito, se è strategico e via discorrendo potreste far partire due rami di sviluppo:
    1. bug fix, pezze e tamponi per diminuire le problematiche del sito attuale
    2. Sviluppo da zero, prendendo come modello (funzionale) quello esistente.
Devi accedere o registrarti per scrivere nel forum
7 risposte