La riusabilità è approssimativamente sinonimo di buon design?


10

La riusabilità è una caratteristica del buon design del software .

La riusabilità è un gloss accettabile ("breve notazione del significato") per una buona progettazione del software? Perché?


Direi che la flessibilità è più importante. Avere un'architettura di base che cerca di accogliere la realtà che qualcosa probabilmente cambierà o verrà aggiunto in seguito è la chiave della mia opinione. La riusabilità arriva quasi gratis a quel punto.
Pemdas,

L'uso della flessibilità suona esattamente come la riusabilità.
Matthew Rodatus,

"La riusabilità è la probabilità di un segmento di codice sorgente che può essere riutilizzato per aggiungere nuove funzionalità con lievi o nessuna modifica" - it.wikipedia.org/wiki/Reusabilità
Matthew Rodatus

Sono impressionato dal fatto che la maggior parte delle risposte di seguito dice di no . Questo sarebbe stato il caso solo pochi anni fa (beh ... 5-10 anni), quando la riusabilità era di gran moda qualcosa di altamente desiderabile.
Martin Wickman,

@MartinWickman La riusabilità è buona, ma non è gratuita.
Caleb,

Risposte:


13

No.

Il riutilizzo è un indicatore di un buon design. Indica che l' accoppiamento del sistema è abbastanza lento e la coesione di una determinata unità è abbastanza elevata da facilitare il riutilizzo senza incorrere in problemi di dipendenza o dover riscrivere la maggior parte del codice.

La riusabilità è in gran parte un'illusione. È verosimilmente impossibile misurare la "riusabilità" di un'unità senza sapere in anticipo dove o come verrà utilizzata. Molti sviluppatori cercheranno di progettare componenti "riutilizzabili" e spesso scopriranno in seguito che gli aspetti specifici che hanno cercato di rendere "flessibili" sono esattamente quelli che non avevano bisogno di essere.

Vorrei usare un "gloss" diverso : Testabilità.

Ora non sono un sostenitore del TDD, né sento la necessità di testare l'unità di tutto e di tutto. Ma scrivere test per un componente ti darà un'ottima idea delle sue caratteristiche di accoppiamento / coesione e molto rapidamente. Se dipende dalle astrazioni, allora si tratta di un accoppiamento libero; troverai facile deridere le dipendenze e questo suggerisce un buon design. Se ha uno scopo chiaro (vedi anche Principio della singola responsabilità ), allora il suo comportamento sarà relativamente intuitivo, troverai facile capire cosa testare, il che suggerisce ancora una buona progettazione.

Ciò, ovviamente, non garantisce un buon design; l'implementazione effettiva o persino l'intera architettura potrebbe essere del tutto inappropriata per il suo scopo dichiarato. Ma almeno ti dice che non stai lavorando con il codice spaghetti o God Objects.

Per favore, non provare a fare ipotesi selvagge sulla "riusabilità" di un componente, in particolare non usarlo come prova di "buon design". Questo è qualcosa che puoi stabilire col senno di poi, una volta che viene effettivamente riutilizzato, e da allora il design potrebbe essere cambiato in modo significativo.


Buona risposta. Hai risposto alla domanda che avrei dovuto porre: "Cos'è una buona brillantezza per una buona progettazione del software?"
Matthew Rodatus,

+1: Soprattutto per "La riusabilità è in gran parte un'illusione".
Kramii,

È solo un indicatore di un buon design se la riusabilità è un obiettivo. Spesso è un obiettivo, se implicito, ma sprecare tempo e denaro per rendere riutilizzabili i componenti quando non è necessario.
Caleb,

5

No.

La riusabilità è una buona caratteristica, perché può accelerare lo sviluppo futuro. (Sebbene in pratica pochissime organizzazioni vedano lo sviluppo futuro accelerato di quasi quanto speravano che fosse.) Tuttavia, qualsiasi software significativo ha parti specifiche di tale applicazione. Inoltre, quando le persone senza esperienza nel dominio provano a scrivere software riutilizzabile, di solito offuscano quel pezzo e riducono le prestazioni senza riuscire a renderlo riutilizzabile.

