In che modo i team di sviluppo software professionali affrontano la complessità del design in progetti non banali?

9

In primo luogo, mi rendo conto che questa domanda potrebbe essere alquanto lunga e vaga e mi scuso per questo. Questo è probabilmente un problema di base con un nome breve per chiunque abbia "capito", ma non trovandomi a questo riguardo, per favore, ricordati di descrivere il problema.

Ho fatto programmazione in questo modo o nell'altro da quando avevo circa 11 anni. Ciò significa che ho iniziato a insegnarmi tutto sin dall'inizio. Ho ricevuto una formazione tecnica, ma non strettamente in informatica (mi sono laureato in ingegneria fotonica). Avevamo ovviamente corsi di programmazione, ma per me questo era principalmente roba di base e non ho imparato molte cose nuove. Ho continuato a educarmi lungo la strada per la gioia di farlo e ho sempre saputo che avrei intrapreso una carriera nella programmazione, ma tutti i miei progetti erano piuttosto piccoli in quel momento. Non ho avuto problemi a tenerli nella mia mente ea mantenerli.

Ora, mi trovo ad essere il protagonista di un team, ma non in un ambiente aziendale - lavoro per l'università sviluppando software scientifico (in C ++) per applicazioni di ingegneria. All'improvviso il progetto sta crescendo (relativamente) grande e ho difficoltà a spostarmi la mente per la maggior parte del tempo. Sto perdendo molto tempo e impegno su due cose principalmente:

  1. Quando devo tornare a una sezione di codice su cui non ho lavorato per un po ', ho difficoltà a ricordare come funzionava. Trascorro molto tempo a rivedere i file di intestazione per le classi pertinenti e a leggere i commenti che ho inserito lungo il percorso nei file di origine. Vorrei che ci fosse una qualche forma di "schematico" che potessi intravedere e recuperare più facilmente l'immagine;
  2. Quando introduco i cambiamenti, a volte mi rendo conto a metà strada che ciò che sto cercando di fare andrà a finire da qualche altra parte (o peggio, si presenta solo a runtime come sorpresa). Io ripristino e inizio a farlo in modo diverso, solo per scoprire ho trascurato l'influenza su qualche altro componente. Vorrei che ci fosse un "diagramma di architettura" in cui ho potuto vedere come si fanno le cose, come quello che sto cercando di fare influenzerà altri componenti e un modo per pianificare in dettaglio prima di iniziare ad implementare le modifiche.

La maggior parte delle persone con cui lavoro ha storie simili a me: strong orientamento tecnico e talvolta grandi capacità, ma senza alcun modo di organizzare il proprio lavoro. Tuttavia, i loro progetti sono di solito molto più piccoli dei miei, quindi in qualche modo riescono a farcela. Ad ogni modo, ciò che significa per me è che sono da solo e non ho nessuno con cui imparare le buone pratiche.

Ho seguito un corso post-laurea nella gestione dell'IT e, mentre lo trovo abbastanza soddisfacente, è rivolto principalmente ai non programmatori, insegnando metodologie di project management, stime del budget / pianificazione, architettura aziendale ecc. come. Va bene, sto cercando di imparare anche quella roba. Ovviamente, sono stati introdotti alcuni strumenti (come UML) e i tipi di processi di sviluppo del software (a cascata, iterativo, agile ...), ma ovviamente non in grande dettaglio e ho difficoltà a decidere cosa dovrei scegliere e usare ( e fino a che punto).

Ho letto molte domande e risposte sulla progettazione del software su SO - ci sono molte cose sul farlo usando questo o quel particolare strumento o metodologia, e se fossi convinto che la documentazione UML avrebbe risolto i miei problemi - sceglieresti e iniziare a usarlo. Ma alcune persone lo giurano, altri dicono che è inutile. Sto cercando una risposta ad un livello più alto di astrazione - ci sono modi per risolvere i due problemi che sto avendo, e come lo fai personalmente? Cosa dovrei imparare per essere in grado di farlo, possibilmente senza essere legato a uno strumento particolare? Questi vanno e vengono di moda di volta in volta, e mi aspetto che la loro applicabilità vari a seconda del tipo di progetto.

