Buone pratiche per il team di sviluppo in progetti di grandi dimensioni

Ecco come codice in C (sia da solo che in gruppo):

step 1. Understand the project
step 2. break the project into modules(each module has a separate folder)
step 3. break the modules into sub-modules(each sub-module is a .c/.h file pair)
step 4. write a manually desined "make" script. This step sounds ridiculous but it helps. Trust me.
step 5. learn to use a version control system
step 6. test-modify-debug-release. Release early and release often
step 7. think of improvements to the existing code
step 8. go back to the drawing board. 

Ad esempio (molto grezzo, in cima alla mia testa esempio):

You're designing an elevator simulation program. 
STEP1: Understand. [we got floors, floors can have people, people press buttons.. etc]
MODULES: 
      AI-Module[double-elevator single switch requires AI algos to decide which request is going to be addressed first and which elevator will service the request, depending upon the current position of both elevators]
     Interior-Electronics Module[To handle inter-elevator requests]
     Exterior-Electronics Module[To handle external-elevator requests]
     Human-Simulator Module[To simulate humans inside/outside the elevator(required to check overload)]

SUB_MODULES:
     AI-Module/ai.c, AI-Module/ai.h, AI-Module/decision_engine.c, AI-MODULE/decision_engine.h
     Interior-Electronics/press_button.c,Interior-Electronics/press_button.h, Interior-Electronics/delegates.c, Interior-Electronics/delegates.h
     Exterior-Electronics/press_button.c,Exterior-Electronics/press_button.h, Exterior-Electronics/delegates.c, Exterior-Electronics/delegates.h
     Human-Simulator/human_sim.c, Human-Simulator/human_sim.h
     ./manager.c ./manager.h ./main.c

E i passaggi seguono: -)

Una delle cose più importanti oltre alle linee guida per la codifica, i sistemi di controllo delle versioni, i flussi di lavoro e un sacco di caffè è:

Comunicazione.

Tu e i membri del tuo team devi comunicare tra loro. Indipendentemente se la domanda potrebbe essere stupida, chiedere se in dubbio. Parla in caso di dubbio. Parla se non c'è dubbio. Parla, parla, parla.

Avere prototipi di funzione e strutture dati nell'intestazione e il codice nel file sorgente è sempre una buona idea. Per una struttura ancora più ampia potresti dividere alcuni aspetti dei tuoi progetti in sottoprogetti (se lo desideri).

E ovviamente un sistema di bugtracker e ticket come Redmine o Bugzilla è altamente raccomandato.

Modularizzazione C

Esiste un classico documento sulla modularizzazione chiamato " sui criteri da utilizzare in scomposizione Systems Into Modules. "In breve, i criteri sono quelli di rendere una scomposizione orientata ai dati, non orientata dal punto di vista funzionale del progetto, e di utilizzare le metriche per giudicare il successo dal modo in cui pochi moduli devono essere toccati per miglioramento.

C è un linguaggio di programmazione strutturato e alcuni concetti chiave includono la creazione di basso accoppiamento (evitando globals e utilizzando i parametri) e alta coesione (raggruppando insieme funzioni e dati strettamente correlati).

Per C, cosa descrivi per separare la .h ( dichiarazione ) da .c ( definizione, anche chiamata implementazione) è buona. Alcune considerazioni pratiche si presentano con i file .c / .h, ma generalmente i file .h dovrebbero includere pochissime variabili globali (ad esempio estensioni) e prototipi solo per quelle funzioni che verranno utilizzate al di fuori di .c.

Ci sono molti programmatori C che parlano non usano analisi strutturate o design. Le Best Practices una volta riguardavano la creazione di un diagramma Structure che rompesse il problema per cui un programma era stato progettato per risolversi in una scomposizione funzionale top-down, trasformata in un albero di moduli usando una tecnica chiamata transform analysis. Questo non è più considerato la migliore pratica, perché la decomposizione orientata ai dati e orientata agli oggetti si è dimostrata superiore. Tuttavia, i programmatori C spesso trovano ciò che fanno per adattarsi al design orientato agli oggetti, in quanto le caratteristiche del linguaggio non si allineano.

