How to Explain Coding non è solo copia e incolla per sviluppatori non software? [chiuso]

O sei troppo conservatore o troppo aggressivo nelle loro stime. Se i tempi sono diversi, allora dovrai convalidare le tue stime e le ipotesi in dettaglio affinché gli altri possano vedere e raggiungere il consenso. Non si può semplicemente dire "ci vorranno 3 settimane perché sembra il progetto X". Dovrai andare più a fondo.

Le stime di solito vengono in 2 forme:

• Alto livello
• dettagliata

Di solito esimates iniziano in forma di alto livello. Una stima di alto livello è forse la taglia T-Shirt come XS, S, M, L, XL e XXL. Di solito vengono usati per definire quanto grande sarà il progetto. Se tutti si comportano allo stesso modo, non c'è bisogno di andare oltre.

Tuttavia, se stai dicendo "medium" e stanno dicendo "extra small", allora devi entrare in una stima più dettagliata che elenca tutte le ipotesi, la funzionalità desiderata e lo sforzo corrispondente (attività) per giustificare lo sforzo medio. Ciò dovrebbe eliminare tutte le differenze in modo che tutte le parti concordino sullo sforzo stimato del progetto. Quanto dovresti andare in profondità? A scopo di stima, forse una vista di alto livello del sistema proposto che sarà costruito, i componenti e le ampie attività necessarie per costruire quei componenti.

Se stai facendo le stesse cose più e più volte, allora dovrei essere d'accordo sul fatto che le cose dovrebbero impiegare meno tempo alla seconda, terza, quarta volta. Certamente l'accesso a un database dovrebbe essere un componente comune che può essere riutilizzato. Potresti sviluppare modelli iniziali per le operazioni di tipo CRUD in modo da non iniziare da zero ogni volta.

Inoltre, se giustifichi la tua stima e tutti gli altri dicono ancora qualcosa di diverso, allora non sono logici o ragionevoli.

Problema con la copia è che copi anche i bug e aggiungi nuove funzionalità solo all'ultima copia "corrente".

Quando si copiano i bug su di te si può finire con una cultura di manutenzione in cui devi correggere i bug molte volte per ogni copia separata. Man mano che il tempo passa e il codice perde la simularità, il bug fixing non sta più "copiando". Una correzione non si adatta perfettamente all'altro progetto ecc.

Quando aggiungi nuove funzionalità che vuoi adattare a un progetto che era fonte di una copia in passato, l'azienda potrebbe aspettarsi che sarebbe facile, in pratica non così tanto, le basi di codice si allontaneranno l'una dall'altra tempo.

Il refactoring è un grande no-no, sapendo che se si migliora il codice sul progetto A resteresti comunque bloccato dalla dolorosa esperienza su tutti gli altri progetti. Fare un refactoring complesso 10 volte? Io non la penso così

Se il progetto A è solo poche modifiche di linea dal progetto B, puoi semplicemente utilizzare il codice del progetto A così com'è e condividere tra A e B. Aggiungi opzioni di configurazione per differenziare tra A e B. Creare un framework, un'applicazione o un servizio configurabile . Ecc.

Detto questo. Copio molto codice, ma solo per scopi di impalcatura. Rimuovo in modo aggressivo qualsiasi codice non necessario e cerco parti che potrebbero essere spostate in una libreria e condivise in questo modo. Si tratta di un modo valido di lavorare se si prevede che il progetto A e il progetto B abbiano un diverso asse di cambiamento (sono simili ora ma non saranno più nel futuro).

Costantemente alla ricerca di comunanza e creazione di componenti sempre più astratti e quindi componenti vaghi ha anche i suoi limiti. Disegna una linea da qualche parte e punta a domini diversi.