tre progetti sovrapposti - come organizzare

3

Al momento sto sviluppando in parallelo tre progetti software scientifici (visione computerizzata) in Python e mi graffio la testa sull'organizzazione, sul codice pulito e sulla facilità di estendibilità / mantenimento del codice.

Una domanda che ho è se mantenere tutti o tre i progetti separati o no? Condividono funzioni simili, che ho pensato di raccogliere in un'API condivisa (con molti argomenti). O dovrebbe mantenere i progetti completamente separati, il che significa che finisco con il codice ridondante che di solito non è raccomandato.

Ho una funzione per impilare le immagini. Questa funzione è utilizzata in tutti e tre i progetti.

def stack_images(img_lst):
    # do some stacking of the img_lst with algorithm_max
    return stacked_image

Ora in uno dei progetti ho bisogno di un altro algoritmo per l'impilamento, chiamiamolo algoritm_min ma il resto del codice all'interno della funzione non cambierà. Dovrei aggiungere l'algoritmo come argomento o dovrei scrivere tre funzioni stack_images, una per ogni progetto, che può essere facilmente adattata alle esigenze di ogni progetto?

Le mie paure per la prima opzione, è molto probabile che io debba apportare piccole modifiche di tanto in tanto, il che significa che in un anno potrei finire con molti argomenti.

Le mie paure per la seconda opzione, se cambio qualcosa di fondamentale nella mia funzione che riguarda tutti e tre i progetti, devo cambiare il codice su tre punti (che sono sicuro che presto o tardi mi dimenticherò di farlo per l'altro progetti).

Secondo esempio, devo cambiare gli spazi colore delle mie immagini tutto il tempo. Questa è una riga di codice in opencv:

# RGB to HSV 
hsv_image = cv2.cvtColor(img, cv2.COLOR_RGB2HSV)
# RGB to LAB 
lab_image = cv2.cvtColor(img, cv2.COLOR_RGB2LAB)

Ora, dovrei scrivere una funzione con lo spazio colore come argomento o per ogni spazio colore una funzione separata? Devo testare queste funzioni di base (non è esagerato?)

    
posta snowflake 28.02.2017 - 15:19
fonte

2 risposte

2

Prova a leggere su metodi agili (mi è piaciuto "Continuous Delivery" - ma per ora potrebbe essere un passo troppo lungo)

Se è presente un codice condiviso significativo, implementare una libreria back-end condivisa. Probabilmente hanno questo sotto controllo di configurazione separato perché prima o poi uno dei progetti correrà davanti agli altri. Vuoi essere in grado di specificare quale versione della libreria vuoi caricare.

Un'API con "molti" argomenti sembra una cattiva idea. I "molti" mi rendono nervoso.

Separare il progetto di test per le cose sperimentali?

Molte piccole classi sono la strada da percorrere. Test unitario pesantemente. Automatizza il test di sistema il più possibile. Favorisci le semplici funzioni pulite.

Non esagerare nella documentazione. Preferirei un piccolo documento di panoramica e poco altro, ma codice sorgente pulito e test di unità abbondante.

fai hai il controllo della configurazione, vero?

    
risposta data 28.02.2017 - 16:22
fonte
1

Questo è un luogo comune in cui intervenire quando si inizia un progetto di nuovo ambito. Libri come codice completo e Il programmatore pragmatico aiuta a chiarire queste situazioni. Suggerirei di guardare un metodo come " punti elenco di riferimento ".

In sostanza, non cercare di rendere il tuo progetto perfetto. Mira a dove pensi di voler colpire e regola l'obiettivo se noti che ha bisogno di essere aggiustato. Soprattutto quando lavori nelle scienze, WILL ha requisiti in evoluzione nel corso del progetto. Sovrastimare un nuovo progetto come questo nelle sue fasi iniziali ti consentirà solo di sprecare lavoro e di progettarti in un angolo.

Funziona per prima cosa, segui principi sani come tenere le cose semplici e piccole e rifattorici se le cose cominciano a diventare confuse. BACIO

    
risposta data 01.03.2017 - 21:05
fonte