Grazie mille per la lettura, non sono stato in grado di dire cosa intendo più brevemente (senza esperienza di progettazione del software e vocabolario).

    
posta neuviemeporte 21.05.2012 - 02:39
fonte

7 risposte

9

When I have to return to a section of code I've not worked on for a while, I have difficulty remembering how it worked. I spend a lot of time reviewing the header files for the relevant classes and reading the comments I placed along the way in the source files.

Immagina come si sentirà il povero ragazzo che viene dopo di te - non ha nemmeno il vantaggio di avere una volta saputo come funziona il tuo codice. Invece di provare a decifrare il tuo codice, dovresti esaminare la documentazione che hai scritto per il modulo in questione. Tale documentazione dovrebbe offrire una visione ragionevolmente accurata di ciò che fa il modulo ogni perché. Non è "il modulo inizia inizializzando tre array usando una tripla per loop ...", ma invece: "questo modulo recupera i dati raccolti dal sensore principale di Fabulotron, riorganizzandolo nel formato standard di Neopolitan (cioccolato, vaniglia, fragola), e lo consegna al modulo di analisi. "

In un mondo perfetto, avresti un documento di progettazione che definisce i vari moduli nel sistema e descrive le rispettive responsabilità, e ognuno dei tuoi moduli potrebbe semplicemente riferirsi a quel documento per spiegare cosa fanno: "Questo modulo fornisce il servizio di raccolta dati Fabulotron come descritto nella sezione 4.8 del documento di progettazione: link . " Se non hai qualcosa del genere, inizia a scrivere una panoramica di ogni modulo mentre ci lavori. Non è necessario scrivere un libro - alcuni paragrafi sono spesso sufficienti per orientarti.

When I introduce changes, sometimes I realize half-way that what I'm trying to do will break things somewhere else (or worse, it shows up only at runtime as a surprise). I revert and start doing it differently, only to find out I neglected the influence on some other component.

Potrebbe essere un'indicazione che i tuoi moduli sono troppo interconnessi. Più indipendente è possibile creare moduli / classi / unità, meno è probabile che si verifichi questo tipo di problema. Cerca di rendere le interfacce tra i moduli più esplicite possibile e cerca di limitarle a ciò che deve essere lì. Un'interfaccia è un contratto - se sai che alcuni moduli sono all'altezza dei suoi obblighi come specificato nell'interfaccia, non devi sapere nient'altro a riguardo. Ciò impedisce alle modifiche nel modulo su cui stai lavorando di influenzare altri moduli.

I wish there was some "architecture diagram" where I could see how things get done

L'uso di parti standard può aiutare in questo senso. C ++ fornisce parti standard sotto forma di libreria di modelli standard e l'utilizzo di tali parti, laddove appropriato, consente di lavorare a un livello più alto di astrazione. Se hai scritto il tuo codice per gestire le strutture di dati come le liste, tu e coloro che seguiranno dovrai costantemente leggere la fonte per capire cosa sta succedendo. Se invece si utilizzano parti standard fornite da STL, qualsiasi programmatore C ++ sarà in grado di dire rapidamente cosa sta facendo il codice senza scavare nelle routine di gestione dei dati.

Un altro tipo di parte standard deriva da modelli di design. Sono concetti standard che possono essere usati come una scorciatoia per spiegare come funziona la relazione tra due oggetti.

    
risposta data 21.05.2012 - 04:08
fonte
5

Sono solo stato uno sviluppatore professionista per un breve periodo di tempo e ho faticato molto su come farlo quando ho iniziato. Ero principalmente autodidatta, anche attraverso l'Università. Fortunatamente per me le persone con cui ho lavorato hanno molta esperienza e sono state in grado di educarmi sui modi di gestire e lavorare su grandi progetti.

Una delle prime cose che ho dovuto fare era sedermi e leggere codice pulito . Che è un libro fantastico che mi ha aiutato a capire come scrivere codice che potrei capire quando ci sono tornato o che qualcun altro potrebbe capire.

