Come convincere le persone che una singola classe con 11975 righe di codice è cattiva? (non è vero?)

Question

Ho una sensazione di dejavu quando leggo il post di [What to do about a 11000 lines C++ source file?], ma non penso di poter iniziare ad agire da solo poiché non ho l'autorità per agire. Quindi penso che il primo passo sia convincere le persone nell'organizzazione che una grossa cifra di codice è cattiva.

Ho una situazione simile in cui esiste una singola classe con 11975 righe di codice e ogni volta che ci sono nuove funzionalità, c'è un'alta probabilità che questa classe diventerà sempre più grande.

Answer 1

Hai le mie simpatie. Qualsiasi classe che sia così grande sta inevitabilmente rompendo lo Single Responsibility Principle, rendendo difficile la manutenzione.

Il mio miglior consiglio è quello di dare l'esempio:

• Mantenere il nuovo codice di piccole dimensioni.
• Refactor senza pietà durante la modifica del codice per ridurre la dimensione di classi e funzioni.

Il tuo codice risplenderà come un faro rispetto a un codice legacy e il tuo team capirà quale codice è più facile da mantenere.

Answer 2

Avere una classe enorme non è male. Se il programmatore riesce a gestirlo e comprenderlo, allora è una classe perfetta. Se il programmatore è completamente perso quando tenta di cambiare o aggiungere qualcosa alla classe, allora è male.

Con la programmazione, si tratta di preferenza. Se preferiscono avere una singola classe di 11975 linee di codice e possono gestirle, allora è la loro scelta.

Ma sì, è generalmente male.

Answer 3

Se questa classe è costituita da molti metodi più piccoli E questi metodi appartengono effettivamente alla classe, cioè sono coerenti tra loro e la classe, quindi questo non è necessariamente negativo.

Il semplice fatto che una classe sia grande non lo rende automaticamente negativo.

Ciò che è più importante è evitare una cosiddetta "classe di Dio" che contiene molti metodi che non hanno alcuna relazione concettuale tra loro o la classe stessa.

Anche tenere a mente la dimensione dei singoli metodi è importante perché la maggior parte degli sviluppatori dovrà "caricare" un intero metodo nel loro cervello in una volta, non nell'intera classe. Quindi il metodo più conciso è il più semplice da mantenere per gli sviluppatori.

È necessario raccogliere le metriche sul numero di problemi di supporto che possono essere ricondotti al codice in questa classe. Inoltre, quanto tempo gli sviluppatori spendono per apportare modifiche a questa classe rispetto ad altre classi più piccole? Una volta che hai queste metriche, sei in una posizione migliore per spiegare alla direzione perché la classe non è buona.

Nella situazione di una classe di grandi dimensioni con un numero ridotto di metodi grandi, utilizzare le tecniche di refactoring descritte in Martin Fowlers book, unitamente ai test delle unità per garantire che non vengano introdotti nuovi bug.

Una volta effettuato il refactoring di un metodo enorme su un numero di metodi più semplici e comprensibili e con test unitari di successo, è sufficiente dimostrarlo ai colleghi.

A questo punto, se i tuoi colleghi non sono d'accordo o non riescono a vedere un miglioramento generale della comprensibilità e della manutenibilità del codice refactored, hai a che fare con un problema politico/di personalità. In tal caso, spetta a te se vuoi continuare a lavorare in tale ambiente.

Answer 4

11975 (o è già 12000 :)) righe di implementazione di classe. È male? Ceneramente sembra così. Ma ...

Dipende. In genere le classi che implementano il modello di Mediatore o il modello di facciata tendono ad essere molto grandi. Hanno un protocollo di routing/comunicazione molto complesso. Anche le classi di "Dio" tendono ad essere molto grandi e monolitiche. In breve, una classe potrebbe essere in realtà di grandi dimensioni ma il potrebbe non essere un problema con.

Quindi, anziché concentrarsi sulla LOC come parametro, concentrarsi sulla funzionalità/progettazione della classe. La classe sta violando il principio di responsabilità unica? La LOC da sola non può essere l'unico fattore decisivo per concludere se una classe è davvero enorme. Guarda altri parametri, ad es. Complessità ciclopica

Tuttavia, se si conclude che questo è davvero pessimo nel contesto del proprio progetto, è necessario avere una valida ragione per convincere gli stakeholder rilevanti. Ad esempio,

a. Questa classe ha molti bug?

b. Queste correzioni ai bug di classe introducono sempre i difetti di regressione? (Alto accoppiamento, bassa coesione?)

c. Quanto tempo ci vuole per correggere i difetti in questa classe? Come si confronta con altri moduli?

d. Generare alcuni diagrammi UML per questo modulo per illustrare i problemi importanti (ad esempio l'accoppiamento).

e. Leggi tanto sulle metriche/consulta il tuo team Qualità/Metriche/Controllo qualità e genera punti dati sufficienti. Un esempio di metriche OOAD è here ma sono sicuro che ce ne sono molte.

EDIT 2 (lievi modifiche)

f. Ottieni il supporto iniziale di alcuni stakeholder chiave nella tua sfera di controllo. Successivamente, ottenere, qualcuno che può presentare questi fatti bene !. Ho visto molte cose fallire in questa fase !.

Buona fortuna!

Answer 5

Dire loro di riassumere ciò che la classe fa \ rappresenta in un minuto.

Answer 6

Ecco la mia reazione iniziale:

1. non ci sono posti di refactoring per ridurre lo SLOC? Hai provato a rifattorizzare prima, prima di ogni altra cosa?
2. È la gestione di più di una responsabilità o come un altro poster dichiarato è una facciata?
3. Ci sono molte macro di pre-elaborazione incorporate nel codice, rendendolo così "più piccolo" di quanto non sembri essere?
4. È in corso la creazione di istruzioni di query di tipo SQL? Ho visto che occupano abbastanza spazio e rapidamente aggiungono allo SLOC senza essere necessariamente indicatori di scarsa qualità del codice.
5. Come è stato assemblato questo codice e in che momento le pressioni? Qual è la storia del codice?Ho visto solo codice come questo (e ne ho prodotto io stesso) quando gli orari sono stati quasi pazzia borderline. Forse è stato un "... creato in 6 giorni, il 7 per riposare" una sorta di corsa mostruosa, ma mai risolto.
6. Gli altri sviluppatori sono effettivamente sviluppatori?

Non ci sono suggerimenti qui tranne il refattore che cosa è possibile. Trova qualsiasi funzionalità viola D-R-Y e poi puliscila.

Answer 7

Convincere qualcuno a cambiare l'implementazione esistente (soprattutto se "funziona") non è facile.

Vorrei iniziare chiedendo agli avversari di fare il compito banale (dalla mia esperienza con classi così estreme, credo che ci siano pochi metodi abbastanza grandi) come aggiungere qualcosa a uno di metodi enormi. Dovrebbe insegnare loro una lezione: trovare il posto giusto sarà davvero doloroso. Quindi, potresti chiedere: "Immagina di sostenere questa lezione, sarà un compito facile?".

Puoi provare un approccio diverso, ma probabilmente fallirà: chiedi loro di scrivere il test dell'unità per questo codice. O semplicemente chiedere loro di pensare a qualsiasi ...

Answer 8

Fondamentalmente quelle persone non hanno conoscenze su oops? Fare OOAD prima di iniziare il progetto è l'idea migliore per evitarlo, dalla mia esperienza posso dire che ogni programmatore non ha conoscenze su oops, quindi ovviamente non possono scrivere un codice migliore.

Questo è dove la differenza è dotato di un programmatore e Analista