Sistema disaccoppiato nei luoghi sbagliati: meta-problema? [chiuso]

Question

Sistema disaccoppiato nei luoghi sbagliati: meta-problema? [chiuso]

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

7

A livello meta, spesso scopro che quando coltivo una base di codice organicamente, parti del sistema che alla fine trovo devono conoscersi l'un l'altro (almeno attraverso qualche interfaccia) sono state disgiunte senza pietà. Ciò si verifica spesso nel codice del prototipo di ricerca, in cui si tende a pensare spesso a ritocchi e piccoli miglioramenti che non erano previsti nella base di codice originale.

Di solito, alcune impostazioni o parti di dati devono essere scandite attraverso circa 15 milioni di livelli di chiamate di funzione in modi che non ho mai previsto quando ho progettato il codice. Questo porta a un terribile dilemma:

Usa un brutto trucco. Questa può essere un'altra variabile globale, avviando i dati su una classe a cui chiaramente non appartiene, mettendo una serie di istruzioni di stampa nel mezzo di codice che in precedenza non aveva nulla a che fare con la logica I / O, facendo un apparentemente semplice compito in maniera molto rotonda per farlo rientrare nella mia base di codice originale, ecc.
refactoring della chirurgia shotgun. Questo quasi mai viene fatto in pratica, perché il codice dovrà probabilmente essere riscritto in ogni caso se è di diventare qualità di produzione, è stato difficile lavorare per la prima volta, è difficile da testare, o ho semplicemente priorità più alte rispetto a scrivere pulito, codice mantenibile quando o ho una scadenza o so che per ora è solo un prototipo. Inoltre, il prossimo tweak potrebbe rompere qualsiasi bella astrazione che mi viene in mente.

Esistono buoni meta-suggerimenti o principi di progettazione che mi aiuteranno a evitare situazioni come questa in primo luogo? Sono NON in cerca di risposte che raccomandino semplicemente il refactoring dopo il fatto, poiché una sessione di refactoring della chirurgia da incubo è esattamente il tipo di cosa che sto cercando di evitare.

object-oriented design design-patterns

posta dsimcha 19.10.2010 - 23:30

fonte

3 risposte

Leggi altre domande sui tag object-oriented design design-patterns

Ci sono documenti accademici sui meriti della programmazione funzionale eccessiva? Dove dovrebbero essere conservati gli asset di sviluppo pesanti come i documenti delle specifiche e i file sorgente dell'editor multimediale?

score 2 · Answer 1

Tre cose che trovo utili, ma alcune persone non le piacciono:

Considera il codice del prototipo iniziale - se stai facendo qualcosa di molto diverso da quello che hai fatto in passato, è probabile che il primo tentativo ti insegni che avresti dovuto farlo in modo diverso all'inizio - elaborare le tue idee e ricominciare da capo

Ridurre al minimo il disaccoppiamento iniziale: per me è molto più facile rifattorizzare qualcosa da uno scenario accoppiato, una volta che ho una buona ragione che fare i giocolieri con un confine arbitrario di disaccoppiamento precoce.

Considera di avere meno livelli o di consentire alle funzioni di saltare i livelli. In alcuni progetti, quest'ultimo può avvicinarsi a una necessità, a volte.

score 1 · Answer 2

L'uso di un framework di dipendenze per l'iniezione può aiutare con l'aggiunta di nuove dipendenze senza l'utilizzo di variabili globali o il passaggio di valori attraverso una serie di chiamate di metodo. Un framework AOP può aiutare a implementare nuove preoccupazioni trasversali.

Ad esempio, la registrazione può essere ottenuta tramite AOP e / o un oggetto di registrazione che può essere iniettato su qualsiasi livello.

Un esempio di un framework che fornisce entrambi questi concetti è Spring.

EDIT: So che il commento qui sotto è contro l'idea di più dipendenze, ma ho trovato questo per Python: Spring Python

score 0 · Answer 3

Penso che, come molte altre cose in programmazione, hai bisogno di equilibrio.

Trova una soluzione che sia abbastanza buona e che non richieda troppo lavoro (in quanto è comunque un prototipo e probabilmente cambierai molte altre cose). Poi, quando hai finito per completare le cose, puoi provare a vedere dove può essere reso veramente buono.

Non lesinare troppo sulla parte abbastanza buona, se il tuo codice è troppo cattivo (di solito penso che aggiungere una variabile non sia un problema, il grosso problema è la mancanza di struttura) non vedrai il bene cambiare ciò che deve essere fatto in seguito.

Penso che finché mantieni una struttura abbastanza chiara nel tuo design, il resto non è molto importante in quanto sarà facilmente refactored in seguito.

Di nuovo, alla fine, sei il programmatore e tu sei l'unico responsabile di prendere la decisione giusta per quanto riguarda la chiarezza del codice, il tempo di implementazione, ecc. Non provare ad adattare una regola di misura unica se pensi che non funzionerà.