La seconda cosa era scrivere test di buona qualità, Unità, Integrazione, Accettazione. Se il tuo codice è ben testato, saprai subito quando hai rotto qualcosa e sarai in grado di diagnosticare rapidamente il problema. Ci sono un sacco di buone risorse di test là fuori su internet, e non sono sicuro quali siano le migliori per suggerirti.

I miei punti chiave sono Test e Clean Code.

    
risposta data 21.05.2012 - 03:13
fonte
2

Ecco alcune idee di alto livello per l'organizzazione di sistemi software di grandi dimensioni. La maggior parte della mia esperienza è nei sistemi internet, ma penso che queste idee si applichino al software di ingegneria.

  • Separa funzionalità in blocchi modulari relativamente isolati. Ad esempio, potresti avere un modulo per ogni famiglia di calcoli fornita dal software.
  • Applicare il modello di progettazione MVC per l'interfaccia utente, se disponibile. Mantieni l'interfaccia e il modello separati con confini ben definiti.
  • Considera l'utilizzo dei livelli per raggruppare i moduli. In un'applicazione che utilizza i livelli di astrazione, ogni livello dipende solo dal livello sottostante.
  • Quando scrivi la documentazione, presumi che dimenticherai tutti i dettagli di implementazione. Scriverete molta documentazione sotto questa ipotesi: forse la metà del vostro codice sarà commentata, ma in seguito sarete meno confusi.
  • I test automatici di integrazione, integrazione e accettazione sono grandi in alcuni spazi, ma gli sviluppatori C ++ sembrano avere sentimenti contrastanti su di loro.
  • Traccia molto sui design pattern . Oltre ad essere generalmente buone idee, i modelli di progettazione forniscono un vocabolario comune nell'ingegneria del software. Chiamare una classe a WidgetFactory è un modo conciso per comunicare che è una classe che esiste per creare widget.

È passato molto tempo da quando ho lavorato con software di ingegneria, quindi il tuo chilometraggio potrebbe variare su questi suggerimenti. Buona fortuna!

    
risposta data 21.05.2012 - 04:40
fonte
1

Consiglio vivamente di mettere le mani su Enterprise Architect , che sebbene non sia gratuito, offre prezzi accademici. È uno strumento eccellente per la progettazione di progetti a livello macro e micro. Può anche decodificare i tuoi file sorgente in diagrammi di classe, il che sarebbe probabilmente un buon inizio per te nel documentare e riorganizzare il modo in cui l'applicazione va insieme.

Avrei anche seguito le raccomandazioni di @ Klee. Non lasciatevi scoraggiare da presunti strumenti "agili", poiché sono in realtà solo gli elementi di best practice che sono anche pratici (se non obbligatori) se si sta seguendo un processo agile. Ma l'integrazione continua (ad esempio) è preziosa indipendentemente dalla tua metodologia. Inoltre, unit test (cppUnit?) Sono i tuoi amici. I test unitari dovrebbero essere molto fattibili se si testano le classi logiche chiamate dall'interfaccia utente, piuttosto che testare l'interfaccia utente direttamente. Ci sono anche strumenti che possono aiutarti ad automatizzare i test dell'interfaccia utente, ma proverei prima a mettere insieme le cose sul back-end.

Buona fortuna!

    
risposta data 21.05.2012 - 05:51
fonte
1

Credo che il tuo problema abbia tre dimensioni

  1. Programmatore-Oriented
  2. Programma-Oriented
  3. Manutenzione del programma - Orientato

Riguardo al primo problema, potresti avere programmatori che non capiscono il concetto di ciò che fa il programma (questo spesso accade nelle configurazioni aziendali). Ma dalla tua domanda e dal dominio in cui ti trovi, sembra che tu e il tuo team abbiate il controllo di ciò che fa il programma, ma non potete tradurlo in un programma di lavoro in tempi rapidi (per citare un esempio, ho sentito parlare di persone avere lauree post-dottorato in Fisica che hanno difficoltà a capire i puntatori nella programmazione e sono sicuro che la Fisica è molto più difficile del C ++). Se questo è il caso, il tuo problema è principalmente incentrato sul Programma (devi sentirti abbastanza fortunato che le persone intorno a te possano capire cosa sta facendo il tuo programma e possono apprezzarlo).

