Come gestire le soluzioni alternative necessarie nel software?

3

Anche con specifiche dettagliate per lo scambio di dati tra programmi per computer, è probabile che i dati generati da vecchie versioni di programmi non siano conformi al 100% alle specifiche, o che utilizzino vecchie caratteristiche oscure che poche persone sanno come implementarle. Di conseguenza, le aziende devono conservare una libreria di "campioni strani" per testare il loro software.

Nella buona progettazione del software, queste stranezze possono essere confinate in un piccolo strato di librerie chiamate "Abstraction Layer". Tuttavia, la maggior parte degli strati di astrazione ha troncato troppe funzionalità (al fine di impedire al software di livello superiore di toccare le parti instabili del software di livello inferiore).

A volte non è possibile nascondere completamente le parti instabili. Quali sono le strategie per far fronte a tali soluzioni alternative necessarie?

((Per favore perdona le mie scarse competenze linguistiche.)

    
posta rwong 15.11.2010 - 04:10
fonte

4 risposte

1

Buona documentazione.

I commenti sul codice fanno molto per dire al prossimo sviluppatore perché l'hack è stato inserito lì, e perché deve rimanere.

Si spera che la ragione sia valida. Ad un certo punto, se si incorre in un debito tecnico sufficiente, dovrebbe essere preso in considerazione un refactoring.

    
risposta data 15.11.2010 - 04:21
fonte
1

I test di unità / integrazione possono essere usati per identificare quelle "caratteristiche" (se non possono essere rimosse). Allo stesso modo, gli stessi tipi di test possono testare il codice che consuma le librerie in questione per garantire che soddisfino il contratto di mis - comportamento.

    
risposta data 15.11.2010 - 05:29
fonte
1

Se i file di dati, prendere in considerazione la creazione di un modulo di traduttore o un programma separato che farà la traduzione per voi nel nuovo formato. Incorpora la conoscenza del vecchio - > nuovi formati in quel modulo e mantieni pulito il tuo codice attuale.

    
risposta data 15.11.2010 - 06:50
fonte
1

Sometimes it is not possible to completely hide away the unstable parts. What are the strategies for coping with such necessary workarounds?

È importante rendersi conto che il software continuerà a evolversi in futuro. Uno strato di soluzioni alternative oscure è tollerabile, ma i problemi reali emergeranno se inizi a creare soluzioni al di sopra di soluzioni alternative. Quindi il refactoring è assolutamente necessario prima che lo strato di soluzioni alternative vada a superare uno. Ovviamente sarebbe meglio farlo in modo pulito, ma semplicemente non è così nel mondo reale.

    
risposta data 15.11.2010 - 08:38
fonte

Leggi altre domande sui tag