Come posso ottenere le cose proprio all'inizio di un progetto software? [chiuso]


64

Sono programmatore con 1 anno di esperienza, recentemente mi sono reso conto che raramente avvio correttamente un progetto (la maggior parte del mio progetto laterale), normalmente il ciclo del progetto va come

  1. Inizia con alcuni casi d'uso
  2. Inizia a scrivere codice
  3. Realizza alcune cose che non ho gestito bene e che non si adattano bene alla base di codice corrente.
  4. Riscrivi gran parte del codice

e questo potrebbe andare alcune volte

Quindi le mie domande sono

  1. Tale pratica è comune o implica che non sono competente?
  2. Come posso migliorare me stesso su questo aspetto?

29
Perfetto! Questo si chiama apprendimento :) E competente! = Efficiente il giorno 1

6
La tua domanda interessante è fuori tema, dal momento che sembra un consiglio di carriera. A proposito, suggerirei anche di contribuire ad alcuni progetti di software libero esistenti, imparerai molto (da una comunità di sviluppatori, alcuni dei quali sono più esperti di te oggi)
Basile Starynkevitch,

6
Se trovi un metodo per avviare perfettamente ogni progetto, faccelo sapere. Oppure scrivici un libro e diventa milionario.
Albero

1
@Qingwei, hai detto di iniziare con i casi d'uso, non definendoli. Definirli sarebbe una specie di analisi, vale a dire. dei requisiti dell'utente. Penso che sia meglio avere una comprensione più approfondita e dettagliata della maggior parte dei casi d'uso all'inizio. Intendo trovare solo un nuovo caso d'uso in una fase successiva, spesso può significare una rielaborazione sostanziale. Meglio fare i lavori sulla progettazione piuttosto che sull'implementazione.
Brad Thomas,

1
Immagino che dipenda da chi parli, ma i casi d'uso IMO sono puramente requisiti. Dovrebbero essere scritti completamente privi di decisioni di progettazione. L'analisi include principalmente la progettazione / definizione dell'architettura di sistema. Pertanto, i casi d'uso non appartengono alla fase di analisi. Detto questo, ciò che accade di solito è scrivere alcuni dettagli del caso d'uso, aggiornare i diagrammi di architettura e ripetere i casi d'uso per apportare le modifiche identificate mentre si eseguono i diagrammi di architettura e aggiornare i diagrammi in base alle modifiche ai casi d'uso . Quindi continui a ripetere finché non sei soddisfatto di entrambi.
Dunk,

Risposte:


70

Il ciclo che descrivi è normale. Il modo per migliorare le cose non è evitare questo ciclo, ma semplificarlo. Il primo passo è accettare che:

  1. È quasi impossibile sapere tutto il primo giorno di un progetto.
  2. Anche se in qualche modo sai tutto, quando avrai finito il progetto, allora qualcosa (i requisiti del cliente, il mercato in cui si trovano, la tecnologia con cui stai lavorando, i desideri dei loro clienti) sarà cambiato e fatto almeno parte di ciò che sapevi non valido o errato.

Pertanto, è impossibile pianificare tutto in anticipo, e anche se tu potessi, seguire quel piano ti porterebbe a costruire qualcosa di imperfetto o obsoleto. Sapendo questo, integriamo il cambiamento nella nostra pianificazione. Diamo un'occhiata ai tuoi passaggi:

  1. Inizia con alcuni casi d'uso
  2. Inizia a scrivere codice
  3. Realizza alcune cose che non ho gestito bene e che non si adattano bene alla base di codice corrente.
  4. Riscrivi gran parte del codice

Questo è in realtà un ottimo punto di partenza. Ecco come mi avvicinerei:

1. Inizia con alcuni casi d'uso

Buono. Dicendo "casi d'uso", si sta concentrando su ciò che il software è per . Dicendo "pochi", non stai cercando di scoprire tutto; stai rispettando una quantità gestibile di lavoro. Tutto ciò che aggiungerei qui è di dare la priorità. Con il tuo cliente o l'utente finale, elabora la risposta a questa domanda:

Qual è il software più piccolo e semplice che potrei darti per migliorare la tua situazione?

