Quando apporti una modifica a una singola tabella nella nostra app, dovremmo ridurre al minimo l'ambito delle nostre modifiche o seguire le best practice per la codifica css / jsp?

Question

Quando apporti una modifica a una singola tabella nella nostra app, dovremmo ridurre al minimo l'ambito delle nostre modifiche o seguire le best practice per la codifica css / jsp?

#1 da (5 voti)

2

Al mio collega è stato assegnato il compito di modificare una delle nostre tabelle dell'applicazione Java. Ha quasi finito, ma ha bisogno di fare un ultimo aggiustamento alla tabella - questo le richiede di aggiungere un attributo CSS a una singola cella di tabella in modo che non si sposti alla riga successiva.

Tuttavia, mi sta informando che "best practice" è definire il comportamento del TD nelle nostre definizioni CSS.

Cambiare il comportamento del TD piuttosto che una singola cella è sicuramente la soluzione migliore, ma questa app è già in produzione e ci sono migliaia di celle di tabella diverse in tutto il mondo - cambiare il comportamento delle nostre celle ora potrebbe influire su ogni singola tabella cella nell'app, quindi la sto incoraggiando a apportare il cambiamento proprio in quella cella per ridurre al minimo la portata del suo cambiamento.

Il mio suggerimento è corretto - è meglio minimizzare lo scopo di questo cambiamento, o seguire la best practice e cambiare l'attributo nelle nostre definizioni CSS?

programming-practices javascript css

posta Zibbobz 05.04.2016 - 19:21

fonte

1 risposta

Leggi altre domande sui tag programming-practices javascript css

Principio aperto / chiuso Integrazione della libreria di log in oggetto multilivello: cos'è una buona struttura?

score 5 · Accepted Answer

Se si apporta una modifica a un'applicazione che causerà un ciclo di test manuale di tre settimane, la persona o la squadra non sarà "sempre fatta", nemmeno chiusa. Se questa è la tua situazione, dovrebbe essere ovvio che mantenere la modifica a livello locale è chiaramente l'opzione migliore.

Tuttavia, se disponi di una suite di test automatica con una copertura di test elevata, che può eseguire i test in meno di dieci minuti, e ti dà la sicurezza che nulla si è rotto, puoi applicare la modifica in modo sicuro. Oppure, se la modifica interrompe troppi test, puoi comunque ripristinare la modifica utilizzando il tuo VCS e cercare una soluzione diversa.

In realtà, tuttavia, potresti trovarti di fronte a una situazione a metà tra questi due estremi, ed è spesso un compromesso. Tuttavia, dovresti cercare di mantenere il tuo software in grado di evolversi e cercare di apportare modifiche in modo sicuro anche quando riguardano più di una parte del tuo sistema.

Quindi, se il tuo team non dispone di tale suite di test, la migliore opzione a breve termine è probabilmente quella di minimizzare l'ambito di una modifica. L'opzione migliore a medio o lungo termine, tuttavia, è quella di creare una tale suite di test, in modo da poter applicare in modo sicuro i refactoring anche se hanno un ambito più ampio. Minimizzare sempre la portata delle modifiche porta in genere a una degredazione della qualità del codice, aumenta il "debito tecnico" e spesso finisce in un "grande "palla di fango" .