Come progettare attorno a librerie non modificabili e non robuste?

6

Per iniziare, mi è stato assegnato il compito di automatizzare uno strumento di produzione significativamente obsoleto. Lo strumento e la sua API e il software non sono praticamente supportati ora. Ho una raccolta di documenti che descrivono ciò che equivale a un manuale per l'operatore del software e un livello introduttivo dell'API. Sono arrivato fin qui compilando queste informazioni, insieme ai file .h (la maggior parte dei quali non è stata fornita dalla documentazione).

Tuttavia, ho raggiunto un punto in cui l'API non ha un modo (noto) per misurare o tenere traccia dell'avanzamento di un'azione integrale. Sono stato in grado di caratterizzare le funzioni correlate nell'API abbastanza bene e in circostanze ideali, potrei probabilmente produrre le azioni desiderate, tuttavia ritengo che ciò lasci un'enorme vulnerabilità agli errori o quasi a tutto ciò che non è esattamente ciò che è previsto. Questo è quello che cerco di migliorare.

Più specificamente, l'azione di caricamento dello strumento è affidabile in determinate condizioni, ma non ho modo di discernere, a livello di codice, quando l'azione è completa o è il risultato. Sovrastimando il tempo, posso rendere il processo riuscito per la maggior parte del tempo, ma non ho modo di sapere se l'azione è fallita (ad es. Quando l'input si esaurisce).

La mia domanda è come aumentare la robustezza del mio programma, quali principi implementare o quali risorse potrebbero essere in grado di fornire alcune informazioni su questo problema.

Nota: sono più che felice di fornire ulteriori informazioni se necessario / utile.

    
posta rtmh 03.08.2016 - 22:56
fonte

1 risposta

13

Alcune cose che puoi fare:

  • Implementa Façades / wrapper per effettuare chiamate interne nell'ordine in cui l'API si aspetta.
  • Aggiungi un sacco di errori / gestione delle eccezioni ai wrapper
  • Disinfetta il più possibile i dati di input
  • Aggiungi funzionalità di registrazione ai wrapper
  • Crea un laboratorio di test quando esegui test certificabili, analizzando gli input e i risultati.
  • Alcuni ingegneri eseguono il reverse engineering dello strumento per ottenere la conoscenza dei meccanismi interni, dei segnali, ecc.

Tutto ciò che è solo workaround e scafolding, il vero lavoro è un lavoro di medicina legale, test in ambienti controllati.

Infine:

  • Riesci a riscrivere l'API?
  • Il produttore dello strumento non è più in attività?
  • Offrono una versione più recente e supportata dello strumento e la sua API?
  • C'è una terza parte che il produttore originale fornisce supporto?

Sinceramente, questa API controlla uno strumento di produzione, gli errori causano la perdita di materiale e / o incidenti alle persone che lavorano con tale strumento quando testano le nuove funzionalità programmate per tale API.

A volte un'azienda deve passare alle nuove tecnologie.

    
risposta data 04.08.2016 - 14:05
fonte

Leggi altre domande sui tag