Non inventato qui - cosa serve per non soccombere ad esso?

6

Inizierò con uno, che tuttavia non ha funzionato come volevo.

Valutazione del fornitore:
All'inizio del progetto, abbiamo dedicato del tempo a fare un sondaggio di librerie open-source esistenti che possono essere utilizzate come blocchi di costruzione per una biblioteca più grande. Nonostante i nostri sforzi, c'erano un certo numero di biblioteche che non abbiamo incontrato fino a diversi mesi nel progetto. Se avessimo scoperto quelle librerie mancanti prima, avremmo potuto prendere le nostre decisioni di progettazione in modo diverso.

Compatibilità dell'architettura:
È stato capito fin dall'inizio che nessuna singola libreria poteva soddisfare tutti i requisiti, quindi sono necessarie diverse librerie esistenti e alcune implementazioni personalizzate per colmare le lacune. Queste librerie dovrebbero essere racchiuse in un'unica architettura in modo che gli utenti non abbiano bisogno di conoscere la costruzione interna della libreria. L'efficienza (in molteplici aspetti, che può essere riassunta come "nessun tempo di CPU, RAM o spazio su disco può essere sprecato") è stata la principale forza trainante nella progettazione architettonica; quindi i wrapper devono essere ugualmente efficienti. All'inizio non sapevamo quale libreria open-source sarebbe compatibile con il design (nel senso che il wrapper non introduce alcuna inefficienza propria), in quanto ciò avrebbe richiesto un lavoro pionieristico per scoprirlo.

Qualità del codice:
Una delle librerie open-source aveva circa 20 anni. Un'altra biblioteca aveva circa 10 anni. Nel pensiero prevalente della libreria open-source, la vecchia libreria dovrebbe essere più stabile e avere meno bug. Alla fine abbiamo scoperto che era vero il contrario, e alla fine abbiamo dovuto risolvere un certo numero di bug nella vecchia libreria.

La mia ipotesi originale è che "ci vuole molta intelligenza per non soccombere a esso? Ci vuole molta esperienza?" ma dopo aver esaminato il progetto, sono arrivato alla conclusione che il riutilizzo del software è come il matchmaking - qualsiasi nozione di "opportunità mancata" si verifica naturalmente a causa del caso, e nessuna quantità di sforzo intenzionale ridurrà le opportunità mancate.

Che cosa serve per non soccombere alla sindrome di Non inventato qui, al fine di ottenere il più alto grado di riutilizzo del software e allo stesso tempo soddisfare perfettamente i requisiti del software?

Aggiunto (2010/12/18)

Uno dei motivi per cui abbiamo perso una buona libreria di candidati è che è stato escluso molto presto. Quando ci sono più di 10 biblioteche nella lista iniziale, c'è una certa pressione per trovare regole che possano eliminare rapidamente alcuni dei candidati, perché altrimenti avremmo speso troppo tempo ad analizzare (paralisi dell'analisi). Tuttavia, questa eliminazione rapida ha causato l'indesiderabile effetto di rifiutare una buona libreria. (proprio come l'assunzione?)

    
posta rwong 09.12.2010 - 08:41
fonte

4 risposte

2

Normalmente optare per librerie consolidate, ben testate e documentate a condizione che:

  • I termini di licenza sono gradevoli e compatibili con tutto il resto che sto utilizzando
  • La libreria viene mantenuta attivamente

Nel tuo caso, sembra che tu ti sia imbattuto in alcuni bit che semplicemente non sono stati più mantenuti. Ciò non significa che il codice non è stato utile, se ti ha fornito un buon punto di partenza per raggiungere i tuoi obiettivi .. significa semplicemente che uno sforzo maggiore di quello previsto era dovuto iniziare a usarlo. Questo sforzo eccede ciò che sarebbe necessario per scrivere la biblioteca da zero? Se è così, probabilmente hai fatto una brutta telefonata. In caso contrario, ti ha fatto risparmiare tempo e denaro.

Sono abbastanza fortunato da lavorare solo con sistemi operativi open source come UNIX, quindi per me è semplicemente una questione di cosa mi porta all'obiettivo finale con il minor numero di resistenze, senza compromettere i principi di progettazione del progetto.

Inoltre, penso che ogni programmatore abbia una cassetta degli attrezzi con molti scaffali. Le librerie che hai appena corretto, ad esempio, possono probabilmente essere riutilizzate, aumentando così il loro valore a lungo termine.

Detto questo, sono attualmente in procinto di re-inventare alcune ruote .. ma solo perché lo sforzo necessario per aggirare ciò che non mi piace in quello che esiste supera lo sforzo necessario per implementare qualcosa per conto mio. Ad esempio, potresti codificare su un'architettura molto specifica ... e potresti fare MOLTO bene senza un po 'di portabilità kruft.

Sono noto per aver iniziato un po 'a rallentare inizialmente, dedicandomi molto tempo per assicurarmi che non rimpiangerò la decisione di oggi tra qualche mese. Se sospetto strongmente che mi pentirò non solo di mordere il proiettile e di implementare qualcosa da zero, lo farò felicemente.

    
risposta data 09.12.2010 - 09:02
fonte
6

Joel ha scritto un bell'articolo su questo:

link

Come riepilogo rapido, se fa parte del tuo core business, scrivilo tu stesso, se non compralo.

    
risposta data 09.12.2010 - 13:52
fonte
0

L'età del codice non è importante quanto la manutenzione del codice. Se a nessuno importa ora, quando hanno loro?

Se raccogli un progetto non curato, finisci, come hai fatto tu, per mantenerlo da solo. Cerca quelli con una comunità vivace e grande. Ho avuto una buona esperienza con i progetti Apache Jakarta e in qualche modo con i progetti Eclipse, oltre a diversi progetti individuali.

    
risposta data 09.12.2010 - 09:53
fonte
0

Avevo un membro del team che era fermamente convinto che dovevamo scrivere il nostro sistema (un motore 3D) da zero nonostante avessimo identificato un motore che il team conosceva e che avrebbe fatto per lo più. L'ho preso da parte e gli ho chiesto se era pronto ad assumersi la piena responsabilità per il fallimento del progetto se non fosse stato in grado di consegnare il suo motore in tempo. Lui non era.

    
risposta data 25.12.2010 - 07:48
fonte

Leggi altre domande sui tag