Quando si sta iniziando un nuovo progetto, come si fa a pianificare per esso o quanto tempo ci vuole?
Pseudocodice? Diagrammi di flusso?
Non si tenta di pensare a tutte le classi in anticipo?
TBH, non ho mai pianificare nulla. Ottengo dritto ad esso e pensare a soluzioni di problemi. Soprattutto perché le poche volte ho cercato di pianificazione in anticipo, vorrei sempre dimenticato qualcosa di importante, e quindi la logica della pianificazione sarebbe viziata.
Molto meno di quanto dovrei
Ho sempre in tuffo, sporcarsi e quindi rendo conto di aver fatto un pasticcio. Poi torna indietro e piano, e farlo bene.
ma la fase di errori disordinato mi dà grandi idee che io non avrei anche se attraverso un processo di progettazione formale.
Edit ricevo soprattutto in questo tipo di distruggere la tastiera pasticci quando si gioca con i più grandi / complessi. Interessante vedere fino a che punto le cose si fanno prima di rendersi conto che il vostro 'è nella mia testa, quindi è ok' design è viziato al 100%.
Dipende. La maggior parte delle cose che scrivo sono piuttosto semplici e di un disegno più grande ottiene costruito passo dopo passo e ho notato quello che ancora manca e ciò che è già completo. C'erano un paio di cose più pelose che richiedevano vasta schizzi e pensato per ottenere il diritto, anche se non ho ancora incontrato molti problemi architettonici che ha richiesto in modo (ancora giovane e roba). Per lo più quelle erano cose aritmetici difficili.
Al mio tirocinio l'anno scorso, il mio manager è stato piacevolmente sorpreso che ho usato diagrammi di flusso per un problema. Ha pensato che fosse un'arte perduta con gli studenti in questi giorni. Ero non-così-piacevolmente sorpreso dal fatto che essi sono stati considerati datati.
In ogni caso, dipende dalla timeline del progetto per me, le scadenze sono la cosa più importante, naturalmente.
Probabilmente non la migliore tecnica ... ma ... ho in programma nel codice .
Spesso scopro classe / metodi / etc. che ho bisogno solo facendo in questo modo. Detto questo, ho sempre presumo che il mio codice di pianificazione non sta per essere la soluzione definitiva.
Inoltre voglio scrivere le note in dettaglio "caratteristiche principali" e "funzionalità minori / desiderio".
Quando si scatta su un problema di qualsiasi dimensione, ho sempre intenzione di scrivere almeno due volte.
Tutto dipende da quanto è grande il progetto di esso. A volte potrebbe richiedere mesi per raccogliere solo tutte le esigenze e sapere esattamente che cosa deve fare.
Quando si scende verso la parte di codifica, tutto dipende da quanto è complicato. Se è estremamente complicato, ho Wills iniziare, semplicemente tirando fuori quello che io voglio fare. Poi mi digitare il mio pseudo codice nei commenti. Poi mi codice intorno a quei commenti.
Tuttavia, se si tratta di semplice codifica. Io di solito solo scrivere quello che ho in mente e testarlo.
Usiamo un approccio molto agile che lavoreremo su parti importanti e di cose naturalmente sono sempre venuta a pop-up nei requisiti. Così li accoglieremo per quelli come si presentano. Si è mai andare a conoscere appieno esattamente ciò che si vuole creare, all'inizio del ciclo di creazione.
È la mia opinione.
La maggior parte del tempo, io almeno cercare di avere uno schema generale (anche solo nella mia testa) di come il modulo / sistema sta andando a lavorare. Mi piace sapere quello che sto per fare prima lo faccio. Rende la programmazione più semplice e veloce (siamo generalmente in tempi molto stretti dove lavoro). Ogni volta che non ho, mi imbatto in problemi che in genere mi porta a tirare fuori il codice e la messa è da qualche altra parte. Devo ammettere, mio processo è venuto attraverso l'esperienza amara e ho avuto davvero bravo a usare espressioni regolari nel codice insieme con find e sostituzione globale.
Qualcun altro ha portato un buon punto, a volte si ha davvero un grande sistema e che diventa difficile. Provo e scomposizione in pezzi. Lavorerò su qualcosa e farlo rimpolpata, e lavorare su qualcos'altro per un po 'e vedere come interagiscono. Anche con pianificazione per il futuro, mi manca le cose e avere il refactoring del codice, ma almeno non sto rifacendo tutto da quando ho avuto almeno una sorta di un piano di lavoro.
Dipende da quanto sia complesso il problema è che si sta tentando di risolvere. Se state prendendo su un grande progetto di programmazione, è necessario disporre di un certo grado di pianificazione prima di iniziare. Se non lo fai, avrai orribilmente perde in dettagli di roba che non abbastanza comunicare con le altre parti in pochissimo tempo.
Fondamentalmente, cercare di ottenere una vista a volo d'uccello dei problemi che è necessario risolvere. Vedere se uno dei problemi sono abbastanza piccoli da poterli risolvere e capire cosa potrebbe aver bisogno di comunicare con il resto della vostra soluzione. Pensate a come un black-box con un'API per il mondo esterno.
Dopo avere tutti i blocchi capito, vedere se è necessario dividere il problema in piccoli sotto-problemi, o di avere una visione abbastanza dettagliata di tutto il progetto che si può iniziare con il codice.
La mia esperienza è che la pianificazione aiuta a prevenire problemi in futuro, ti fanno pensare di più su come si suppone che il codice a crescere in futuro, se avete bisogno di aggiungere nulla, ecc
Nella maggior parte dei casi vi farà risparmiare il tempo speso per la pianificazione, quando si esegue il debug o l'estensione del progetto. Inoltre, avere un layout di massima del progetto significa che sarà più facile per ottenere aiutare la costruzione delle scatole nere è necessario, in modo da poter lavorare su di essa con più persone che solo a se stessi.
A seconda della complessità del progetto, solito inizio con il rilievo e la carta, e scrivere su una specifica, e alcuni pseudo codice del flusso di controllo. Poi posso sempre fare riferimento a che, mentre sto codifica. Rende più facile e richiede meno refactoring perché non hai pensato il problema attraverso.
Personalmente dipende la portata e la complessità del progetto, quante persone con cui sto lavorando su di esso, e le aspettative generali sulla consegna.
E 'molto importante capire le aspettative generali dei partiti che useranno il software. Tutte le persone coinvolte nel progetto dovrebbe avere una comprensione comune di ciò che viene lavorato - come che viene comunicato va in molte direzioni.
Troppo spesso, le parti coinvolte nello sviluppo di software non si rendono conto che la comunicazione tra le parti è spesso la parte più critica e sottovalutato del progetto - e la principale causa di incidenti di progetto.
Dopo l'esperienza di un sacco di progetti incompiuti , tendo a implementare una versione semplificata dei miei processi di business nella mia metodologia di sviluppo personale.
Essi generalmente seguono la seguente struttura:
Mi preparo un caffè e mestieri un paio di panini.
In realtà dipende dal progetto. Ho lavorato su alcuni progetti nel settore della difesa che ha avuto 2 anni di pianificazione dettagliata prima di scrivere una sola riga di codice, e ho seduto e sfornato alcune piccole utilità da poche richieste in un'email da un 3D o texture artist in una sola seduta con un sacchetto di salatini e una tazza di Joe.
Essere in grado di sviluppare diagrammi di flusso, diagrammi UML, casi d'uso, dizionari e ampi standard di codifica prima mano è un bel modo per mantenere le cose organizzate, ed è certamente la pena di fare su progetti di grandi dimensioni, le squadre più grandi, e progetti mission-critical. Ma queste cose fanno prendere tempo, e sono spesso eccessivo per i piccoli progetti.
L'unica cosa che dovete veramente per garantire è che avete una comprensione adeguata del dominio del problema. In caso contrario, passare il tempo davanti alla ricerca fino a quando si fa è sempre la pena il tempo.
Quando ero nella via "cascata" di fare le cose vorrei scrivere diverse centinaia di documenti di più pagine che mostrano tutti i dettagli che potrebbero essere scoperti durante la ricerca. Per arrivare a questo enorme tomo di documentazione che sarebbe in generale
Negli ultimi anni ho seguito con Agile (SCRUM) e hanno preso un approccio totalmente diverso.
Devo dire che Agile riduce la quantità di documenti di scrittura di tempo speso che decadono non appena le drys inchiostro. Il proprietario del prodotto arriva a vedere i risultati in un modo molto più rapido. Il che significa che si arriva a mantenere il progetto va nella direzione giusta nel tempo - anche se che i cambiamenti di direzione come noi si stanno sviluppando.
Tenete a mente che c'è un tempo e un luogo per entrambi i modi di sviluppo. Non vorrei che per costruire il software Jet utilizzando Agile!
Sono ancora all'università e non ho ancora avere esperienza con la creazione di sistemi di software su larga scala, ma ...
La prima cosa che deve essere fatto è quello di capire che cosa sta voleva. Finora per me, questo è normalmente una specifica assegnazione, ma nel mondo reale si tratta di parlare con il cliente. Un sacco.
Poi lavoro come fare ciò che è necessario. Per i relativamente piccoli programmi che ho lavorato su, io normalmente formo nella mia mente una vaga idea di ciò che il mio programma sta andando a guardare come (quali sono le parti importanti del programma sono e come interagiscono tra loro). Questo può comportare picchi se non ho idea di come una parte del programma funzionerà. Non credo che questo approccio (fare tutto nella mia mente) scalerà molto bene, ma la questione è stato chiesto ciò che realmente facciamo ...
Una volta che so più o meno quello che sto cercando di fare, mi siedo e scrivere il codice. E 'qui che scopro problemi in quello che stavo pensando.
Io non credo di aver usato ogni pseudocodice per la progettazione di un algoritmo. Credo pseudocodice è troppo basso livello per la progettazione di grandi blocchi di programma.
Ho solo usato un diagramma di flusso in una sola occasione per aiutare con la progettazione di un programma - indietro quando stavo imparando assemblaggio ed era abbastanza nuovo per la programmazione (ed era disponibile). The Mythical Man-Month dice il seguente: ". Il grafico dettagliato blow-by-blow flusso, tuttavia, è un fastidio obsoleto, adatto solo per iniziare i principianti a pensare algoritmico ... Non ho mai visto un programmatore esperto che abitualmente fatto dettagliata diagrammi di flusso prima di iniziare a scrivere programmi."
IMO 5 minuti di pianificazione avanti = 1 ora di codifica ....
Tante volte dobbiamo tornare indietro e ripensare tutta la situazione, perché non abbiamo intenzione di nulla.
La parte più importante dovrebbe essere il diagramma di flusso.
Gli altri dettagli a volte possono essere curati al volo.
Vorrei attirare vasti diagrammi di flusso e scrivere il codice pseudo per le funzioni più complicate. Mi sento come disegnare il diagramma di flusso mi permette di refactoring senza introdurre bug per caso. Fare un diagramma visivo su carta, come un diagramma di flusso mi aiuta anche a capire se la mia logica è in realtà corretto. Questo funziona davvero solo per le piccole - medie progetti nei quali siano note la maggior parte delle specifiche.
Con più esperienza, la necessità di disegnare diagrammi di flusso estesi e scrivere il codice pseudo intera funzione diventerà più ridondante ma prima di raggiungere quel punto io consiglio caldamente di piano prima di codice.
