perfeziona il tuo codice mentre vai o FINISCA prima il prodotto, migliora la struttura più tardi [chiuso]

Benvenuti nel meraviglioso mondo di Project Management plc!

Ho scoperto che ci sono due estremi per programmatori / sviluppatori:

1. Lo Ship-it-now
2. Charles Winchester

Il primo tipo dovrebbe essere auto-esplicativo (sono il tipo di sviluppatore che vuole portare a termine il lavoro e spedirlo il più velocemente possibile, correggendo eventuali bug in seguito), mentre il secondo tipo potrebbe richiedere un preventivo per spiegare:

I do one thing at a time. I do it very well. And then I move on - Charles Emmerson Winchester III (MASH)

È la differenza tra scrivere un'app che calcola una percentuale per un dato valore utilizzando un'interfaccia a riga di comando senza controllo (Ship-it-now) e una versione con controllo completo dell'input, notifica di errore di arrotondamento e una GUI personalizzata.

Il processo che uso per scrivere software è:

• scrivi il codice (come per il documento spec / design, o il più vicino possibile)
• prima di impegnarsi, chiedimi "sono felice (entro limiti ragionevoli) con questo codice?"
• chiedi a un altro sviluppatore se posso comunicare il codice con loro

In questo modo posso spiegare perché ho fatto le cose come ho fatto e loro possono darmi un input prima di refactoring / re-design o di rimetterlo nel master branch.

Potresti impiegare anni e anni a rielaborare o ri-implementare il codice, a fissare nuovi bug non appena si presentano (e lo faranno) oppure ignorare la funzionalità creep e la necessità di riprogettare e spedire qualcosa in realtà che funziona (con pochi bug ... forse).

Come altri hanno affermato, sembra che tu possa lavorare da solo (non far parte di una società di sviluppo). Alla fine della giornata, una società di sviluppo HA per avere qualcosa da vendere, altrimenti andranno fuori mercato molto velocemente. A tal fine, la maggior parte dei project manager non permetterà a uno sviluppatore di continuare a lavorare su un pezzo di codice che (a tutti gli effetti) funziona, ma sembra un po 'brutto.

Non fraintendermi, ho usato il codice nel modo in cui descrivi. Ma questo era per i progetti di animali domestici o per il codice non importante che sarebbe stato dato a parenti / amici.

Immagina di costruire un'auto o una casa. Non vuoi vendere qualcosa che non funziona (preso nella fase di refactoring / re-design troppo a lungo e ci sono progetti reali che sono così - il più grande degli ultimi tempi era Duke Nukem Forever), ma tu Inoltre, non voglio vendere qualcosa che abbia grossi problemi. Hai bisogno di capire il miglior equilibrio. Si spera che il miglior equilibrio sia un prodotto completo con pochi o nessun problema (qualsiasi software enorme che si possa pensare); ma non è sempre il caso.

Concedersi delle scadenze potrebbe aiutarti ad apprendere le abilità necessarie nella gestione dei progetti. So che quando ero all'università, tutti i miei incarichi avevano un punteggio di gestione del tempo del 25% - se non riuscivi a dimostrare di aver gestito bene il tuo tempo (diagrammi di Gantt, lezione registrata e frequenza di tutorial, uso registrato dei laboratori , ecc.) potresti perdere punti e potenzialmente lasciare un voto.

La principale differenza tra te e un'azienda è che un'azienda ha per produrre qualcosa o perde denaro, quindi normalmente viene martellata prima che il metallo fuso si raffreddi. Con ciò intendo, mentre nulla è scolpito nella pietra, le idee sono modellate e piegate e un progetto inizia il suo lungo ciclo con le decisioni iniziali prese. Con il passare del tempo, diventa sempre più difficile cambiare come probabilmente saprai ormai.

Tuttavia, dove un normale programmatore potrebbe scartarlo in favore di un nuovo design, le scadenze sul lavoro lo fanno in modo che tu non abbia quel lusso quindi devi farlo funzionare, eseguendo qualsiasi aggiustamento necessario per farlo la scadenza. Il risultato finale è che se all'inizio non si trattava di un'idea ben strutturata, presenta urti e graffi e in genere sembra che sia stata forzatamente creata per sembrare in quel modo piuttosto che un'opera d'arte.

