Come dovrei documentare meglio la mia progettazione dell'app in modo da evitare la programmazione per coincidenza? Come posso strutturare le note in modo che sia chiaro come funziona un'app in modo che quando mi riferisco ad essa un anno dopo non vado perso per i primi 3 giorni?
Separa l'analisi dal design. Non lasciare che i problemi architettonici si intromettano nei requisiti. Prendi le tue note dal punto di vista di un estraneo, cosa vedranno e da dove vengono questi dati?
Dovresti spendere più tempo sui tuoi appunti, non di meno. Non è possibile creare l'architettura per adattare le note parziali, è come progettare abiti per un manichino che manca entrambe le gambe e un braccio, sicuro che sia veloce ma (come hai notato) è poco funzionale; -)
Leggici un po 'su UML, anche se non lo utilizzi per delineare la tua app, le metodologie che usano UML ti forniranno l'ispirazione.
Le applicazioni sono costituite da almeno due serie principali di requisiti: commerciale e tecnico. I requisiti aziendali vengono prima e dovrebbero descrivere cosa deve fare l'applicazione e gli obiettivi aziendali che risolverà. Avere una buona serie di requisiti aziendali spesso richiede non solo la comprensione di ciò che l'utente richiede, ma anche ciò che l'utente desidera davvero. Voglio dire, una persona non tecnica spesso non può esprimere l'autobus. req è chiaramente e completamente senza l'aiuto di un BA qualificato (uno che capisce il particolare Business a portata di mano).
Supponendo di essere un BA qualificato e di avere un set completo di Bus. di rich. Quindi è necessario elaborare un piano per costruire il prodotto, requisiti tecnici. Esistono molti paradigmi e approcci per gestire un progetto. Dovresti sceglierne uno che funzioni per te e per la squadra, per esempio Agile.
Raccomando di tracciare le Entità richieste per risolvere i Requisiti Aziendali. Quindi, prendi una divisione e conquista l'approccio all'implementazione. Il referee Red-Green funziona abbastanza bene per la divisione del lavoro.
Ad esempio, un Dipendente è un'entità nel tuo prodotto. Il Dipendente ha bisogno di operazioni CRUD. Crea un'interfaccia CRUD e un test unitario per ciascuno dei 4 elementi CRUD. L'unità testa tutto fallito all'inizio. Quindi, delegare un programmatore per implementare le operazioni CRUD dell'entità Dipendente finché non passano tutti.
Risciacquare e ripetere. Supponendo di aver identificato correttamente tutte le entità, questo ti porterà bene nelle ultime fasi dello sviluppo back-end. Aggiungi classi di supporto e una libreria comune, mantieni aggiornati i test unitari e nel tempo i prodotti miglioreranno e lo sviluppo sarà più veloce.
Infine, disaccoppia il lavoro front-end dal back-end usando Inversion of Control. Fai il tuo CSS e tutto quel jazz con dati finti fino al completamento. Quindi, collega il back-end.
Questo è il modo in cui mi piace fare le cose, almeno. Tieni presente che non ci sono "giusti modi per costruire un ponte" nel software. Ogni squadra è unica. Ogni progetto è unico. Paradigmi e standard sono linee guida stabilite da sviluppatori che hanno risolto problemi particolari in un modo particolare e hanno detto che le soluzioni hanno superato la prova del tempo.
Buona fortuna.
Ricorda che la mia risposta riflette i miei punti di forza e di debolezza, che potrebbero non essere i tuoi.
Dividi la programmazione in tre parti 1) sintassi (definizione di variabili, operazioni di lettura-scrittura, ecc.), 2) calcoli e 3) logica.
La mia grande debolezza è nella parte matematica / computazione, quindi cerco di ottenere aiuto dagli altri. Nello specifico, cercherò di convincere l'utente, tipicamente un ingegnere, a scrivere tutte le equazioni e le formule computazionali pertinenti per me. In assenza di tale aiuto, potrei consultare un libro di testo o utilizzare una libreria di programmazione.
Il mio punto di forza è nelle lingue, quindi affronterò i problemi sintattici da solo: definizione delle variabili, formattazione, layout, ecc. Questo è molto più semplice, se ho seguito il passaggio 1 e l'ingegnere ha definito il problema per me.
L'ultima area è logica: ramificazione, loop, collegamenti, condizioni di test, ecc. Questa è la mia area di difficoltà intermedia, motivo per cui l'ho affrontata per ultima.
Questo consiglio potrebbe non funzionare per te nella sua forma esatta. Ma l'idea è di identificare i tuoi punti di forza e di debolezza e ottenere tutto l'aiuto necessario in quest'ultima area.
Se non sei bravo a prendere appunti (e sembra che tu non lo sia), allora proverei la prototipazione. Disegna un piano approssimativo, quindi passa un paio d'ore per vedere se è una buona idea. È quindi possibile utilizzare il prototipo come piano di come dovrebbe funzionare la produzione. (fai una riscrittura)
I make notes but they're not very useful, how should I organize my notes[...]?
Hai bisogno di un bug tracker .
Se vuoi iniziare un progetto, segnala come errore Elevator Pitch ! Allega ogni caratteristica importante per supportare quell'obiettivo come un altro bug.
Se hai delle note scritte, o delle idee che hai analizzato, o dei minuti che hai preso da un incontro con un cliente, chi ha bisogno di farlo nel bug tracker il prima possibile.
Il valore di organizzare il tuo piano di progetto in questo modo è che puoi facilmente cercare e organizzare ogni attività in base a come si relaziona ad altri elementi, quanto è urgente, quanto hai completato. Consente inoltre di collegare le modifiche del codice sorgente ai fattori che le hanno influenzate; questa modifica corregge l'errore o implementa quella funzionalità.
È possibile utilizzare un diagramma di classe a scopo di documentazione. Non intendo generare una documentazione automatica usando UML, che è veramente una cagata ma per creare manualmente le viste dei diagrammi di classe dei tuoi pacchetti.
Non hai davvero bisogno di conoscere UML perché se inverti il tuo progetto ottieni il tuo modello e un diagramma di classe per ogni pacchetto. Quindi basta aggiungere note su classi e metodi. Si salva il diagramma direttamente nella radice del pacchetto. Lavoro fatto !!
Davvero facile e molto efficiente. Questo è quello che faccio e gli sviluppatori mi amano: -)
Leggi altre domande sui tag productivity documentation