Migliaia di errori!

Sembra che tu stia confondendo parecchie cose con il termine "errori"

• attributi html legacy
• stile di codifica
• errori di codifica che non causano errori
• bug non segnalati
• errori che ora sono funzionalità
• bug segnalati
• segnalati bug che ti sono stati assegnati per la correzione

Su un'app legacy che verrà sostituita, solo uno di questi tipi di errore dovrebbe interessarti. L'ultimo.

Mi spingerei fino a dire che non dovresti nemmeno rifattorizzare altre cose su una funzione che stai correggendo, principalmente a causa di:

• errori che ora sono funzionalità

Puoi vedere dal codice come avrebbe dovuto funzionare, ma non l'ha mai fatto, ma tutti gli utenti sono andati d'accordo con l'elemento di larghezza indeterminata negli ultimi 10 anni e non ti ringrazieranno per averlo corretto.

Per quanto riguarda i lati positivi, se metti la tua testa JFDI cinica, sarai in grado di masterizzare i bug in modo super veloce e il nuovo team di versioni non sarà in grado di tenere il passo con le vecchie funzionalità delle versioni.

Questo ti darà un sorriso ironico e ironico mentre raccomandi un emulatore chrome ie6 emulator ai client in modo che possano continuare a utilizzare la "feature" di selezione che amano

Ciò che chiedi non è una domanda tecnica, e nessuno qui può rispondere.

Stai lavorando su un software in modalità di manutenzione e osservi la tecnologia fuori moda e un gran numero di imperfezioni e incongruenze. Chiedi a cosa fare. Dovresti ad esempio allungare gli sforzi per renderlo compatibile con browser? Dovresti portarlo in linea con gli standard moderni? Dovresti correggere le incoerenze sintattiche nell'app? Il fatto è che queste sono decisioni aziendali . Dovresti chiedere al tuo manager o al proprietario del prodotto quali problemi vogliono che tu risolva e quali sono le loro priorità. Poiché esiste già un progetto in corso per riscrivere l'app, la gestione è probabilmente già a conoscenza dei problemi che osservi.

Se l'app verrà sostituita completamente nel giro di pochi mesi, è probabile che vogliono solo che risolvi specifici problemi critici e lasci da solo il resto del pasticcio. Ma non lo sappiamo.

Chiedete se è possibile eseguire operazioni di ricerca e sostituzione lungo la base di codice, modificando migliaia di file. Certo che puoi. La domanda è se dovrebbe . Tali cambiamenti radicali richiederanno probabilmente test approfonditi per garantire che nulla si sia rotto. Anche in questo caso è una decisione aziendale se i benefici superano i costi in termini di tempo e rischio.

Quando l'applicazione verrà sostituita tra 18 e 24 settimane (aggiungendo i ritardi previsti alla settimana da 6 a 8 stimata sopra presentata), allora è davvero necessario chiedersi quale valore si aggiunge al business investendo ancora una quantità considerevole di lavoro nella vecchia versione.

Certo, quando sarai bloccato a supportare l'applicazione per molti anni a venire, allora liberarti del debito tecnico può valerne la pena a lungo termine. Ma quando tutto andrà a finire comunque, perché preoccuparsi? Basta aggiungere un'altra correzione di hackish in aggiunta a tutte le altre correzioni di hacking per riparare qualsiasi problema semplicemente non può attendere il rilascio della nuova versione e chiamarla un giorno.

Potresti anche chiederti cosa puoi fare per l'applicazione nella piccola vita che è rimasta. Quando sei veramente annoiato e semplicemente non hai niente di meglio da fare con il tuo tempo, potresti dargli una grande revisione e rimuovere tutti i problemi di stile che hai menzionato, ma è molto probabile che ciò sarà inizialmente rompere più cose di quanto non risolverà. Potresti essere in grado di sbarazzarti di questi nuovi problemi alla fine con un tempo sufficiente, ma non hai quel tempo.

Motivi per NON apportare grandi cambiamenti:

Uno: il codice sta andando via tra qualche mese. Varrà davvero il tempo della compagnia per te di passare 5 mesi a sistemare un sistema che verrà poi gettato via 1 mese dopo? Avvertenza: raramente i sistemi vanno via quando sono in programma di andare via. Il sistema di sostituzione è quasi sempre in ritardo, ci sono utenti che non possono eseguire l'aggiornamento per qualsiasi motivo, ecc. Ma questo è un problema complesso.