Anche se è vero che tutti vogliono guardare un pezzo d'arte, c'è una linea sottile tra fare qualcosa che richiede molto tempo ma che è fatto in modo notevole e qualcosa che è fatto prima ed è conveniente per il tempo impiegato esso.

Detto ciò, mi trovo a fare esattamente quello che fai a casa. 1, 2, 1, 2. L'unica conclusione che posso dedurre è che c'è così tanto margine di miglioramento, che è difficile ignorare i difetti che abbiamo fatto finora.

Penso che sia davvero una falsa dicotomia. Molte guide sulla produttività o consigli di programmazione del programmatore dipingono questa idea che tu: 1) perfeziona il codice e non rilasci mai il prodotto o 2) affronti il codice semifinito con errori. In realtà, la maggior parte del tuo lavoro sta mantenendo il vecchio codice (tuo o di qualcun altro) non implementando completamente le cose completamente nuove da zero.

In questa luce, trovare il tempo extra per ripulire le cose è quasi sempre meglio, trovo. A lungo termine, il tempo risparmiato attraverso il refactoring verso un design migliore supera il tempo impiegato a sistemare il codice errato. Anche questo effetto si combina, come di solito se non si sta lavorando per una migliore implementazione, si sta aggiungendo a uno peggiore e rendendo più difficile cambiarlo e mantenerlo in seguito.

Per il nuovo software, questa nozione conduce in modo interessante alla conclusione opposta. Dal momento che manterrai il codice per un po 'ed è molto difficile ottenere il design ideale in anticipo, di solito è meglio portarlo fuori dalla porta con il miglior design che puoi allenare in quel momento. Una volta che è in natura, il design si evolverà attraverso la manutenzione in ciò che deve essere.

Parlando della mia esperienza, ho scoperto che è un equilibrio. Avviare un nuovo progetto e plasmare l'architettura mentre si va è più difficile che mantenere un progetto esistente. Con i nuovi progetti, hai una sorta di lavagna vuota e spetta a te definire come è strutturata. I progetti esistenti hanno già definito questo e ti offrono alcuni vincoli su cui lavorare, limitando le tue scelte e, a causa di ciò, potenzialmente ti danno un tempo più veloce per implementare.

Direi che è ingiusto confrontare i tuoi progetti personali con i tuoi progetti professionali. I progetti personali sono i tuoi progetti e dovresti usarli come un'opportunità per provare obiettivamente nuove metodologie e tecnologie. Cioè, a meno che tu non stia scrivendo il progetto esclusivamente per la funzionalità, nel qual caso - perché dovresti mettere più peso sul design rispetto alla funzionalità?

Per quanto riguarda i diagrammi UML, non ho avuto alcuna esperienza nel loro utilizzo per la progettazione del progetto. Io tendo a pensare che sono un po 'pesante quando la società ritiene che la cosa più importante sia spedire il codice. Per questo motivo, tendo ad iniziare la codifica ad alto livello dopo aver riflettuto sull'approccio di ciò che voglio che il prodotto finale assomigli. Ritengo che la manutenibilità e la leggibilità siano i fattori più importanti a questo punto. Un altro problema con la documentazione è che deve essere letto per essere utile. Puoi disegnare un diagramma UML per aiutarti a pensare attraverso il design, ma anche se impacchetterai tutta la tua documentazione più tardi, qualcuno lo leggerà davvero? La documentazione non letta non è utile.

Per quanto riguarda il ciclo "codice, refactoring, codice, refactoring", è sufficiente farlo quando è necessario migliorare il codice. Evitare il refactoring per motivi di refactoring. Prendi l'approccio che stai apportando miglioramenti necessari all'architettura. Solitamente eseguo piccoli refactoring (estrapolo al metodo, convenzioni di denominazione, ecc.) E lasciano i refactoring più importanti (architettura, struttura di classe) ai tempi in cui sto migliorando il sistema o correggendo un bug particolarmente sgradevole che sembra essere il sottoprodotto del design (o mancanza di esso). Ho visto molti posti che potrebbero trarre beneficio dal refactoring, ma se la funzione funziona, non mi pasticcio a meno che non sia necessario. A breve termine, eseguirò comunque le piccole correzioni di refactoring, così so che le cose stanno migliorando.