Questo è il tuo prodotto minimo realizzabile - qualsiasi cosa più piccola di questa non è utile per il tuo utente, ma qualsiasi cosa più grande rischia di pianificare troppo presto. Ottieni informazioni sufficienti per costruirlo, quindi vai avanti. Ricorda che non saprai tutto a questo punto.

2. Inizia la codifica.

Grande. Ti metti al lavoro il prima possibile. Fino a quando non hai scritto il codice, i tuoi clienti non hanno ricevuto alcun vantaggio. Più tempo dedichi alla pianificazione, più tempo il cliente ha trascorso in attesa senza rimborso.

Qui, aggiungerei un promemoria per scrivere un buon codice. Ricorda e segui i Principi SOLIDI , scrivi test unitari decenti su qualsiasi cosa fragile o complessa, prendi appunti su tutto ciò che potresti dimenticare o che potrebbe causare problemi in seguito. Vuoi strutturare il tuo codice in modo che il cambiamento non causi problemi. Per fare ciò, ogni volta che prendi la decisione di costruire qualcosa in questo modo invece che in quel modo, strutturi il tuo codice in modo tale che il meno possibile il codice sia influenzato da quella decisione. In generale, un buon modo per farlo è separare il codice:

  • usa componenti semplici e discreti (a seconda della lingua e della situazione, questo componente potrebbe essere una funzione, una classe, un assembly, un modulo, un servizio, ecc. Potresti anche avere un componente di grandi dimensioni costruito da quelli più piccoli, come una classe con molte funzioni o un assembly con molte classi.)
  • ogni componente fa un lavoro o lavori relativi a una cosa
  • le modifiche al modo in cui un componente esegue il suo funzionamento interno non dovrebbero comportare la modifica di altri componenti
  • componenti devono essere fornite cose essi utilizzano o dipendono, piuttosto che il recupero o la creazione li
  • i componenti dovrebbero fornire informazioni ad altri componenti e chiedere loro di fare il lavoro, piuttosto che recuperare informazioni e fare il lavoro da soli
  • i componenti non devono accedere, utilizzare o dipendere dal funzionamento interno di altri componenti: utilizzare solo le loro funzioni accessibili al pubblico

In questo modo, stai isolando gli effetti di una modifica in modo che nella maggior parte dei casi, puoi risolvere un problema in un punto e il resto del codice non se ne accorge.

3. Incontrare problemi o carenze nella progettazione.

Questo accadrà. È inevitabile Accetta questo Quando si verifica uno di questi problemi, decidere che tipo di problema è.

Alcuni problemi sono problemi nel codice o nella progettazione che rendono difficile fare ciò che il software dovrebbe fare. Per questi problemi, è necessario tornare indietro e modificare il progetto per risolvere il problema.

Alcuni problemi sono causati dalla mancanza di informazioni sufficienti o da qualcosa a cui non hai mai pensato prima. Per questi problemi, devi tornare al tuo utente o client e chiedere loro come vorrebbero affrontare il problema. Quando hai la risposta, vai e aggiorna il tuo design per gestirlo.

In entrambi i casi, dovresti prestare attenzione a quali parti del codice devono cambiare e, mentre scrivi più codice, dovresti pensare a quali parti potrebbero dover cambiare in futuro. Ciò rende più semplice capire quali parti potrebbero essere troppo interconnesse e quali parti potrebbero necessitare di essere più isolate.

4. Riscrivi parte del codice

Una volta identificato il modo in cui è necessario modificare il codice, è possibile procedere e apportare la modifica. Se hai strutturato bene il tuo codice, di solito ciò comporta la modifica di un solo componente, ma in alcuni casi potrebbe comportare anche l'aggiunta di alcuni componenti. Se scopri che devi cambiare molte cose in molti posti, allora pensa al perché. Potresti aggiungere un componente che mantiene tutto questo codice dentro di sé, e quindi avere tutti questi posti solo per usare quel componente? Se puoi, fallo e la prossima volta devi cambiare questa funzione, sarai in grado di farlo in un unico posto.

5. Test

