Come posso capire se un altro progetto è principalmente manutenzione e bug? [chiuso]

0

Ho iniziato a lavorare in una società relativamente grande che sfortunatamente ha la sua parte di un bel po 'di codice legacy e ho finito per passare una quantità extra di tempo in manutenzione e correzioni di bug.

Mi piacerebbe cambiare progetto come in superficie ci sono altri progetti che sembrano "interessanti". Il problema è che non sono sicuro che sia meglio.

Ho chiesto ad alcuni colleghi di vedere cosa sta succedendo e loro "affermano" di essere coinvolti in cose interessanti, ma in realtà non li credo come in uno dei casi che so per certo che è la stessa situazione di me sono.

Quindi la mia domanda è la seguente:

Se non ho qualcuno che possa davvero fidarmi di fare una buona scelta sullo scambio di un altro progetto, c'è un modo per scoprirlo (voglio dire se è uguale ovunque)?

Un'idea sarebbe quella di fare un po 'di ingegneria "inversa", cioè iniziare a monitorare ogni persona che si impegna nel repository per capire a cosa si è occupato. Ma questo approccio mi sembra irrazionale.

Sicuramente ci deve essere un modo migliore?

    
posta user10326 01.08.2014 - 00:03
fonte

2 risposte

5

La cosa principale da capire è quanto è vecchio il progetto e sta sostituendo / convertendo un altro progetto o veramente un nuovo progetto non tentato prima.
Cercherò di scoprirlo parlando con le persone attualmente presenti nel progetto. Ovviamente usa una certa discrezione, chiedi loro cosa fanno effettivamente e tracci le tue conclusioni.

Potresti anche trovare i seguenti punti di vista che vale la pena di meditare:

  • generalmente l'80% della programmazione è manutenzione e correzioni di bug.
  • considera il codice legacy per includere ... il codice che hai attualmente in produzione
  • Il codice legacy
  • è anche il codice che ... paga le bollette. e forse il tuo stipendio.
  • non appena è attivo un nuovo progetto, sono necessari manutenzione e correzioni di bug.
  • i nuovi progetti hanno spesso più bug del previsto quindi il passaggio alla risoluzione dei bug è spesso rapido.
risposta data 01.08.2014 - 01:31
fonte
1

TL; Versione DR:

Verifica se il dominio del progetto ti interessa e guarda l'intero ciclo di vita, non solo il codice, per vedere se le attività in corso sono interessanti per te.

Elaborazione un po ':

Per capire dove un progetto è in termini di sviluppo veramente nuovo rispetto a manutenzione e debug, guardando il codice e il codice il check-in probabilmente non è abbastanza IMO.

Inoltre, è necessario esaminare altre attività del ciclo di vita.

I nuovi requisiti sono definiti? Questi requisiti possono essere soddisfatti con modifiche al codice esistente o è necessario un nuovo codice?

C'è un progetto in corso? Di nuovo, questo sviluppo o modifica totalmente nuovo?

Spesso la risposta è entrambe. I nuovi requisiti e il nuovo design sono spesso soddisfatti con un mix di sviluppo completamente nuovo, manutenzione ed espansione della base di codice esistente.

Quindi non puoi necessariamente equiparare manutenzione e bug fixing con "poco interessante" - spesso alcune delle più grandi sfide tecniche sorgono in queste fasi.

Infine, per quanto riguarda "cool" - è troppo una questione di opinione personale. Per alcuni, forse lavorare a Google o una startup Web è l'epitome di "cool", ma qualcuno che fa calcolo scientifico, o sviluppo embedded o software medico, potrebbe trovare Google poco interessante al confronto, che ci crediate o meno. Quindi è difficile commentare specificamente su questo aspetto.

    
risposta data 01.08.2014 - 04:18
fonte