Migliaia di errori!

Sono stato assegnato a un nuovo progetto di recente. Bene, in realtà un vecchio progetto, scritto in ASP classico. Ora una nuova versione dell'applicazione è stata scritta nell'ultimo ASP.NET, ma non dovrebbe essere RTM tra un po '(la data di rilascio stimata è gennaio 2017), quindi devo eseguire un po' di manutenzione sulla vecchia applicazione fino a quando non può essere scartato.
Inoltre, ho la sensazione che non tutti i clienti passeranno immediatamente al nuovo programma, quindi questa versione probabilmente sarà disponibile per un po '.

E il problema è che è pieno di errori. Alcune parti risalgono al secolo precedente, quando non esistevano standard web e non mi dispiace davvero della modalità Quirks widthe degli heightattributi anziché CSS, tabelle utilizzate per layout, set di frame, ecc., Ma oh, tutti quegli errori! width="20px"in tutto il luogo, onchange="javascript:..."e in quei luoghi dove si fanno uso di CSS, style="width:20"e style="width=20px"sono all'ordine del giorno. Per non parlare delle linee in cui vi sono contraddittori widthe styleattributi. Ecc. Ecc.
Di conseguenza, l'applicazione Web funziona solo con IE e solo in modalità compatibilità. È chiaro che gli sviluppatori non hanno mai esaminato la validità del codice, solo se ciò che è uscito sembrava quello che avevano in mente dovrebbe apparire.

E non so come gestirlo. Trovo impossibile chiudere gli occhi su quegli errori mentre cerco nel codice altri errori.
Ovviamente posso fare una ricerca e sostituzione globale per rimuovere la maggior parte dei problemi, ma ciò significherebbe che il mio primo commit consisterebbe in migliaia di file ASP modificati. Posso farlo?

Sembra che tu stia confondendo diverse cose nel termine "errori"

• attributi html legacy
• stile di codifica
• errori di codifica che non causano bug
• bug non segnalati
• errori che ora sono caratteristiche
• bug segnalati
• segnalati bug che ti sono stati assegnati per risolvere

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

Vorrei dire che non dovresti nemmeno refactoring altre cose su una funzione che stai risolvendo bug, principalmente a causa di:

• errori che ora sono caratteristiche

Dal codice puoi vedere come forse avrebbe funzionato ma non lo ha mai fatto, ma tutti gli utenti vanno d'accordo con l'elemento di larghezza indeterminata negli ultimi 10 anni e non ti ringrazieranno per averlo riparato.

Tra i lati positivi, se metti a dura prova il tuo cinico JFDI, sarai in grado di masterizzare anche se i bug sono super veloci e il team della nuova versione non sarà in grado di tenere il passo con le funzionalità delle vecchie versioni.

Questo ti darà un sorriso ironico e ironico di allegria ironica mentre consigli un emulatore di plugin Chrome ie6 ai clienti in modo che possano continuare a usare la 'funzione' di selezione che amano

Quello che fai non è una domanda tecnica e nessuno qui può rispondere.

Stai lavorando a un software in modalità manutenzione e osservi una tecnologia fuori moda e un gran numero di imperfezioni e incoerenze. Tu chiedi cosa fare. Ad esempio, dovresti estendere gli sforzi per renderlo compatibile con più browser? Dovresti allinearlo agli standard moderni? Dovresti correggere le incoerenze sintattiche all'interno dell'app? Il fatto è che si tratta di decisioni commerciali . Dovresti chiedere al tuo manager o al proprietario del prodotto quali problemi vogliono che tu risolva e quali siano le loro priorità. Poiché è già in corso un progetto per riscrivere l'app, è molto probabile che il management sia già a conoscenza dei problemi riscontrati.

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

Chiedete se è possibile effettuare ampie operazioni di ricerca e sostituzione nella base di codice, modificando migliaia di file. Certo che puoi. La domanda è se dovresti . Tali cambiamenti radicali richiederanno probabilmente test approfonditi per garantire che nulla si rompa. Ancora una volta è una decisione aziendale se il vantaggio supera i costi in termini di tempo e rischi.

Quando l'applicazione verrà sostituita tra le 18 e le 24 settimane (aggiungendo i ritardi attesi alle 6-8 settimane stimate sopra presentate), allora devi davvero chiederti quale valore aggiungi all'azienda investendo ancora una notevole quantità di lavoro in la vecchia versione.

Certo, quando rimarrai bloccato nel supportare l'applicazione per molti anni a venire, a lungo andare può valere la pena di liberare il debito tecnico. Ma quando tutto sarà scaricato comunque, perché preoccuparsi? Basta aggiungere un'altra correzione hackish in cima a tutte le altre correzioni hackish per riparare qualsiasi problema semplicemente non può aspettare fino al rilascio della nuova versione e chiamarlo un giorno.

Potresti anche chiederti cosa puoi fare per l'applicazione nella piccola vita che è rimasta. Quando si è veramente annoiato in questo momento e semplicemente non hanno nulla di meglio da fare con il vostro tempo si potrebbe dare un grande revisione e rimuovere tutti i problemi di stile che hai citato, ma è molto probabile che questo sarà in prima pausa più cose di quanto non lo riparerà . Potresti riuscire a sbarazzarti di questi nuovi problemi alla fine dando abbastanza tempo, ma non hai quel tempo.