Una causa comune di problemi nel software non è conoscere abbastanza bene i requisiti. Questo non è spesso colpa degli sviluppatori - spesso, l'utente non è sicuro nemmeno di ciò di cui ha bisogno. Il modo più semplice per risolverlo è invertire la domanda. Invece di chiedere "che cosa devi fare per fare il software?", Ogni volta che esegui questi passaggi, dai all'utente ciò che hai costruito finora e chiedi loro "L'ho costruito - fa quello che ti serve?". Se dicono di sì, allora hai costruito qualcosa che risolve il loro problema e puoi smettere di funzionare! Se dicono di no, saranno in grado di dirti in termini più specifici cosa c'è di sbagliato nel tuo software e puoi andare a migliorare quella cosa specifica e tornare per ulteriori feedback.

6. Impara

Durante questo ciclo, presta attenzione ai problemi che stai riscontrando e alle modifiche che stai apportando. Ci sono schemi? Puoi migliorare?

Qualche esempio:

  • Se continui a scoprire di aver trascurato il punto di vista di un determinato utente, potresti coinvolgere maggiormente l'utente nella fase di progettazione?
  • Se continui a dover cambiare le cose per renderle compatibili con una tecnologia, potresti costruire qualcosa per l'interfacciare tra il tuo codice e quella tecnologia in modo da dover cambiare solo l'interfaccia?
  • Se l'utente continua a cambiare idea su parole, colori, immagini o altre cose nell'interfaccia utente, potresti creare un componente che fornisce al resto dell'applicazione quelli in modo che siano tutti in un unico posto?
  • Se scopri che molte delle tue modifiche sono nello stesso componente, sei sicuro che quel componente si attenga a un solo lavoro? Potresti dividerlo in alcuni pezzi più piccoli? Puoi cambiare questo componente senza dover toccare altri?

Sii agile

Quello a cui ti stai muovendo qui è uno stile di lavoro noto come Agile. Agile non è una metodologia, è una famiglia di metodologie che incorporano un intero carico di cose (Scrum, XP, Kanban, solo per citarne alcuni) ma la cosa che tutti hanno in comune è l'idea che le cose cambino, e come sviluppatori software noi dovrebbe pianificare di adattarsi ai cambiamenti anziché evitarli o ignorarli. Alcuni dei suoi principi fondamentali - in particolare quelli rilevanti per la tua situazione - sono i seguenti:

  • Non pianificare in anticipo di quanto tu possa prevedere con fiducia
  • Tieni conto che le cose cambiano mentre vai
  • Invece di costruire qualcosa di grande in una volta, costruisci qualcosa di piccolo e poi miglioralo in modo incrementale
  • Mantieni l'utente finale coinvolto nel processo e ricevi un feedback tempestivo e regolare
  • Esamina il tuo lavoro e i tuoi progressi e impara dai tuoi errori

5
"Fantastico. Inizi a lavorare il prima possibile. Fino a quando non hai scritto il codice, i tuoi clienti non hanno ricevuto alcun vantaggio. Più tempo dedichi alla pianificazione, più tempo il cliente ha trascorso in attesa senza rimborso." Non posso essere d'accordo con questo. Meno tempo dedichi alla pianificazione, più tempo il cliente trascorre in attesa di qualcosa che funzioni effettivamente correttamente, senza alcun rimborso.
Corse di leggerezza con Monica il

4
@RobCrawford: c'è un intero continuum tra "nessuna pianificazione" e "pianificazione eccessiva". La "pianificazione" o la "visione" perennemente ti faranno correre ... in cerchio. Agile non si tratta di "non pianificare", si tratta di evitare di fare affidamento su elementi incerti e di essere in grado di cambiare gli obiettivi mentre procedi: hai ancora bisogno di una sorta di obiettivo generale, anche se sfocato / impreciso, altrimenti non puoi misurare se ciò che sviluppi è progresso o uscita.
Matthieu M.,

7
Penso che tutti coloro che si oppongono alla "mancanza di pianificazione" abbiano completamente ignorato il fatto che il primo passo è identificare il prodotto minimo praticabile. Ciò comporta necessariamente una pianificazione. Mi sembra che il punto di questo post sia più di scoraggiare cercando di ottenere un design perfetto in anticipo; invece, quindi un po 'di pianificazione e non spendere per sempre cercando di identificare tutto in anticipo.
jpmc26,

