Nella metodologia di programmazione estrema, quali risorse / possono essere utilizzate per documentare l'implementazione?
Ho usato un diagramma di attività per documentare i passaggi di progettazione per ciascuna attività. Ho letto che per XP, il capitolo di implementazione è il codice stesso.
Sto sviluppando un'applicazione Android che consiste nella GUI e nella codifica java.
I test di unità / accettazione sono una documentazione più strong su come funziona il sistema di qualsiasi altro pezzo di carta potrebbe mai essere.
Tuttavia, documenta il design in qualsiasi modo che funzioni per te; XP non ti dice che non puoi 'pensare sulla carta' o generare documentazione di supporto come meglio credi, ma non richiede richiedere tali elementi
La documentazione è qualcosa di importante quanto la progettazione di database, le interfacce utente e qualsiasi altra cosa che ho sentito deridere dagli sviluppatori. Il trucco che agile sta cercando di insegnare alle persone è imparare ciò che è necessario e ciò che è cruft. In passato, molta documentazione era cruft. Ecco perché le aziende spenderebbero milioni di dollari di specifiche generate che sono state prontamente scartate dai team di sviluppatori. Troppo dettagliato e spesso sopra progettato come il codice che è stato generato da esso. Ultimamente alcune persone sono andate all'estremo opposto e dicono che tutto il codice dovrebbe essere auto-documentante e "Basta leggere il codice". Così sciocco.
Il codice che stai scrivendo è lì per risolvere un problema, quindi considera la documentazione come anche la necessità di risolvere un problema. Chiediti: perché ho bisogno di questa documentazione? e ... seguendo pratiche agili ... qual è la soluzione più semplice che risolverà il problema nel modo più chiaro? Ma soprattutto - per chi scrivo questo? e quale livello di comprensione assumerò che abbiano?
Non ci sono regole rigide né nella programmazione né nella scrittura della documentazione. Ognuno deve adattarsi al problema e al contesto del problema. Tratta tutte le opzioni disponibili come una tavolozza di soluzioni tra cui scegliere e da applicare al tuo progetto. Scegli le migliori opzioni come le vedi e non aver paura di cambiarlo in un secondo momento.
Per definizione chiave della metodologia XP, mancano specifiche di progettazione o documentazioni. Il riferimento sotto è da Wiki - Extreme programming .
Critics have noted several potential drawbacks,[5] including problems with unstable
requirements, no documented compromises of user conflicts, and a lack of an overall
design specification or document.
Questo approccio ha una serie di critiche e una di esse:
Can increase the risk of scope creep due to the lack of detailed requirements documentation
I sostenitori di XP sottolineano quanto segue: Coders like coding, not documenting, and coders like seeing code they've written work.
Stiamo creando una documentazione (snippet UML, firme dei metodi e altre osservazioni) e ne includiamo alcuni nei test unitari. Tuttavia, il progetto deve documentare il codice in un determinato momento, perché è il modo in cui i clienti utilizzano effettivamente le funzionalità che hai ideato. Sarebbe egoista solo per codificare e mai documentare o commentare come funziona il software.
Qualsiasi documentazione è dura per un programmatore poiché non può mai spiegare il software in meno di 10 centinaia di parole. Pertanto, l'opzione di avere i documenti video che registra l'approccio alla progettazione e i casi d'uso, nonché i diagrammi per mostrare l'interazione tra i componenti possono essere fatti con meno tempo e più divertimento.
Leggi altre domande sui tag design agile documentation extreme-programming