Disaccoppiamento vs YAGNI

Question

Si contraddicono?

Il disaccoppiamento è qualcosa di grande e difficile da raggiungere. Tuttavia, nella maggior parte delle applicazioni non ne abbiamo davvero bisogno, quindi posso progettare applicazioni altamente accoppiate e quasi non cambierà niente di diverso da ovvi effetti collaterali come "non puoi separare i componenti", "il test delle unità è doloroso culo "ecc.

Cosa ne pensi? Cerchi sempre di disaccoppiare e affrontare il sovraccarico?

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 test unitari - se è necessario disaccoppiare per fare il test unitario, allora YAGNI ovviamente non si applica.)

Ho davvero sinceramente dubbi sulle persone che dicono di "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 ci sia un esempio non banale di un tale programma là fuori. Ognuno disegna una linea da qualche parte.

Dalla mia esperienza, ho scollegato il codice e quindi non ho mai sfruttato la flessibilità aggiuntiva su tutte le volte che ho lasciato codice accoppiato e quindi ho dovuto tornare indietro e modificarlo in seguito. Non sono sicuro se ciò significa che sono equilibrato o ugualmente rotto in entrambe le direzioni.

Answer 2

I (quasi) disaccoppia. Ogni volta che lo facevo lo trovavo utile, e (quasi) ogni volta che non lo facevo, dovevo farlo più tardi. Ho anche trovato un buon modo per ridurre il numero di bug.

Answer 3

Bene, YAGNI è poco più di una falsa frase semplicistica che la gente gira intorno. Il disaccoppiamento, tuttavia, è un concetto abbastanza ben compreso. YAGNI sembra implicare che si è una sorta di sensitivo. È solo la programmazione di cliché, che non è mai una buona idea. Per essere onesti, c'è da dimostrare che YAGNI non è probabilmente correlato al disaccoppiamento. L'accoppiamento è in genere "più veloce" e "chissà che tu abbia bisogno di una soluzione disaccoppiata, non cambierai comunque la componente X!"

Answer 4

Il disaccoppiamento a scopo di disaccoppiamento può essere negativo. Costruire componenti testabili è molto importante però.

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

Answer 5

Come dice il tag, è molto soggettivo. Si basa interamente sulla tua saggezza ingegneristica per decidere di cosa "non avremo bisogno". Potrebbe essere necessario l'accoppiamento in un caso, ma non in un altro. Chi lo deve dire? , naturalmente.

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

Answer 6

Direi che non lo fanno. Il disaccoppiamento consiste nel ridurre le dipendenze non necessarie all'interno del codice e nel restringere gli accessi attraverso interfacce pulite e ben definite. "Non ne avrete bisogno" è un principio utile che generalmente sconsiglia l'eccessiva estensibilità e l'eccessiva ampiezza dell'architettura di una soluzione in cui non esiste un caso d'uso ovvio e attuale.

Il risultato pratico di questi è che si dispone di un sistema in cui è molto più facile di refactoring e mantenere i singoli componenti senza provocare inavvertitamente un effetto a catena in tutta l'intera applicazione, e dove non ci sono aspetti inutilmente complicati al design - è come semplice come è richiesto per soddisfare i requisiti attuali.

Answer 7

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

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

Direi che YAGNI entra quando inizi a torcere e cambiare la logica tutto oltre gli scenari di utilizzo effettivi richiesti dall'attuale implementazione. Diciamo che hai un codice che utilizza un paio di fornitori di pagamenti esterni che lavorano entrambi con reindirizzamenti su un sito esterno. Va bene avere un design che mantenga tutto pulito, ma non penso che sia giusto iniziare a pensare ai provider che non sappiamo se saranno mai supportati che hanno un sacco di modi diversi di gestire l'integrazione e il relativo flusso di lavoro.

Answer 8

Se "unit test è una rottura di palle", allora direi che si fai bisogno. La maggior parte delle volte il disaccoppiamento può essere raggiunto anche virtualmente a costo zero, quindi perché non vuoi farlo?

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

Answer 9

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

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

In genere, supponendo che YAGNI determini il disaccoppiamento. Se non applichi affatto quel coltello, finirai per presupporre che devi avere classi che conoscono tutto il comportamento dell'altro prima di aver dimostrato che ciò è vero.

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