Gestione del progetto e le dipendenze bundling

Question

mi è stato alla ricerca di modi per conoscere il modo giusto per gestire un progetto software, e ho inciampato sul seguente post sul blog. Ho imparato alcune delle cose che parlano del modo più duro, altri hanno senso, e altri ancora sono ancora poco chiari a me.

In sintesi, l'autore elenca una serie di caratteristiche di un progetto e quanto queste caratteristiche contribuiscono a un progetto di 'suckiness' per la mancanza di un termine migliore. Potete trovare l'articolo completo qui: http://spot.livejournal.com/308370.html

In particolare, non capisco la posizione dell'autore in bundling dipendenze con il progetto. Questi sono:

== Bundling ==

• La vostra fonte arriva solo con altri progetti di codice che dipende da [+20 punti di FAIL]

  Perché questo è un problema, soprattutto in considerazione al punto 3, che sono stati modificati i vostri progetti dipendenze per soddisfare le esigenze del vostro progetto, non è vero quindi rendere ancora più senso che il codice dovrebbe essere distribuito con le sue dipendenze?

• Se il codice sorgente non può essere costruito senza prima costruire i bit di codice in bundle [+10 punti di FAIL]

  Questo non deve necessariamente essere il caso per il software integrato contro 3rd librerie di partito? Il codice deve che altro codice per essere compilato in sua biblioteca prima che il linker può funzionare?

• Se hai modificato gli altri bit di codice in bundle [+40 punti di FAIL]

  Se ciò è necessario per il vostro progetto, allora ne consegue naturalmente che hai detto codice bundle con il vostro. Se si desidera personalizzare una build di alcuni lib, dire WxWidgets, dovrete modificare che gli script di build progetti a bulid la libreria che si desidera. Successivamente, dovrete pubblicare quei cambiamenti per le persone che desiderano costruire il vostro codice, quindi perché non utilizzare uno script make alto livello con i params già scritti in, e distribuire questo? Inoltre, (soprattutto in una finestra ENV) se la base di codice dipende da una particolare versione di un lib (che è anche necessario per la compilazione personalizzata per il vostro progetto), non sarebbe più facile per dare all'utente il codice da soli (perché in questo caso, è improbabile che l'utente avrà già la versione corretta installato)?

Quindi, come risponderebbe a questi commenti, e quali punti mi sia omettendo di prendere in considerazione? Sei d'accordo o in disaccordo con introito dell'autore (o la mia), e perché?

A cura di chiarimento.

Answer 1

  

La vostra fonte arriva solo con altri progetti di codice che dipende.

Il mio progetto richiede progetto X.

Tuttavia, dato che il mio progetto dipende segreti misteri interiori di X, o di una versione precedente di X, allora il mio progetto include una copia di X. In particolare rilascio N.m di X. E nessun altro.

Provare a installare la versione più recente X e vedere che cosa si rompe nel mio progetto. Dal momento che l'aggiornamento X ha rotto il mio progetto, dimenticare il mio progetto. Essi non lottare con qualcosa che si rompe spontaneamente dopo un aggiornamento. Troveranno un componente più open source.

Quindi un punteggio FAIL.

  

Se il codice sorgente non può essere costruito senza prima costruire i bit di codice in bundle.

Il mio progetto non si basa sulle API di X. Essa si basa sulla profonda, linking interno di parti specifiche di X, bypassando le API.

Se il mio progetto sul dipendeva l'API per X, poi - per alcuni linguaggi come C o C ++ -. Il mio progetto in grado di compilare con solo il C o C ++ intestazioni, non i binari

Per Java questo è meno vero, dal momento che non v'è, intestazione non binario indipendente. E per i linguaggi dinamici (come Python) questo non ha senso tecnico.

Tuttavia, anche Java e Python hanno modi a un'interfaccia separata da attuazione. Se mi baso su implementazione (non Interface), quindi ho ancora creato lo stesso problema essenziale.

Se il mio progetto dipende da C o C ++ binari, e costruire le cose in ordine, o aggiornare un altro componente senza ricostruire la mia, le cose possono andare male per loro. Possono vedere stranezze, rotture, "instabilità". Il mio compare di prodotti rotti. Non lo faranno (e non può) eseguire il debug. Hanno finito. Troveranno qualcosa di più stabile.

Quindi un punteggio FAIL.

  

Se hai modificato gli altri bit di codice in bundle.

Ho due scelte quando modifico X.

1. Get it accettato come parte di X.

2. Fissare il mio programma di lavoro con non modificato X.

Se il mio progetto dipende da una X modificata, non si può installare X semplicemente, in modo corretto e in modo indipendente. Essi non possono aggiornare X, non possono mantenere X. Probabilmente non possono applicare correzioni di bug o patch di sicurezza di X.

ho sostanzialmente fatto il loro lavoro impossibile modificando X.

Da qui il punteggio FAIL.

  

In seguito, dovrete pubblicare quei cambiamenti per le persone che desiderano costruire il vostro codice.

In realtà, loro mi odiano per questo. Non vogliono conoscere le misteriose modifiche X. Vogliono costruire X secondo le regole, quindi costruire la mia roba in base alle regole. Essi non vogliono leggere, pensare o essere sicuri che il kit di patch di aggiornamento mistero è stato applicato correttamente.

Invece di scherzare con quello, faranno scaricare un pacchetto in competizione. FAIL.

  

se il vostro codice di base dipende da una particolare versione di un lib (che è anche necessario per la compilazione personalizzata per il vostro progetto)

Questo è veramente squallido. Se io dipendo da una versione con compilazione personalizzati, hanno finito guardando il mio pacchetto. Troveranno qualcosa senza versione-specifici misteri interiori e compila personalizzati prima che avrete difficoltà. FAIL.