3
Woah, quindi questo è esploso. Come hanno notato i commentatori, NON consiglio di fare una pianificazione zero. Quello che sto dicendo - e quello che dice Agile - è non fare troppa pianificazione. Dico esplicitamente "Non pianificare oltre in anticipo di quanto si possa prevedere con fiducia". Le persone che affermano che io sostengo "tuffarsi nel codice" dovrebbero notare che il codice è il passaggio 2, dove il passaggio 1 è ... beh, la pianificazione . Il trucco è fare una pianificazione sufficiente per determinare il prodotto più piccolo che aiuti l'utente e quindi dare loro quel prodotto .
anaximander,

3
In conclusione, Agile concorda sul fatto che esiste una pianificazione troppo scarsa. Suggerisce semplicemente che esiste anche qualcosa di troppo.
anaximander,

14

E 'normale.

Puoi prendere uno dei due approcci:

  1. Benvenuto cambiamento

Se si presume che lo si sbagli, è necessario creare una base di codice che è aperta a modifiche. Principalmente questo implica prendere il codice alla fine di un libro sul refactoring e costruire il tuo codice in questo modo dall'inizio (decomposibilità, buona copertura del test, ...).

  1. Evita il cambiamento

In questo caso devi fare un BDUF (grande design in primo piano). Devi fare un sacco di prototipi cartacei, discutere idee con potenziali utenti o te stesso con la paperella di gomma, provare varie cose in prototipi o modelli, scrivere una specifica completa e solo una volta che senti di aver inchiodato la soluzione, finalmente può iniziare a scrivere codice. Fare tutto ciò che in realtà non elimina il cambiamento inaspettato, lo riduce solo un po ', il primo anno circa. Quindi, devi ancora costruire il tuo codice per essere facile da cambiare.

Quindi, in sostanza, il cambiamento è un dato di fatto. Supponiamo che accadrà. Costruisci il tuo codice di conseguenza. In pratica, è possibile trovare una via di mezzo tra gli approcci di design-up-front e just-start-coding che evitano cambiamenti gratuiti senza rimanere bloccati nella paralisi dell'analisi. Ci vuole solo un po 'di esperienza.


11

Lo sviluppo del software è stato descritto come una serie di problemi intrinsecamente "malvagi" .

Horst Rittel e Melvin Webber hanno definito un problema "malvagio" come uno che può essere chiaramente definito solo risolvendolo o risolvendone una parte *. Questo paradosso implica, essenzialmente, che devi "risolvere" il problema una volta per definirlo chiaramente e poi risolverlo di nuovo per creare una soluzione che funzioni. Questo processo è stato la maternità e la torta di mele nello sviluppo di software per decenni

Questo descrive perfettamente il problema che stai affrontando. Fondamentalmente, ciò che facciamo è difficile . Se esiste una parte che potrebbe essere descritta come "di routine", nel tempo la isoliamo e la automatizziamo. Quindi non resta che il nuovo o il difficile.

Esistono altri modi per superare problemi come questo; alcune persone trascorrono molto tempo a considerare i problemi in anticipo e non a scrivere codice finché non si sentono a proprio agio con il design. Altri cercano la guida di persone che hanno già affrontato problemi come questo, tramite la programmazione di coppia o solo siti come questo.

Ma certamente il tuo approccio non suggerisce incompetenza. L'unico problema potrebbe essere se, quando torni indietro, non stai riflettendo sul motivo per cui hai scelto di fare cose in questo modo per cominciare, e se potresti essere stato in grado di vedere il modo "migliore" senza il riscrivere.

In molti casi, c'era, e puoi incorporarlo nel tuo processo di progettazione per la prossima volta. In alcuni casi, non c'era (o il costo sarebbe stato tanto elevato o superiore al costo del tuo altro approccio), e puoi semplicemente lasciare andare la tua preoccupazione.