Team Best Practices

Questo è l'argomento di interi libri. Watts Humphrey ha scritto un rapporto tecnico chiamato " Il processo software del team " che è un classico e un download gratuito. Scorri solo le pagine 4-6 e 15 per avere una panoramica veloce di ciò che è importante per la squadra e la sua leadership. Altre parti del documento ti dicono molto sulle aspettative delle metodologie pianificate in termini di documentazione, inclusa la produttività e la misurazione della qualità.

Il tuo team può scegliere un modello di ciclo di vita pianificato (più tradizionale cascata, spirale o sviluppo orientato alle funzionalità) o Agile (iterativo / incrementale o forse snello). Entrambi avranno molti processi che si sovrappongono, anche se potrebbero non essere praticati esattamente nello stesso modo: documentazione, controllo del codice sorgente, tracciamento e pianificazione integrati con database ed editor di grafici, test e qualche tipo di revisione tra pari.

Se pensi

Stiamo scoprendo modi migliori per sviluppare software eseguendolo e aiutando altri a farlo.

dovresti considerare cosa stanno dicendo i ragazzi di Agile perché il processo di squadra si concentra su Scrum o eXtreme Programming (XP) , è più tardi e reagisce a ciò che le persone pensavano non funzionasse prima.

La cosa importante da menzionare è spirito di squadra, comunicazione e approccio per eliminare il ufficio tecnico / gap che i membri del team possono sapere / avere. Ecco alcuni suggerimenti che puoi prendere in considerazione e seguire:

• Porta un flusso continuo di nuove conoscenze in . Una volta alla settimana dovresti avere qualcuno da fuori che parli per un'ora su un argomento tecnico. Fornisci cibo e fai uno sforzo per ottenere buoni oratori. Coinvolgi le persone della tua organizzazione di sviluppo sorella e completamente fuori dalla tua azienda o da un altro progetto. Quando porti le persone, chiedi loro chi sta facendo il lavoro più interessante relativo al tuo progetto o area di competenza. Questo processo ti aiuterà a sviluppare conoscenze e abilità nel tuo gruppo e alla fine ti collegherà agli esperti del mondo in qualunque cosa tu stia facendo.

• Hai membri del team che parlano almeno una o due volte al mese. Se stai costantemente ricercando le migliori pratiche e hai successo, alla fine dovrai chiedere più risorse o chiedere ad un team di sviluppo di adottare il tuo lavoro. Più persone hai che possono parlare in modo articolato del lavoro, maggiori sono le tue possibilità di successo.

• Avere incontri brevi e frequenti il cui obiettivo principale è mantenere l'intero team connesso . Quando gestivo un gruppo di 6-8 persone costruendo un compilatore, ci siamo incontrati due volte a settimana per 45-90 minuti. Tutti compresi me, ho parlato di cosa hai fatto dall'ultimo incontro, cosa speri di ottenere dal prossimo incontro e quale sarà il prossimo passo che farai oggi ( ovvero, la metodologia Scrum delle riunioni quotidiane di stand-up ). Queste riunioni hanno offerto tre obiettivi:

  1. Tenuto tutti a conoscenza del grande quadro della squadra.

  2. Abilitato le persone junior a imparare dalle persone anziane.

  3. La gente si è scollata rapidamente, prima che uscisse dai binari.

È un grande privilegio essere in una grande squadra, imparare le buone pratiche l'una dall'altra e avere voce in capitolo nell'impostare la propria direzione!

Quando dividere il codice sorgente C in più file:

• Quando il tempo di compilazione inizia a rallentare. Solitamente il compilatore crea solo i file sorgente che sono stati modificati. Se metti tutto in un c + h duo, il compilatore compilerà sempre tutto.
• Quando lavori con più di uno sviluppatore contemporaneamente sullo stesso progetto. Indipendentemente dal fatto che si utilizzi o meno un sistema di controllo versione, non è conveniente quando due sviluppatori desiderano modificare lo stesso file sorgente. Questo è un motivo valido per raggruppare le funzioni in parti che appartengono insieme e dividere in file separati di conseguenza.