Al lavoro, cerco di tenere a mente di "lasciare le cose meglio di come le hai trovate". Questo non significa che io sto continuamente refactoring codice con ogni cambiamento, ma che se sto facendo un cambiamento che è abbastanza significativo per giustificare una valutazione di renderlo migliore, considero le opzioni (anche di peso nel tempo che sarebbe prendere per implementare insieme a rischio, manutenibilità, ecc) e scegliere la migliore opzione bang-for-the-buck.

Parte del vantaggio di lavorare su un team che produce applicazioni è che si viene esposti a metodi alternativi di progettazione. Inoltre, sei consapevole delle scorciatoie evidenti nel design o nella realizzazione per portarlo fuori dalla porta. L'esempio coerente che ho riscontrato è la mancanza di uso del polimorfismo rispetto all'uso di variabili per controllare il comportamento. Il primo richiede un po 'più di impegno per implementare e di solito è più manutenibile e meno incline a comportamenti strani. Lo sviluppatore potrebbe aver pensato che stava solo riutilizzando il codice che è già lì, ma il peso di mantenimento a lungo termine che porta non è sempre insignificante.

Per quanto riguarda le scadenze dei progetti commerciali, ci sono molte variabili. Non tutti i progetti sono su una marcia della morte, anche se sembra essere abbastanza comune valutare la distribuzione del codice rispetto alla sua qualità. Gli utenti finali non si preoccupano dei progetti di fantasia che potresti aver implementato, tanto meno della scelta del contenitore di iniezione delle dipendenze. Sono più interessati a un software ben funzionante, accurato e affidabile che possa portare a termine il lavoro.

Should I just keep on sketching until the final product is completed before thinking of making the readability/reusability/architecture/engine more sound?

Ecco la cosa. Il prodotto finale probabilmente non esiste nemmeno nei tuoi sogni. Come può essere completato? I Compagni stanno vendendo software con supporto, il che significa esattamente che il lavoro continuerà a venire. Gli unici progetti "finiti" sono quelli morti (con poche eccezioni).

Quindi sì, se lavori in una compagnia dovresti occuparti di leggibilità / riusabilità / architettura prima della fine di un progetto perché sarai più produttivo (e non c'è motivo di preoccuparsi ...). Detto questo, prendersi cura di qualcosa non significa che dovrebbe essere perfetto (non credo che questa parola abbia comunque alcun significato nei software). Significa avere un approccio pragmatico allo sviluppo e non risolvere solo problemi a breve termine creando quelli a lungo termine quando non ce n'è bisogno.

Per i tuoi progetti domestici, fai ciò che vuoi. Se sei l'unico utente, fai quello che ti piace aggiungere funzionalità o refactoring. Se hai altri utenti, discuti con loro.

Concorda con gli altri utenti che è un equilibrio, devi essere pragmatico e devi capire l'incentivo commerciale per la spedizione anticipata.

Detto questo, tenderei comunque a fare le cose bene e amp; chiamali a destra la prima volta anziché tornare più tardi.

Se imponi un codice scadente e affrettato su decisioni di progettazione scadenti e affrettate, finisci con un pasticcio intricato che è difficile da mantenere ed estendere sorprendentemente rapidamente.

Quando sei sotto pressione aziendale, tendi a convivere con questi compromessi per un periodo più lungo del previsto, ma sicuramente inizieranno ad avere costi nascosti sempre maggiori in termini di produttività e qualità il prodotto finale.

Prima che tu lo sappia, sei completamente bloccato in un angolo a causa di tutte le scorciatoie che hai fatto. Ma l'alternativa di riscrivere tutta questa roba può finire con l'apparire di un grosso compito in sé con le "correzioni" che si mettono a rompere qualcos'altro nell'applicazione.

Come sviluppatore, ovviamente non vuoi incontrare un perfezionista che non spedirà mai perché sta rifacendo il suo codice per la centesima volta. Tuttavia, si ha un po 'di responsabilità professionale nel respingere la richiesta di prendere scorciatoie o spedire spazzatura, almeno spiegando il lato negativo del debito tecnico.