8
  1. Sì, questo è comune, tranne forse per la parte "riscrivi la maggior parte del codice". Non avrai mai tutti i requisiti fin dall'inizio, quindi è importante affrontare bene il cambiamento. Questo è il concetto di "manutenibilità del codice". Naturalmente aiuta anche a dedicare un po 'più di tempo a soddisfare i requisiti e progettare correttamente.
  2. Innanzitutto, pensa a quali cambiamenti erano necessari nei progetti passati e come avresti potuto prevederli o prepararli meglio. All'inizio di un progetto, pensa di più ai dettagli dei casi d'uso. Prima di iniziare l'implementazione, fai qualche disegno astratto (quali sono i componenti principali del codice e come comunicano, quali sono le loro API). Ancora più importante, cerca di mantenere il codice il più semplice e facile da modificare possibile, leggi concetti come SOLID, DRY, KISS e YAGNI.

6

Tale pratica è comune o implica che non sono competente?

Quelli non si escludono a vicenda. Il modello potrebbe essere comune e potresti essere ancora incompetente. La tua competenza può essere determinata misurando le tue prestazioni rispetto ai tuoi obiettivi. Stai raggiungendo i tuoi obiettivi?

Questo schema è comune? Sfortunatamente sì. Molte persone si immergono in progetti senza una chiara idea di quale problema stiano risolvendo, come progetteranno una soluzione corretta e quali metriche costituiranno il successo.

Come posso migliorare me stesso su questo aspetto?

Se hai deciso di andare da qualche parte e hai appena iniziato a camminare, e poi hai scoperto un giorno in cui quello che dovevi davvero fare era trasportare un elefante da Cape Town a New York City, tutto quel tempo che hai trascorso a camminare è stato sprecato. Scopri cosa stai facendo prima di iniziare a farlo.

Una volta che inizi a farlo, considera: che aspetto ha mai il codice che non deve essere riscritto ? Quel codice:

  • Fa una cosa utile.
  • Lo fa correttamente.
  • Lo fa con prestazioni sufficienti.

Quindi: più codice scrivi dove quel codice fa bene una cosa utile, correttamente, con buone prestazioni, meno codice dovrai mai riscrivere.


1

Penso che sia sicuro dire che non sei così lontano da un modo migliore di lavorare, e non sei l'unico su questa barca.

Quello che penso ti manchi è che, sebbene tu determini ciò che vuoi, non ti fermi a fare lo stesso processo per come lo farai.

Questo passaggio per fermarsi e pensare a come affrontare il problema in generale si chiama design, è il passo che ti fa passare un po 'di tempo a sviluppare la struttura o l'architettura del sistema in modo che tutto ciò che fai da loro contribuisca alla soluzione finale, come inserendo i pezzi in un puzzle una volta elaborati i bordi.

Molte persone non eseguono questo passaggio, ma quando ho iniziato a scrivere codice era obbligatorio. Penso che la differenza sia negli strumenti di sviluppo - mentre ho iniziato con un editor di testo, ora hai tutti i tipi di funzionalità che ti consentono di saltare e digitare.

Quindi, prenditi un po 'di tempo per capire le ampie aree, i componenti e l'interoperabilità tra di loro e definire gli oggetti che comprenderanno la tua soluzione prima di iniziare a scrivere codice. Non deve essere nei dettagli immensi e capire che non lo otterrai perfettamente all'inizio, quindi si evolverà nel tempo, ma ciò che fa è per aiutarti a smettere di sprecare sforzi per rivisitare cose che non dovrebbero Non è necessario cambiarlo molto.


1

