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é?
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é?
Risposte:
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.
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.)
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
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.
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.
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.
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
Roba di utilità
Per le cose CRUD che occupano il 70-80% della maggior parte delle app, non credo proprio che la riusabilità sia una metrica preziosa.