Due: se si apportano molte modifiche, in particolare la ricerca di massa e le sostituzioni, si introdurranno bug. Non potresti introdurre bug: lo farai. Supponiamo che tu abbia fatto un S & R e cambiato "width = 200" in "width: 200px". C'è codice C # o VB sui tuoi punti ASP? Perché se avessi una variabile chiamata "width" che avevi impostato a 200, l'hai appena interrotta. (O per quello, hai pensato di limitare le pagine S & R alle pagine ASP?) O se hai cambiato "width: 200" in "width: 200px", cosa succede se nel codice c'era un posto che diceva "width" : 200mm "? Ora dice "larghezza: 200pxmm". Ok, supponiamo che tu abbia pensato a quelli. Che cosa succede se c'è un posto che ha la specifica di larghezza non valida, che è ovviamente ignorata, e ora si stende abbastanza bene. Si "aggiusta" la larghezza e ora si espande con 200px ... e il display è rovinato, perché 200px è in realtà la larghezza sbagliata da dare e ha funzionato solo perché quel valore è stato ignorato? I Mass S & R sono molto pericolosi, perché quasi sicuramente non stai studiando in ogni posto che cambi. Probabilmente non sei nemmeno sicuro di cosa testare.

Tre: il codice che è "ovviamente" sbagliato potrebbe in effetti essere ciò che l'utente desidera. Ho visto un sacco di specifiche sui requisiti che richiedono un comportamento che è ovviamente sbagliato e folle ... e poi torno agli utenti e chiedo cosa vogliono VERAMENTE, e si scopre che vogliono davvero questo comportamento folle, perché quello è come funziona il loro business o che i regolamenti governativi lo richiedono o altro.

Anche se il comportamento è veramente sbagliato, forse gli utenti se lo aspettano e lavorano sistematicamente attorno a esso, e risolvendolo, si rompono i loro metodi alternativi. Esempio: lavoro su un sistema in cui abbiamo un luogo in cui si specifichino da e attraverso date in cui una vendita è disponibile al pubblico. Entrambe le date erano davvero la mezzanotte che iniziò quel giorno, quindi se hai detto "fino al 30 luglio" significava che si concludeva con la fine del giorno il 29 luglio, cioè un minuto prima delle 12:01 del 30 luglio, non la fine del 30 luglio A un certo punto l'ho risolto, ma potevo farlo solo perché c'erano meno di una mezza dozzina di persone con autorità per usare quello schermo, e potevo semplicemente dire loro che avevo sistemato tutto. Se ci fossero centinaia di utenti, e ormai tutti avevano capito che dovevi dare il giorno successivo alla data di scadenza, allora il mio "aggiustamento" lo avrebbe rotto per tutte queste persone.

I can of course do a global find and replace to get most of the issues out of the way, but that would mean my first commit would consist of thousands of changed .asp files. Can I do that?

Non vedo perché no. Un commit dovrebbe essere concettualmente una cosa, ma non vedo alcuna ragione per cui una ricerca globale e la sostituzione da style="width=20" a style="width: 20px" non contano come "una cosa", concettualmente. E se ti aiuterebbe a dormire meglio, a meno di non essere distratto mentre aggiusti altre cose, e non muck niente di niente , perché no?

Il tuo problema è priorità di impostazione : quali sono i problemi di showstopper (in produzione)? Che stanno spuntando bombe a orologeria? E che può essere lasciato un po 'più a lungo (perché funziona e lo ha fatto per anni, anche ordinariamente)?

Quello che farei nella tua situazione è creare elenchi di problemi classi che vorrei esaminare. Ad esempio, sostituendo style="width=(\d+)" con style="width: px" (che può probabilmente essere corretto con un find / replace globale usando regexp - scusa se il mio non è 100%) sarebbe una classe, e se c'è solo una ricorrenza, così sia. Per ogni categoria elencare una priorità (quanto è urgente farlo) e una stima del lavoro (quanto tempo ci vorrà per fare questa categoria).

Le tue attività di manutenzione saranno incluse in questo elenco. Ora stai iniziando ad applicare un po 'di gestione, anche se solo a te stesso, e hai uno strumento da usare quando hai tempo a disposizione e nulla da fare, o quando devi negoziare con il tuo manager sul lavoro da fare (o richiedere tempo da dedicare a qualcosa di cui potrebbe non essere a conoscenza). (Questo tipo di proattività potrebbe aiutarti a farti notare per le promozioni, se fatto bene.)

Immagino che ti piaccia programmare perché hai una certa personalità perfezionista in una certa misura. MA in un ambiente commerciale, devi iniziare a capire che il nemico perfetto è il bene (e un buon guadagno in denaro, perfetto potrebbe non necessariamente aumentare notevolmente per un lavoro molto più completo). Prima fai ciò che è necessario, quindi fai ciò che è bello avere. Sì, questo potrebbe andare contro il tuo grano senza fine. Basta sorridere e sopportare, e forse ottenere un hobby per esercitare il perfezionismo e mantenere sano di mente; -)