Hai già delle ottime risposte ma la tua domanda mi fa venire in mente alcune cose che pensavo di provare a toccare.

  1. Come hai notato imbattersi in cambiamenti lungo la strada, suggerirei di pensare a come le cose hanno influenzato il tuo progetto e come avresti potuto minimizzare l'impatto con le scelte di progettazione / codifica, generando allo stesso tempo una mappa mentale di dove le persone spesso apportano modifiche in ritardo. Con l'esperienza puoi anticipare e codificare un po 'di flessibilità per le cose che sai saranno importanti, anche se c'è un disaccordo su questo concetto nel settore in quanto alcuni ti contrasteranno mentre stai investendo in un'area non specificamente richiesta, di per sé .

  2. Uno dei test, lanciare un prototipo per gli stakeholder del progetto può essere un ottimo modo per affinare i requisiti. Tuttavia, durante lo sviluppo puoi cercare modi per "vedere" ciò che sta accadendo nel tuo codice senza causare molta confusione o complessità. Ci sono sicuramente strumenti disponibili per aiutarti, ma puoi anche fare molto senza di loro, se lo desideri. Ad ogni modo, uscire dal codice per vedere cosa sta succedendo con occhio critico può fornire vari tipi di intuizione.

  3. Cerca attività comuni. Ti ritroverai a gestire gli stessi problemi più e più volte. Dopo un po 'dovresti scoprire le carenze o i compromessi di varie scelte e concentrarti su una metodologia che ti aiuta a evitarle. Naturalmente, se stai lavorando in un framework, alcuni di questi problemi potrebbero essere racchiusi negli strumenti che stai già utilizzando.

  4. Se lavori in un framework, trascorri il tempo, se puoi risparmiarlo, per considerare come fare le cose da zero. Ad esempio, è possibile assemblare facilmente un messaggio di richiesta, aprire un socket ed emettere manualmente una richiesta GET o POST. Se lo desideri, puoi analizzare manualmente i messaggi XML. Qualunque cosa tu faccia, le domande che generi e le risposte che trovi aumenteranno le tue abilità. Naturalmente, puoi scegliere quali tipi di problemi sottostanti sono importanti o di interesse. Considererei questo sviluppo personale e non mi aspetterei di passare molto tempo qui.

  5. Proiettili d'argento, metodologie e problemi ad alto ronzio sono ovunque. Fondamentalmente, le realtà sottostanti di lavorare con le informazioni non stanno cambiando così rapidamente. Prendi nota del fatto che il framework, il set di strumenti o la metodologia in atto sia un aiuto o un ostacolo in varie situazioni. Nelle grandi aziende ho visto molte metodologie tentate sebbene la società non fosse in grado di eseguirle in modo efficace. Proprio come i framework, le metodologie non sono un modo sicuro per funzionare ad alto livello anche se si basano sulle pratiche di alcuni team altamente funzionali.

È difficile ridurre l'esperienza e renderla accessibile. Immagino che un modo breve per mettere tutto questo sia quello di tenere gli occhi aperti, pensare a ciò che vedi e non smettere mai di imparare.


1

Vorrei aggiungere alcuni suggerimenti

1) Personalmente ho trovato incredibilmente utile iniziare a visualizzare le cose. Disegna caselle, frecce, linee ... Non importa quale linguaggio di modellazione usi. In primo luogo lo stai facendo PER TE. Dovrebbe aiutare il flusso di pensieri.

2) Trova un partner sparring : prendi un caffè e la lavagna a fogli mobili / diagramma ecc. Dall'alto e vai in città. IMHO è ancora meglio se non hai le competenze tecniche corrispondenti. Rimbalzi avanti e indietro le idee per l'implementazione del caso d'uso. Trovi un vicolo cieco o due: trovi una soluzione. Con una mente agile c'è spesso meno tempo speso in questa fase rispetto a quando si scrive codice, non funziona e bisogna uccidere pezzi del proprio lavoro o rifarli

3) Trova un capo in grado di capire che probabilmente non hai mai finito di migliorare il tuo software scritto. Se inserisci sempre nuove funzionalità / requisiti che vengono scaricati sulla tua scrivania e non ti preoccupi mai del tuo software, ti risponderà con bug, mancanza di manutenzione e un sacco di capelli che tirano giù alcuni anni. Ottieni questo tempo di manutenzione del software / budget assegnato! Un buon numero di round round è circa il 20% del tempo necessario per sviluppare il software, necessario ogni anno per mantenerlo in forma nel corso della sua vita.

4) Questo processo di apprendimento incrementale non si ferma mai (e non dovrebbe)! Guarderai indietro tra 10 anni e sorriderai.

Spero che questo aiuti un pochino e buona fortuna!


Dovrebbe leggere "qualunque cosa". Modificato il post sopra.
Christian Meißler,

Ottimi consigli!
Dan
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.