Approccio a un'attività di programmazione

Ciò che sembra descrivere è un problema nella definizione dell'ambito. Il mio consiglio è il seguente:

1. Pensa in ogni caso a tutti i diversi compiti possibili, potresti trovare alcune utili funzioni aggiuntive. Scrivi le intestazioni per tutte le diverse idee che hai avuto, ma niente di più delle intestazioni.

2. Esamina e assegna la priorità alle intestazioni. Probabilmente alcuni in fondo potrebbero andare persi, concentrarsi sulla funzionalità richiesta.

3. Espandi le intestazioni principali nelle loro attività secondarie finché non hai attività che durano solo alcune ore o giorni ciascuna.

4. Esamina questi dati con la persona che richiede la modifica (probabilmente prima di espandere i dettagli se la persona non è tecnica).

5. Inizia a lavorare sull'attività principale e continua verso il basso, producendo prototipi e dimostrazioni (se non rilasci) a intervalli regolari per la revisione con il richiedente.

6. Aggiungi e rivedi l'elenco delle attività tra i completamenti delle attività; più attività saranno sempre risultate dalle recensioni degli utenti e alcune potrebbero diventare obsolete.

Invece di pensare a tutto in una volta, usa un approccio top-down.

Quindi pensa: "cosa fa questo programma al più alto livello possibile?"

Esempio: se stai scrivendo un pezzo di codice per prendere un array di stringhe e manipolare ogni stringa in qualche modo, codificherai prima questo:

public ICollection<string> DoHighLevelStuff(ICollection<string> items)
{
    for(int i=0; i<items.Count; ++i)
        item = DoLowLevelStuff(item);

    return items;
}

e ti preoccupare esattamente del modo in cui i metodi di livello inferiore funzionano più tardi.

Prendo questo approccio in modo naturale, ma alcune persone non possono fare a meno del contrario.

Nota: problemi diversi richiedono approcci diversi e un approccio dal basso non è necessariamente una cattiva pratica.

Ti consiglio vivamente di dare una buona occhiata a Test Driven Design.

Qui inizi a scrivere un test per ogni nuova funzionalità. La parola "test" qui indica che si verifica il comportamento del codice controllando se funziona come previsto. Prima scrivendo il test, si è certi che inizi a pensare a come usare il tuo codice, invece di come scriverci . Quindi si implementa quanto basta per rendere superabile il test: adempiere ai requisiti e quindi aggiungere altri test che descrivono più funzionalità e più codice per farlo passare. Ripeti fino a quando non avrai tutte le funzionalità di cui hai bisogno.

Suggerirei di dare un'occhiata al link che descrive come sviluppare una classe Money in questo modo .

Ho trovato l'approccio MOLTO utile soprattutto per le biblioteche. Potresti anche farlo.

Puoi provare a pensare con piccoli incrementi e scrivere cose in ogni fase.

Inizia con un documento dei requisiti. Pensare dal punto di vista dell'utente finale. Blocca i requisiti. La cosa più importante è annotarlo in un documento controllato in versione.

Quindi vai alle specifiche funzionali. Pensare dal punto di vista dell'architetto. Annotare in un documento a versione separata controllato, in che modo verranno soddisfatti tutti i requisiti. Dovrebbe descrivere tutte le interazioni e le funzionalità degli utenti.

Passa ora al documento di progettazione. Pensare dal punto di vista di un lead. Annota il documento di design di alto livello. Questo dovrebbe descrivere i moduli di alto livello e spiegare chiaramente le interfacce tra i moduli. Le interfacce devono essere congelate in questa fase.

Ora inizia la codifica attuale. Pensare dal punto di vista di un programmatore. Implementare modulo per modulo. Concentrati su un modulo alla volta. Interrompi la codifica di un modulo una volta aderito all'interfaccia già bloccata.

Se tutto va bene, l'integrazione non dovrebbe essere troppo dolorosa.