Pertanto un buon design è modulare e riutilizzabile solo dove è possibile vedere che il pezzo può essere riutilizzato e in cui si dispone delle competenze per ottenere effettivamente la riusabilità. Altrove dovresti cercare di rendere le cose pulite ma non preoccuparti della riusabilità. (Tranne nella parte posteriore della testa in cui stai prendendo appunti in modo che su un sistema futuro avrai un'idea di come renderlo riutilizzabile.)


Che dire dei test automatizzati? I test unitari non sono una forma di riutilizzo?
Matthew Rodatus,

@ Matthew-Rodatus: i test unitari fanno parte del tuo software consegnabile. Il riutilizzo di solito si riferisce al riutilizzo del codice in alcuni altri software.
btilly

Buon punto. Immagino che sto usando la "riusabilità" in senso ontologico, il che è confuso. Tuttavia, osserva come le funzionalità della riusabilità sono anche caratteristiche del codice testabile: en.wikipedia.org/wiki/Reusability
Matthew Rodatus,

1
@ matthew-rodatus: la riusabilità non è "Ha questo elenco di funzioni". Se cerchi di ottenere la riusabilità in quel modo, fallirai duramente. Fidati di me su questo.
btilly

Buon punto. Vedo ora che non ho posto la domanda che intendevo porre, ma è comunque un dialogo interessante.
Matthew Rodatus,

4

Credo (e questa è la mia convinzione personale) che il rapporto tra riusabilità e buon design non sia riflessivo, quindi la risposta semplice e di base è no . Se sei interessato ad alcune buone guide alla progettazione, consulta questo articolo di Wikipedia.

Una buona progettazione del software deve essere riutilizzabile, almeno in alcune parti fondamentali, penso che pochissime persone eseguano effettivamente il riutilizzo del codice sorgente, a causa del fatto che è estremamente complesso progettare il nucleo di un sistema per essere riutilizzabile in molti contesti diversi (E lo sto dicendo per esperienza)

Considera una classe con un'enorme quantità di responsabilità (nota anche come Blob) che svolge tutti i compiti di cui hai bisogno ma senza alcun tipo di considerazione progettuale, forse hai visto il caso. La maggior parte delle persone con una classe del genere la userebbe ancora e ancora e penso che dovremo concordare sul fatto che sia riutilizzo, riutilizzo senza progettazione.

Spero di non aver rovinato troppo le mie spiegazioni


Ecco perché ho detto "gloss" (con cui intendo dire che, in pratica, la riusabilità cattura la maggior parte, ma non tutto ciò che intendiamo per buon design).
Matthew Rodatus,

Il mio punto è che hai bisogno di riusabilità per avere un buon design , ma avere un sacco di codici "riutilizzabili" non significa che tu abbia un buon design, quindi direi ancora di no, nemmeno come un gloss
David Conde,

Questo ha senso. Non sono sicuro di essere d'accordo, ma +1 per una risposta ben ponderata.
Matthew Rodatus,

2

Penso che un indicatore migliore di un buon design sia l'adesione a idee fondamentali come il principio della responsabilità singola e il mantenimento della coesione di ciascun componente. Usando le astrazioni con un'interfaccia chiara e concisa e mantenendo la conformità con il principale sostitutivo di Liskov , incoraggiamo il riutilizzo senza cercare di prevedere ciò che sarà e non verrà riutilizzato.

Attenersi a questi principi di progettazione fondamentali rende il codice più facile da testare e più facile da riutilizzare.

Good design == good design, la riusabilità è un sottoprodotto.


1

La riusabilità è spesso un obiettivo di progettazione implicito. Se riesci a creare un componente, o un intero disegno, in modo tale da poterlo riutilizzare in un secondo momento, sembra ovvio che dovresti farlo. Ciò che non è sempre ovvio è che possono essere necessari molto tempo e sforzi (e denaro) per rendere qualcosa di riutilizzabile, e quindi il vantaggio della riusabilità deve essere valutato rispetto al suo costo.

Un design riutilizzabile che costa il doppio e / o impiega il doppio del tempo di realizzazione rispetto a quello di cui il cliente ha bisogno non è un buon design dal punto di vista del cliente, in particolare se il cliente non ha bisogno di riusabilità.

Ci sono una serie di attributi simili che sono spesso considerati obiettivi di progettazione impliciti perché sembrano ovviamente buoni:

  • minimizzare i costi

  • minimizzare i tempi di sviluppo

  • minimizzare la complessità

  • massimizzare l'affidabilità

Queste cose sono tutte oggettivamente buone, ma potrebbero non essere sempre importanti per un determinato cliente in un determinato momento, quindi è importante comprendere appieno ciò di cui il tuo cliente ha bisogno (anche se quel cliente è solo il tuo capo). Ci sono una serie di aforismi che hanno lo scopo di ricordarci questo fatto (ad esempio "Fatto è meglio che perfetto" e "Buono, economico, veloce: sceglierne due"), ma è ancora facile cadere nella trappola del tentativo di rendere il software fantastico sotto tutti gli aspetti, quando in realtà non è sempre necessario un grande sotto tutti gli aspetti.

Per arrivare alla domanda sul titolo, quindi: No , la riusabilità non è sinonimo di buon design. La riusabilità può essere un componente utile di un particolare design, ma solo quando è necessario.


0

Non necessariamente. Se rendi qualcosa di riutilizzabile che chiaramente non verrà mai riutilizzato, allora è un cattivo design.

Ad esempio, se stai scrivendo un file pieno di dati che è unico per la tua azienda e che i dati devono essere importati una volta altrove, perché preoccuparsi di renderlo riutilizzabile?

Detto questo, se il tuo framework non ne ha già uno, potrebbe essere necessario riutilizzare il codice per scrivere su un file. Sarebbe un buon design.


Come fai a sapere se qualcosa non verrà mai riutilizzato?
Matthew Rodatus,

1
@Matthew - Sarebbe la mia definizione di bravo designer: qualcuno che di solito risponde correttamente a questa domanda
pdr,

0

Direi di no, soprattutto perché descrive solo un piccolo segmento di codice. Ho scoperto che dove l'usabilità è più importante è al centro e ai confini esterni del territorio di utilità, non tanto in mezzo. Darò alcuni esempi di cose in cui penso che la riusabilità sia una metrica utile di design di qualità.

Roba principale

  • Modelli di moduli Web che consentono di aggiungere una pagina in modo semplice e coerente (o per qualsiasi tipo di interfaccia utente)
  • Progettare aiutanti del modello come una classe base ViewModel che sarà inclusa in tutte le mie applicazioni MVVM

Roba di utilità

  • Classe di posta elettronica che invia un messaggio SMTP (utilizzalo sempre)
  • Una classe di calcolatori di distanza GIS (utilizzata in un gruppo di nostre app)

Per le cose CRUD che occupano il 70-80% della maggior parte delle app, non credo proprio che la riusabilità sia una metrica preziosa.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.