Motivi per NON apportare grandi cambiamenti:

Uno: il codice sparirà tra qualche mese. Vale davvero la pena dedicare il tempo dell'azienda a dedicare 5 mesi alla riparazione di un sistema che verrà gettato via 1 mese dopo? Avvertenza: i sistemi raramente vanno via quando sono programmati per 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, verranno introdotti dei bug. Non potresti introdurre bug: lo farai. Supponiamo di aver fatto un S&R e di aver modificato "larghezza = 200" in "larghezza: 200 px". C'è codice C # o VB sulle tue pagine ASP? Perché se avevi una variabile chiamata "larghezza" che stavi impostando su 200, la hai semplicemente rotta. (O del resto, hai pensato di limitare l'S & R alle pagine ASP?) O se hai cambiato "larghezza: 200" in "larghezza: 200px", cosa succede se nel codice c'era un posto che diceva "larghezza: 200mm "? Ora dice "larghezza: 200pxmm". Bene, supponiamo che tu abbia pensato a quelli. E se ci fosse un posto in cui fosse stata specificata la larghezza non valida, che ovviamente viene ignorata e ora si presenta abbastanza bene. Tu aggiusti" la larghezza e ora presenta 200px ... e il display è rovinato, perché 200px è in realtà la larghezza sbagliata da dare e ha funzionato solo perché quel valore è stato ignorato? Le S&R di massa sono molto pericolose, perché quasi certamente non stai studiando tutti i posti che cambi. Probabilmente non sei nemmeno sicuro di cosa testare.

Tre: il codice "ovviamente" sbagliato può in effetti essere ciò che l'utente desidera. Ho visto molte specifiche di requisiti che richiedono un comportamento che è ovviamente sbagliato e folle ... e poi torno dagli utenti e chiedo che cosa REALMENTE vogliono, e si scopre che vogliono davvero questo comportamento folle, perché quello è come la loro attività funziona o le normative governative lo richiedono o altro.

Anche se il comportamento è davvero sbagliato, forse gli utenti si sono aspettati che lo aggirassero abitualmente e, risolvendolo, si romperanno le soluzioni alternative. Esempio: lavoro su un sistema in cui abbiamo un luogo in cui si specifica da e attraverso le date che una vendita è disponibile al pubblico. Entrambe le date erano davvero la mezzanotte che è iniziata quel giorno, quindi se hai detto "fino al 30 luglio" significava che si sarebbe conclusa con la fine della giornata il 29 luglio, ovvero un minuto prima delle 00:01 del 30 luglio, non la fine del 30 luglio A un certo punto ho risolto questo problema, ma potevo farlo solo perché c'erano meno di una mezza dozzina di persone con l'autorità per usare quello schermo e potevo semplicemente dire loro che l'avevo risolto. Se c'erano centinaia di utenti, e ormai tutti avevano capito che dovevi davvero dare il giorno successivo alla data di scadenza, allora il mio "aggiustamento"

Ovviamente posso fare una ricerca e sostituzione globale per rimuovere la maggior parte dei problemi, ma ciò significherebbe che il mio primo commit consisterebbe in migliaia di file ASP modificati. Posso farlo?

Non vedo perché no. A commettere dovrebbe essere concettualmente una cosa, ma non vedo alcun motivo per cui un ritrovamento e sostituzione globale da style="width=20"a style="width: 20px"non conterebbero come "una cosa", concettualmente parlando. E se ti aiutasse a dormire meglio, risparmiandoti la distrazione mentre aggiusti le altre cose e non sporcare nulla , perché no?

Il tuo problema è stabilire le priorità : quali dei problemi sono gli showtopper (in produzione)? Quali sono le bombe a orologeria? E quale può essere lasciato tra un po 'di più (perché funziona e lo fa da anni ormai, anche un po')?

Quello che farei nella tua situazione è fare elenchi di classi problematiche che vorrei esaminare. Ad esempio, la sostituzione style="width=(\d+)"con style="width: \1px"(che probabilmente può essere corretta con una ricerca / sostituzione globale usando regexp - scusate se la mia non è al 100%) sarebbe una classe, e se c'è solo un'occorrenza, così sia. Per ogni elenco di categorie una priorità (quanto è urgente farlo) e una stima del lavoro (quanto tempo ci vorrà per fare questa categoria).

Anche le attività di manutenzione figureranno 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 niente da fare, o quando devi negoziare con il tuo manager sul lavoro da svolgere (o richiedere tempo per essere assegnato a qualcosa di cui potrebbe non essere a conoscenza). (Questo tipo di proattività potrebbe aiutarti a farti notare per le promozioni, se fatto nel modo giusto.)

Immagino ti piaccia programmare perché hai una leggera personalità perfezionistica in una certa misura. MA in un ambiente commerciale, è necessario iniziare a rendersi conto che il perfetto è il nemico del bene (e il bene porta i soldi, il perfetto potrebbe non necessariamente portare sensibilmente di più per un lavoro molto più). Prima fai ciò che è necessario, quindi fai ciò che è bello avere. Sì, questo potrebbe andare contro il tuo grano senza fine. Sorridi e sopportalo, e magari prendi un hobby per esercitare il tuo perfezionismo e mantenerti sano di mente ;-)