Disaccoppiamento vs YAGNI

Question

Sono in contraddizione?

Il disaccoppiamento è qualcosa di eccezionale e abbastanza difficile da realizzare. Tuttavia nella maggior parte delle applicazioni non ne abbiamo davvero bisogno, quindi posso progettare applicazioni altamente accoppiate e quasi non cambierà nulla se non ovvi effetti collaterali come "non è possibile separare i componenti", "il test unitario è doloroso nel culo " ecc.

Cosa ne pensi? Cerchi sempre di disaccoppiare e gestire le spese generali?

Answer 1

Mi sembra che il disaccoppiamento e YAGNI siano virtù molto complementari. (Ho appena notato la risposta di Rob, e sembra che siamo sulla stessa pagina qui.) La domanda è: quanto disaccoppiamento dovresti fare, e YAGNI è un buon principio per aiutare a determinare la risposta. (Per coloro che parlano di unit test - se devi disaccoppiare per fare il tuo unit test, allora YAGNI ovviamente non si applica.)

Dubito davvero sinceramente che le persone che affermano di aver sempre " sempre " disaccoppiare. Forse lo fanno sempre ogni volta che ci pensano. Ma non ho mai visto un programma in cui ulteriori strati di astrazione non possano essere aggiunti da qualche parte, e dubito sinceramente che esista un esempio non banale di un tale programma. Tutti tracciano una linea da qualche parte.

Dalla mia esperienza, ho disaccoppiato il codice e quindi non ho mai approfittato della flessibilità aggiuntiva ogni volta che ho lasciato il codice accoppiato e quindi ho dovuto tornare indietro e modificarlo in seguito. Non sono sicuro che ciò significhi che sono ben bilanciato o ugualmente rotto in entrambe le direzioni.

Answer 2

YAGNI è una regola empirica (non una religione). Il disaccoppiamento è più o meno una tecnica (anche non una religione). Quindi non sono realmente collegati, né si contraddicono a vicenda.

YAGNI riguarda il pragmatismo. Supponi di non aver bisogno di qualcosa, finché non lo fai.

Di solito assumendo che YAGNI si traduca in disaccoppiamento. Se non applichi affatto quel coltello, finisci per presumere che devi avere lezioni che sappiano tutto sul comportamento reciproco prima di aver dimostrato che è vero.

" Disaccoppiare " (o "vagamente coppia") è un verbo, quindi richiede lavoro. YAGNI è una presunzione, per la quale ti adegui quando scopri che non è più vero.

Answer 3

I (quasi) sempre disaccoppiare. Ogni volta che lo facevo lo trovavo utile e (quasi) ogni volta che non lo facevo, dovevo farlo in seguito. Ho anche trovato un buon modo per ridurre il numero di bug.

Answer 4

Direi di no. Il disaccoppiamento riguarda la riduzione delle dipendenze non necessarie all'interno del codice e il rafforzamento degli accessi attraverso interfacce pulite e ben definite. " Non ti servirà " è un principio utile che generalmente sconsiglia l'eccessiva estensibilità e l'architettura eccessivamente ampia di una soluzione in cui non esiste un caso d'uso ovvio e attuale.

Il risultato pratico di questi è che hai un sistema in cui è molto più facile refactoring e manutenzione dei singoli componenti senza causare inavvertitamente un effetto a catena su tutta l'applicazione, e dove non ci sono aspetti inutilmente complicati nella progettazione - è così semplice come richiesto per soddisfare i requisiti attuali.

Answer 5

Il disaccoppiamento per motivi di disaccoppiamento può essere negativo. La costruzione di componenti testabili è tuttavia molto importante.

La parte difficile della storia è sapere quando e quanto disaccoppiamento è necessario.

Answer 6

Se "test unitari è un dolore nel culo" quindi direi che ne hai bisogno . La maggior parte delle volte il disaccoppiamento può essere ottenuto anche con un costo praticamente nullo, quindi perché non dovresti farlo?

Inoltre, uno dei miei più grandi bugbear quando si lavora su una nuova base di codice è dover disaccoppiare il codice prima di poter iniziare a scrivere unit test quando l'introduzione di un'interfaccia da qualche parte o l'uso dell'iniezione di dipendenza potrebbe far risparmiare parecchio tempo

Answer 7

Come dice il tuo tag, è altamente soggettivo. Dipende interamente dalla tua saggezza ingegneristica per decidere cosa non avrai bisogno di. Potrebbe essere necessario un accoppiamento in un caso, ma non in un altro. Chi deve dirlo? Tu , ovviamente.

Per una decisione così soggettiva, quindi, non ci può essere una linea guida da prescrivere.

Answer 8

Beh, YAGNI è poco più di una falsa frase semplicistica che la gente lancia in giro. Il disaccoppiamento, tuttavia, è un concetto abbastanza ben compreso. YAGNI sembra implicare che si è una specie di sensitivo. È solo una programmazione per cliché, che non è mai una buona idea. Ad essere onesti, è necessario sostenere che YAGNI probabilmente non è affatto collegato al disaccoppiamento. L'accoppiamento è in genere "più veloce" e & ch; chissà se hai bisogno di una soluzione disaccoppiata; non cambierai comunque il componente X! "

Answer 9

YAGNI il casino :) ... davvero, non abbiamo bisogno di avere tutto il codice misto per andare "più veloce".

I test unitari aiutano davvero a sentire quando è accoppiato (dato che uno capisce bene cos'è un test unitario rispetto ad altri tipi di test). Se invece lo fai con " non puoi separare i componenti " mentalità, puoi facilmente aggiungere cose che non ti serviranno :)

Direi che YAGNI arriva quando inizi a torcere e cambiare la logica tutt'intorno oltre gli scenari di utilizzo reali richiesti dall'attuale implementazione. Supponiamo che tu abbia del codice che utilizza un paio di provider di pagamento esterni che funzionano entrambi con reindirizzamenti verso un sito esterno. Va bene avere un design che mantenga tutto pulito, ma non penso che sia giusto iniziare a pensare a provider che non sappiamo se saranno mai supportati che hanno molti modi diversi di gestire l'integrazione e i relativi flusso di lavoro.