Uso della compilazione / inclusione di funzioni condizionali per il controllo delle versioni

Question

Uso della compilazione / inclusione di funzioni condizionali per il controllo delle versioni

#1 da (1 voti)

1

Ho giocato con la seguente idea: comunemente quando diverse serie di versioni (1.0.x, 1.1.x, codice di sviluppo) di un prodotto sono mantenute in parallelo, si utilizzano diversi rami all'interno di un sistema di controllo della versione per svilupparli. In teoria, però, si potrebbero usare macro di funzionalità (scritte da un punto di vista C / C ++, ma l'idea dovrebbe essere portabile) per abilitare o disabilitare particolari funzionalità basate sulla versione che si sta costruendo. In C / C ++ questo probabilmente significherebbe racchiudere il codice per le nuove funzionalità in #ifdef FEATURE_X e abilitarle o disabilitarle sulla riga di comando di build o avere un file di intestazione principale contenente un codice come

#if version > 101
# define FEATURE_X
# define FEATURE_Y
#endif

Le funzionalità di back-porting, se necessario, potrebbero essere eseguite riorganizzando questo file.

L'idea alla base di questo è che normalmente si vorranno ripristinare e correggere correzioni che non fanno parte di nuove funzionalità significative per le versioni precedenti a meno che non si abbia una ragione specifica per non farlo. Tuttavia, questi back-ports sono spesso eseguiti in modo piuttosto casuale, con conseguenti sottili differenze non intenzionali tra versioni o correzioni dimenticate in alcune versioni. L'approccio macro delle funzioni inverte le cose, effettuando il back-porting delle sezioni di codice di default e di marcatura esplicita che non sono per il back-porting. Anche se non sarebbe un proiettile d'argento in alcun modo, potrebbe migliorare il livello di stabilità che si otterrebbe con una determinata quantità di test. Mi aspetto anche che migliori la struttura del codice forzando la separazione più pulita di diverse funzionalità.

Quindi la domanda: qualcuno conosce i dati del mondo reale su questo o simili approcci?

testing version-control project-management development-process programming-practices

posta michaeljt 26.01.2015 - 11:26

fonte

1 risposta

Leggi altre domande sui tag testing version-control project-management development-process programming-practices

Asp.Net MVC da in bootstrap modale PHP MVC Visualizza molti record - logica del modello

score 1 · Accepted Answer

È più comune utilizzare il branching del controllo sorgente per controllare quali funzioni sono disponibili all'interno di una particolare versione del software.

Detto questo, le applicazioni che offrono funzionalità a livelli all'interno dello stesso livello di versione a volte utilizzano la tecnica che descrivi. Di solito, vedrai due usi principali delle definizioni condizionali. I primi usi di #define s dichiarano la funzionalità di livello per la build di quel livello. Il secondo utilizzo è in tutto il codice in cui la funzionalità per-livello deve essere effettivamente abilitata.

In altri casi, è possibile mantenere la compatibilità con le versioni precedenti su una modifica che altrimenti si interrompe utilizzando #define s e la versione dell'applicazione. Ciò diventa un po 'più complicato e produce codice meno facile da mantenere, ma è un modo conveniente per tenere insieme tutto il codice rilevante in un singolo ramo. Lo sviluppatore deve ricordare di ripristinare il numero di versione quando crea una speciale build compatibile con le versioni precedenti, ma consente al codice precedente di rimanere in linea con il resto del codice sorgente.