In primo luogo, mi rendo conto che questa domanda potrebbe essere piuttosto lunga e vaga e mi scuso per questo. Questo è probabilmente un problema di base con un breve nome per chiunque abbia "capito", ma siccome mi trovo carente in questo senso, per favore abbi pazienza nel descrivere il problema.
Ho programmato in questo modo o nell'altro da quando avevo circa 11 anni. Questo significa che mi sono principalmente insegnato tutto dall'inizio. Ho ricevuto una formazione tecnica, ma non rigorosamente in Informatica (mi sono laureato in Ingegneria Fotonica). Naturalmente avevamo dei corsi di programmazione, ma per me questo era principalmente roba di base e non ho imparato molte cose nuove. Ho continuato a educare me stesso lungo la strada per la gioia di esso e ho sempre saputo che avrei perseguito una carriera nella programmazione, ma tutti i miei progetti erano piuttosto piccoli in quel momento. Non ho avuto problemi a tenerli nella mia mente e mantenerli.
Ora mi trovo al comando di un team, ma non in un ambiente aziendale - lavoro per l'università sviluppando software scientifico (in C ++) per applicazioni di ingegneria. Improvvisamente il progetto sta diventando (relativamente) grande e ho difficoltà a pensarci su per la maggior parte del tempo. Sto perdendo molto tempo e sforzi principalmente su due cose:
- Quando devo tornare a una sezione di codice su cui non ho lavorato per un po ', ho difficoltà a ricordare come ha funzionato. Passo 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 "schema" che potevo vedere e riconquistare più facilmente il quadro;
- Quando introduco cambiamenti, a volte mi rendo conto a metà strada che ciò che sto cercando di fare romperà le cose da qualche altra parte (o peggio, si presenta solo in fase di esecuzione come una sorpresa). Ripristino e comincio a farlo diversamente, solo per scoprire che ho trascurato l'influenza su qualche altro componente. Vorrei che ci fosse un "diagramma dell'architettura" in cui potevo vedere come vengono fatte le cose, come ciò che sto cercando di fare influenzerà altri componenti e un modo per pianificare in dettaglio prima di iniziare a implementare le modifiche.
La maggior parte delle persone con cui lavoro hanno storie simili alle mie: forte orientamento tecnico e talvolta grandi capacità, ma senza modo di organizzare il proprio lavoro. Tuttavia, i loro progetti sono in genere molto più piccoli dei miei, quindi riescono a farcela in qualche modo. Comunque, ciò che significa per me è che sono da solo e non ho nessuno da cui imparare le buone pratiche.
Ho seguito un corso post-laurea in gestione dell'IT e, sebbene lo trovo abbastanza soddisfacente, si rivolge principalmente ai non programmatori, insegnando metodologie di gestione del progetto, stime di budget / pianificazione, architettura aziendale ecc., Non progettazione del software e pianificazione in quanto tale. Va bene, sto cercando di imparare anche quella roba. Naturalmente, sono stati introdotti alcuni strumenti (come UML) e i tipi di processi di sviluppo del software (a cascata, iterativi, agili ...), ma ovviamente non in grande dettaglio e faccio fatica a decidere cosa dovrei scegliere e usare ( e in quale misura).
Ho letto molte domande e risposte sulla progettazione di software su SO - ce ne sono molte nel farlo usando questo o quel particolare strumento o metodologia, e se fossi convinto che la documentazione UML avrebbe risolto i miei problemi - l'avrei presa e inizia ad usarlo. Ma alcune persone lo giurano, altri dicono che è inutile. Sto cercando una risposta a 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 poterlo fare, possibilmente senza essere vincolato a un particolare strumento? Questi vanno e vengono di volta in volta fuori moda, 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 ciò che intendo più brevemente (mancanza di esperienza di progettazione software e vocabolario).