Questa è un'indicazione dell'accoppiamento alto

4

Sto facendo una revisione del codice per un sistema software commerciale. Ho notato che la storia di alcuni utenti e anche le sotto-attività quando sono implementate provocano un grande codice di commit e di solito finiscono con il cambiare di decine di file di codice sorgente (classi java, file javascript, HTML, ecc.)

Mi aspetto che quando qualcuno implementa una sottoattività o una singola storia utente richiederà solo la modifica di alcuni componenti. A volte il commit può avere fino a 60 file modificati.

In allegato uno screenshot per illustrare il caso

unaltroesempio

Nota:nonpensochelamiadomandasiaunaduplicazionedi Ho modificato una firma del metodo e ora ho oltre 25.000 errori. Cosa succede ora? Nel mio caso, sto cercando di capire se il software soffre di un elevato accoppiamento o meno osservando il costo della revisione del codice. Perché cambiare il comportamento di una storia utente richiede molte modifiche nel codice sorgente?

    
posta Ubaidah 27.12.2016 - 21:22
fonte

2 risposte

8

Is this an indicator of high coupling?

Forse.

A volte questo è un indicatore dell'accoppiamento elevato perché quando una cosa cambia, si sovrappone, influenzando un sacco di altre cose.

A volte è un indicatore di accoppiamento lento perché quando si vuole fare una cosa considerevole è necessario toccare tutte le diverse responsabilità necessarie per fornire una funzionalità coesiva agli utenti finali.

Le caratteristiche dello stack completo tendono a peggiorare la situazione, dal momento che si ottiene il front end e il back-end, i test per ciascuno e i contratti per ciascuno.

Java tende a peggiorare le cose con il suo stile idiomatico di BlahBlahServiceProviderFactory che le classi devono fare tutto.

Il tuo bisogno di internazionalizzazione tenderà a peggiorare la situazione, poiché dovrai separare le risorse dal codice.

E, francamente, le recensioni del codice tendono a peggiorare la situazione, dal momento che le persone vogliono evitare il sovraccarico della recensione e i revisori vogliono che le funzionalità coesive vengano riviste, non piccole fette con le cose ancora in corso.

Quindi, mentre i check-in ampi possono essere un segno di accoppiamento, sono più spesso un effetto collaterale pratico delle funzionalità aziendali che necessariamente superano i limiti del modulo.

    
risposta data 27.12.2016 - 22:05
fonte
2

EDIT : ho scritto la seguente risposta sotto la lettura errata che il richiedente voleva sapere se l'uso diffuso di un metodo Java da parte di altri componenti era un'indicazione di stretto accoppiamento tra quel metodo e i componenti usandolo (nel qual caso la risposta è no, come ho risposto di seguito).

Ora vedo che il richiedente stava cercando di inferire la probabilità di accoppiamento stretto nel sistema sulla base della recensione.

La seguente risposta affronta solo il caso precedente, ma lo lascio in sospeso perché penso che sia ancora pertinente a quella parte della domanda.

Non considererei questo accoppiamento stretto. La firma di un metodo fa parte delle sue specifiche. Se avessi cambiato String::length() in String::length(boolean derp) , probabilmente creerebbe un sacco di codice Java là fuori. Non puoi aspettarti che la modifica di un metodo non causerà molti errori.

Tutto ciò indica che questo metodo è ampiamente utilizzato. Se hai bisogno di cambiare il metodo , nella maggior parte dei casi dovresti scrivere un metodo separato, non modificare un metodo già ampiamente utilizzato.

    
risposta data 28.12.2016 - 20:08
fonte

Leggi altre domande sui tag