Quali consigli (consigli, tecniche, trucchi, eccetera) hai per qualcuno che sta effettuando il porting di una libreria di codici da una lingua a un'altra, o riscrivendola per funzionare in un compilatore diverso, ambiente?
Ogni piattaforma (lingue e librerie di sistema) ha una sua personalità. Il modo in cui un programmatore Ruby progetta le proprie API sfrutta le caratteristiche e la cultura uniche che rendono Ruby quello che è. Questo è chiaramente diverso dal modo in cui uno sviluppatore C o C ++ progetterà la propria API, che a sua volta è diversa dal modo in cui uno sviluppatore Java o C # potrebbe farlo.
Vuoi prendere le idee dalla piattaforma originale e modellarle nei concetti che rendono la nuova piattaforma quello che è. Nulla è meno naturale dell'utilizzo di una libreria progettata in modo completamente diverso rispetto alle altre librerie della piattaforma. C'è un certo numero di piattaforme di programmazione che sono in realtà ben progettate ed eleganti. Vuoi sfruttare quei punti di forza per la tua porta.
Conoscere le capacità native del linguaggio / framework "a" e "da".
Stavo eseguendo il porting di una libreria di calendari su iOS da Javascript. iOS ha una robusta classe di calendario, mentre JavaScript non aveva nulla di utile per me. (Stavo convertendo da un calendario religioso al calendario gregoriano e viceversa.)
Ho dedicato del tempo a riscrivere l'intera libreria in Objective-C solo per rendermi conto che il mio codice era ampiamente ridondante. (A proposito, ho fatto uno scarso lavoro e ho ottenuto risultati inaccurati, quando ho fatto un passo indietro e ho realizzato il mio errore.)
Diverse decine di linee di metodi di conversione erano sostituibili con sei o più righe di codice framework nativo.
Se questo è un progetto critico (il porting è spesso), scrivi un piano di test completo (idealmente con i test unitari nella lingua di arrivo) PRIMA di eseguire il porting di ogni parte di codice e dell'intero sistema.
Non c'è modo al mondo che il porting sia accurato al 100% al primo tentativo, quindi devi assicurarti in anticipo che stai catturando tutto.
Se possibile, esegui lo stesso piano per il codice originale perché non ci sono garanzie che sia stato scritto correttamente e, in effetti, avere un comportamento equivalente può dipendere da un'implementazione scorretta.
- > Concentrati sulla funzionalità e non sul modo in cui è stata codificata.
- > Pensa prima di scrivere, perché alcuni elementi possono essere già gestiti dalla lingua, dalla piattaforma, ecc.
- > Utilizza il vantaggio della nuova piattaforma.
"Porting" - come sembra che tu stia usando la parola - è solo TDD con fastidioso codice legacy.
Ottieni correttamente i casi di test. Conferma che il codice legacy supera i casi di test.
Quindi scarta il codice legacy.
Quindi scrivi un nuovo codice che passa i test case nella nuova lingua.
Costruisci un diagramma di classi / un albero gerarchico in modo che tu sappia quale porta per primo. Mappare i tipi di dati di base (int - > Int32?). Fai lo stesso per le strutture dati.
Leggi altre domande sui tag porting