Secondo l'ingegneria del software, quale metodo è troppo lungo? [chiuso]

Naviga le tue risposte
2

Stavo solo lavorando con un metodo di circa 70 linee di codice sviluppato da altri. Usa una struttura di pattern molto carina, roba simile al container IOC, ma mi chiedo ... Il metodo è troppo lungo?

È un metodo così lungo ancora facilmente leggibile?

La domanda potrebbe essere finita, ma ora inizia la premessa da cui è nata la mia domanda.

Prima di rendermi conto della sua lunghezza (eccessiva per me) mi stavo annoiando cercando di capire cosa stava facendo.

È pieno di istruzioni di questo tipo: 

if (success == null)
{
    //Log response error
    logger.LogProviderActionResponse(userId, "actionName", transactionRequestId,
        _configuration.ResponseLogErrorTryAgainId, xmlResponse.InnerXml.ToXml(true));
    return new CheckActionResult(ActionStatus.Failed);
}

Che cosa sta facendo e perché? Si occupa ovviamente della registrazione, perché la variabile success è nullo, ma cosa implica? E anche ci sono molti parametri, qual è il loro significato?

Avrei bisogno di leggerlo attentamente, per studiarlo.

Il problema è che questo metodo implementa un'interfaccia e una classe astratta, ha molti fratelli. Copia e incollati fratelli che condividono lo stesso comportamento strutturale. Ma non è immediato distinguere le informazioni strutturali dalle informazioni specifiche del dominio.

Nello sviluppo di una nuova azione o di un nuovo fornitore dovrei solo copiare, incollare e modificare elementi specifici del dominio . Ma è difficile ... dato che sono profondamente mescolati con il comportamento strutturale ...

Refactoring Vorrei fare per aumentare la leggibilità

  • 1o passaggio

    racchiudi tutto questo logging con una #region che può essere compressa

  • Il secondo passaggio potrebbe essere

    utilizzare il metodo Extract per trasnsformare la precedente chiamata di registro a una singola istruzione. Qualcosa come:

    Log.LogWithReason (Success.IsEmpty);

Ma l'uso del rendimento è in conflitto con questo scopo e richiede uno sforzo extra.

  • 3 ° passaggio

    significherebbe separare completamente la responsabilità di Logging (usando AOP? Implementandolo nella classe base? usando eventi?). Se un metodo ha 5/8 chiamate al registro per diversi motivi. È troppo consapevole della registrazione. A mio parere, il principio della responsabilità unica è violato poiché i metodi hanno acquisito la responsabilità secondaria di essere strongmente consapevoli della registrazione.

La domanda rimane quella specificata nel titolo ma spero di leggere un confronto molto maturo qui basato sull'idea di semi che ho scritto!

Grazie per il tuo contributo

    
posta M.F05051985 11.04.2014 - 11:26
fonte

2 risposte

3

@jwenting ha ragione che il numero di linee non dovrebbe essere la ragione principale per i metodi di refactoring. Tuttavia è spesso un indicatore di un "odore di codice". E quando la situazione è così chiara come nel tuo esempio di registrazione, dove l'SRP è chiaramente violato, il metodo dovrebbe essere refactored. Quindi i tuoi criteri principali per "quando fare il refactoring" dovrebbero essere lo stesso SRP, gli altri principi SOLID e il principio del "single level of astrstraction" (SLA).

E il "numero di linee" di un metodo dovrebbe essere usato solo come indicatore di "quale metodo per verificare se viola questi principi e può essere migliorato".

Come hai chiesto di "ingegneria del software": se stai scrivendo qualcosa come una guida di stile per il tuo codice, non aggiungere una regola come "evita metodi più lunghi di XXX righe" , meglio aggiungere una regola come "evitare metodi che violano lo SRP" .

    
risposta data 11.04.2014 - 12:18
fonte
1

Un metodo è troppo lungo e fa più del necessario. Qualsiasi affermazione generale che "qualsiasi metodo più lungo di XXX linee / istruzioni è troppo lungo" è fasullo, mostra solo che l'autore della dichiarazione è un acedemico irrispettoso senza esperienza di scrittura di software realmente produttivo.

È bello e dandy affermare che "tutto ciò che può essere deve essere rimosso in un altro metodo", ma se questo rende il codice più difficile da seguire, non è la cosa da fare (e potrebbe introdurre problemi di prestazioni che è ancora peggio). Ancora una volta, il teorico può fare affermazioni del genere, il professionista deve lavorare con la realtà e la realtà potrebbe ben scontrarsi con la teoria del libro.

Ho lavorato su sistemi di fissaggio che sono stati creati secondo "standard" stabiliti da tali teorici. Sistemi che sulla carta erano meraviglie di bellezza e design, ma in pratica erano quasi impossibili da mantenere e mancavano di esibirsi (soprattutto perché erano troppo lenti a causa di un carico eccessivo dovuto a chiamate di metodi eccessive e creazioni di oggetti). > Il caso peggiore era un sistema che impiegava 72 ore per generare 500 lettere formali. Ignorando il pasticcio della struttura del sistema e collegando il generatore di lettere direttamente al database, è sceso a circa 20 secondi (senza contare il tempo necessario per la stampa fisica che era di pochi minuti).
Questo è il prezzo che paghi se lasci che la correttezza teorica prenda posto sul design pragmatico e pratico.

    
risposta data 11.04.2014 - 11:46
fonte

Leggi altre domande sui tag

Impostazione dei parametri globali: è un uso ragionevole di const_cast e volatile? Le migliori pratiche per restituire json in un'applicazione REST?