In caso di problemi incentrati sul programma, uno dei miei scandalosi suggerimenti sarebbe di passare a un livello più alto di astrazione rispetto al C ++ come l'apprendimento di una nuova lingua come Python o Haskell (Python è abbastanza facile da imparare e se si sta avendo bravi matematici, Haskell è semplicemente fantastico). Il passaggio a un livello più alto di astrazione manterrebbe le dimensioni del codice ridotte, facili da comprendere e da mantenere a lungo termine e influire rapidamente sui cambiamenti. Quindi puoi avere 10 linee di codice al posto delle 50 linee di codice originali. Inoltre, avere qualcuno con esperienza nella programmazione di computer sarebbe sicuramente di aiuto. Essendo in un'università, puoi anche coinvolgere alcuni studenti nella GUI e nelle interfacce in modo da concentrarti maggiormente sulla funzionalità. Raccomando anche il libro Progettazione software C ++ su grande scala di John Lakos (è un libro abbastanza grande, puoi diventare un abile programmatore Python nel tempo che potresti impiegare per leggere il libro)

Se risolvi le prime 2 dimensioni del problema, il terzo viene risolto automaticamente. Dal momento che credo che tu stia lavorando su un singolo progetto di grandi dimensioni, qualsiasi software di gestione del progetto decente ti faccia passare. La pianificazione anticipata è necessaria. Se inizi a programmare subito, potresti essere troppo coinvolto nel programma per dimenticare l'immagine grande. Tenere presente le cose non funzionerebbe per un grande progetto. Metti tutto in carta (o nel computer). Usa una wiki per condividere informazioni. Per quanto riguarda le metodologie, preferisco la metodologia agile (Simply, agile è un nome elegante per lo sviluppo di software incrementale). Suggerisco anche di assumere qualcuno con esperienza in questo settore in modo che si prenda cura di questi in modo che tu possa concentrarti sul tuo programma principale. La conclusione è che tutte le metodologie di project management sono solo un modo per garantire il successo del programma; così puoi scegliere chiunque sia adatto a te e alla tua squadra invece di selezionare qualcosa che qualcuno consiglia il meglio. Inoltre, il seguente software potrebbe aiutarti

  • Software gratuito Mind - Mind mapping
  • Trac: programma di bug software rapido e semplice e wiki
  • MoinMoin - wiki veloce per abilitare la condivisione delle conoscenze sul programma

Anche se i suggerimenti di cui sopra richiederebbero qualche curva di apprendimento, ne valeva la pena a lungo termine. Infine, la programmazione è più semplice di quella di Photonic Engineering (sebbene non sia la programmazione in C ++)

    
risposta data 21.05.2012 - 07:03
fonte
1

La risposta è ingegneria del software.

Per progetti di grandi dimensioni si segue una sequenza di raccolta dei requisiti, definizione del processo, specifica, ecc. molto prima che venga eseguita una codifica effettiva.

Esistono varie metodologie utilizzate a seconda dell'ambiente e della cultura. Le attività di tipo Enterprise tendono a seguire " Rational Unified Process " o simili, le start-up tecnologiche solitamente richiedono variazioni su Agile , dipartimenti governativi un po 'oberati di lavoro Cascata methodoligy.

In tutti i casi il processo ti aiuta a definire esattamente quello che stai facendo e, verso la fine del progetto, ti consente di dimostrare di averlo fatto.

    
risposta data 21.05.2012 - 03:58
fonte
0

Come la tua domanda, ogni risposta che ti è utile sarà molto lunga e vaga - ma la risposta breve è "Ingegneria del software"

Ti suggerisco di liberare del tempo libero, il più possibile se sei serio riguardo a una carriera di sviluppo del software, e inizia con la visita di Steve McConnells sito. La programmazione è facile e può essere insegnata in un semestre, l'ingegneria del software è un ordine di grandezza più complessa e richiede molto più tempo per imparare.

    
risposta data 21.05.2012 - 10:51
fonte

Leggi altre domande sui tag