Come mantenere il controllo in un grande progetto software? [duplicare]

1

Ho un progetto software di grandi dimensioni che sono l'unico sviluppatore di (~ 80KLOCS e conteggio - so che ci sono molti progetti più grandi là fuori, ma è un ordine di grandezza più grande di quanto abbia mai avuto a che fare prima)

Se è rilevante, il codice è diviso tra PHP e JavaScript. Direi che circa un terzo di esso era JS, circa due terzi è PHP; Mi aspetto che nel tempo, la dimensione del JavaScript supererà la dimensione del PHP.

Sto iniziando ad arrivare alla situazione in cui, occasionalmente, la parte strana di questa è diventata più complicata da mantenere. È ancora praticabile, ma posso vedere che forse tra qualche mese diventerà un incubo.

Ad ogni modo, la mia domanda è questa:

Con progetti software più grandi, qual è il modo migliore per mantenerli mantenibili? Voglio dire, quando suppongo che il mio ciclo di apprendimento del programma abbia colpito una serie di questi muri di mattoni di manutenibilità:

  • Prima parete; risolto apprendendo che è possibile inserire il codice all'interno delle funzioni
  • Seconda parete; risolto apprendendo che è possibile inserire funzioni all'interno delle classi
  • Terza parete; risolto apprendendo che è possibile inserire classi in un'architettura (ad esempio, MVC). E in un momento simile - versioning, unit test etc
  • Quarto muro; ????

In ogni caso, mi sono semplicemente chiesto - c'è qualche altra cosa che apprende, qualche approccio di organizzazione di codice magico che rende "enormi" questi enormi progetti di software? Dev'esserci qualcosa che impedisce ai grandi progetti di fermarsi? È solo un caso di essere severi con se stessi ... nel qual caso, rigoroso su cosa?

Grazie per l'aiuto, dovrebbe venire:)

    
posta Algy Taylor 14.11.2014 - 14:48
fonte

1 risposta

9

Ad un certo punto, ogni progetto diventa troppo grande e complicato per tenere tutto in testa. Per alcuni questo punto viene prima o poi che per gli altri e sembra che tu abbia raggiunto quel punto nel tuo progetto ora.

Il primo passo ora è iniziare a scrivere quella temuta documentazione. Annota

  • ciò che ogni classe dovrebbe fare,
  • quali classi lavorano insieme in un modello di progettazione e perché utilizzi quel modello
  • per una logica complicata, annota perché deve essere fatto in questo modo e non può essere risolto in un modo più semplice,
  • aggiungi diagrammi di chiarimento (UML) dove necessario.

Questo può essere un documento autonomo o può essere estratto dai commenti nel codice con strumenti come JavaDoc, doxygen, ecc. L'obiettivo qui è avere qualcosa a cui è possibile fare riferimento per aggiornare la memoria quando devi tornare a un pezzo di codice dopo un po 'di tempo.

Qualcos'altro che puoi fare per mantenere gestibile una base di codice in crescita è dividerlo in moduli / librerie più piccoli.

Suddividendo il progetto in più moduli più piccoli con limiti / interfacce rigorosamente definiti, è possibile lavorare su ciascun modulo in isolamento senza la necessità di sapere / ricordare cosa accade esattamente dall'altra parte del confine.
Questo rende efficacemente ogni modulo un suo piccolo progetto, con una complessità molto più piccola rispetto al progetto complessivo.

    
risposta data 14.11.2014 - 15:27
fonte

Leggi altre domande sui tag