Come gestire i codici complessi in (enormi) progetti

Documento, documento, documento!

Io lavoro con un codice MVC piuttosto complesso, e sono solo ora in capire come funziona, invece di accettarlo sulla fede. Ogni volta che apporto una modifica che ho difficoltà a capire, ho inserito un commento nel codice di quella sezione per aiutare a chiarire cosa sta succedendo. Potrebbe non essermi stato d'aiuto visto che non c'era, ma aiuterà la prossima persona in giro. Mi piace anche chiedere ad altri programmatori intorno a me di guardare le mie modifiche per vedere se sono chiare.

La mia azienda ha una wiki interna che usiamo per documentare molte delle meta attività che svolgiamo, come problemi con i server virtuali, domande comuni, ecc. Ogni volta che mi imbatto in qualcosa che non ho fatto prima, ma dovrò farlo spesso , Controllo per vedere se c'è una wiki su di esso. Se non ce l'ho, ne farò uno. Altre persone sono state coinvolte anche recentemente, quindi spero che cresca più velocemente. Penso che aiuti davvero la comunicazione dei compiti più banali che abbiamo.

Non penso che tu possa mai evitare completamente la complessità nel tempo, ma ci sono modi per mitigarlo:

• Mantenere il codice il più pulito possibile in qualsiasi momento, entro limiti ragionevoli. (Nel senso "come Zio Bob definisce" pulito "" senso.)
• Applica le revisioni del codice e / o abbina la programmazione per ridurre le probabilità di uno sviluppatore che sovrascrive le cose inutilmente.
• Mantenere test unitari e test di integrazione adeguati.
• Investi in un server di integrazione continua e costruisci spesso. Rilascia spesso anche, se possibile.

Tutto questo dipende in qualche modo da ciò che effettivamente il progetto comporta. A volte, ad esempio, sarà vantaggioso accettare la complessità in cambio di prestazioni. Non tutto il codice complesso è necessariamente una cosa negativa. In generale, però, penso che seguire queste linee guida dovrebbe aiutare.

• debito tecnico

  refactoring per eliminare

• cambiamenti aziendali

  adatta e expunge

• cambia strumento

  nuovi strumenti, stessa vecchia architettura = mancata corrispondenza dell'impedenza

Inoltre, resisti alla tentazione di aggiungere rapidamente hack perché il codice è già complesso / cattivo / hacky. Nella mia esperienza finirai con esponenziale più complessità.