Gli argomenti più efficaci a favore del miglioramento della qualità del codice, per un manager [chiuso]

3

Il sistema legacy del mio datore di lavoro iniziò (nel 1997) come codice procedurale molto strutturato (con un gran numero di OO), e fu fortunatamente uno dei 10% dei progetti software che ebbe successo. Oggi può sembrare un po 'antiquato, ma almeno è strutturato e fornito un framework per appendere le estensioni.

Avanti veloce verso la fine degli anni 2000 e gli sviluppatori non connessi con gli architetti originali hanno esteso il sistema un po 'alla volta in modo ad hoc senza architettura, semplicemente prendendo decisioni mentre procedevano, andando con quello che sembrava avere senso per loro al tempo. Hanno anche abbandonato qualsiasi convenzione di denominazione o codifica. Per semplificare eccessivamente, non fanno mai una lezione, non fanno mai nulla per il riutilizzo, e l'unica considerazione è: "spezzerà ciò che è già lì?" che mette un freno a approcci più innovativi. C'è ancora molto codice VB6.

Questi sviluppatori sono ancora lì e sono trincerati e possono applicare patch al sistema o fare cose consentite dagli architetti originali, molto velocemente.

Tuttavia, dal momento che il riutilizzo del codice è zero, non hanno blocchi di base con cui costruire un sistema completamente nuovo, quindi non possono fare nulla di veramente speciale o nuovo per un potenziale cliente, nemmeno uno gigante come il Sams Club.

Ricordo che c'erano ottimi argomenti per migliorare la qualità del codice, ad esempio usando la metodologia OO, in termini monetari che avrebbero attirato l'attenzione di un dirigente, ma non riesco a ricordare dove l'ho visto. È da un po. Intuisco intuitivamente che la raccolta di tutte le funzionalità in una classe fornisce la massima flessibilità e manutenibilità, ma non ho munizioni.

Alcuni dei pensieri a cui sono confrontato includono: Il sistema sembra funzionare "bene". Quindi perché dovremmo fare un giro sulla barca con qualcosa come un "programma di qualità"? Gli sviluppatori attuali lo adorano così com'è, quindi non vogliono fare nulla per migliorare il loro codice o la qualità dell'architettura. Conoscono ognuno dei 73 luoghi in cui viene indicata una certa quantità. Chi ne ha bisogno? T-Sql non ha bisogno di essere compilato! Copia e incolla lo stesso codice localizza bug per quella particolare copia.

EDIT:

Non era chiaro cosa stavo chiedendo, eh? Bene, la risposta accettata contiene un commento che ha un link ( link ) era esattamente quello che stavo cercando, quindi ho contrassegnato come risposta. Quindi, qualcuno, forse diverse persone, sapeva intrinsecamente quello che stavo chiedendo comunque. Se leggi l'articolo pubblicato, vedrai che in realtà quello che sto passando qui è comune. Non sono molto solo in questo, il che mi fa sentire meglio. : -)

    
posta toddmo 07.11.2014 - 23:48
fonte

1 risposta

7

La domanda originale sembrava riflettere un equivoco - una delle 10 ipotesi sbagliate su OO: la convinzione che l'orientamento all'oggetto implicherebbe più riutilizzo del codice e meno codice duplicato.

È un errore!

Se hai sviluppatori che si prendono cura del codice DRY , si occupano del riutilizzo e di chi ha imparato e compreso i principi OO , possono utilizzare quest'ultimo per creare un software migliore e più riutilizzabile. Ma non funziona mai all'inverso - basta introdurre qualche orientamento agli oggetti a un gruppo di persone che non si cura delle cose che ho menzionato prima non cambieranno nessuna delle loro cattive abitudini.

Quindi immagino che quello che cerchi davvero sia qualcosa di simile a un'offensiva di qualità per lavorare attivamente contro il famoso architettura big-ball-of-mud . Si noti che l'articolo dietro questo link non contiene la parola "orientamento dell'oggetto". In realtà, non contiene argomenti in termini di denaro (ma suppongo che i confronti e le immagini utilizzate siano comunque comprensibili per la maggior parte dei manager).

    
risposta data 08.11.2014 - 01:01
fonte

Leggi altre domande sui tag