Come si esce dal ruolo di manutentore del codice? [chiuso]


13

Nei miei ultimi tre lavori, ero un manutentore del codice. In tutti e tre i casi, sono stato assunto dopo che la maggior parte del codice per il progetto era già stata scritta.

Sono un programmatore autodidatta. Prima di iniziare il mio primo lavoro professionale, avevo forse una dozzina di progetti che avevo avviato e spedito con successo.

Scrivere nuovo codice e mantenere il codice esistente sono due lavori completamente diversi. È come confrontare un ingegnere aeronautico con un meccanico aeronautico.

Fa particolarmente schifo quando sei un meccanico aeronautico che lavora su un aereo progettato da un ingegnere che non ha fatto alcun tentativo di progettare l'aereo per essere in qualche modo logico o facile da mantenere.

Sto iniziando a sentirmi come se fossi in giro quando il progetto è iniziato, devi essere una di quelle persone speciali che in qualche modo hanno trasceso il resto delle persone nel campo dell'informatica. Cosa ci vuole per essere in quella posizione?

Sento che questa domanda non ha davvero una risposta facile, ma qualcuno potrebbe darmi qualche idea? Sei mai stato al piano terra di un nuovo progetto? Cosa ci è voluto per arrivarci?


Ti candidi per lavori di manutenzione del codice?
James,

@James tutti i lavori sono lavori di manutenzione del codice, o almeno tutti quelli che ho incontrato ...
nbv4

Non scoraggiarti. Nella tecnologia nulla è permanente. Potresti sentire il meccanico contro l'ingegnere. Ma penso che ci siano molte aziende con leader autodidatta e api operaie con titoli avanzati. Lo status, la conoscenza e gli sforzi per conformarsi all'istruzione formale dovrebbero avere qualche ricompensa, ma è la tua risposta a "Che cosa hai fatto per me ultimamente?" è meglio, fa molta strada.
Sviluppatore:

Risposte:


6

La manutenzione significa cose diverse per persone diverse e avviene per diversi motivi.

  • Nel peggiore dei casi, il sistema iniziale è stato messo insieme in fretta, la squadra iniziale ha preso il merito di tutto. Hanno seguito la regola 80/20, quindi mentre potrebbe esserci un prodotto minimo realizzabile che può essere venduto, molti clienti hanno bisogno di molte correzioni e piccoli miglioramenti. Molti problemi, ma non rimane molta gloria. Hai il lavoro più difficile, ed è ingrato. Spero che questa non sia la tua situazione.
  • Nel migliore dei casi, hai dimostrato di essere attento con il tuo lavoro e di cui ti puoi fidare per apportare modifiche al prodotto messo in campo senza romperlo. Quali problemi rimangono troppo difficili per le persone che hanno martellato il sistema originale insieme. Forse non sono riusciti a costruire il sistema per durare e tu sei lì, forse come loro sostituto, per sistemare le cose e salvare i clienti, il progetto e i profitti.
  • Molto probabilmente, il 60% dei costi dei progetti arriva durante la manutenzione. Forse è il momento, forse la tua organizzazione segrega tra nuovo sviluppo e manutenzione, ma sei nella maggioranza dei 3/5 perché molti di noi eseguono la manutenzione.

Ecco alcune cose da provare:

  • Fare un ottimo lavoro, avere un grande atteggiamento, essere un leader dell'idea.
  • Per quanto possibile, lavora in gruppo, non da solo.
  • Impara lingue più recenti.
  • Scopri le piattaforme più recenti.
  • Richiesta di lavorare su programmi più piccoli, magari anche con aziende più piccole.
  • Diventa esperto e partecipa alla documentazione. Quando i progetti iniziano, anche nell'era post cascata, hanno bisogno di molto coordinamento scritto per pianificare, documentare, valutare e chiarire i requisiti.
  • È pericoloso che i progetti inizino nelle mani di persone che non apprezzano la gestione dei requisiti, la stima e la valutazione dei rischi, quindi apprendi e esercita queste competenze il più possibile.
  • Ottieni formazione o certificazioni più formali. Ciò può aumentare il tuo status e renderti una scelta più interessante quando si formano squadre per nuovi progetti di sviluppo.
  • Avvia una società o qualche consulenza sul lato. Questo ti offre uno sbocco creativo per indirizzare il tuo tipo di lavoro preferito e ti dà un migliore apprezzamento di com'è iniziare senza codice o documentazione.
  • Avvicinati al tuo capo e alle persone che pianificano nuovi progetti.
  • Al contrario, se sei molto vicino ai tester e al QA, il loro output è spesso l'input per la manutenzione, quindi indovina con chi il tuo capo pensa di lavorare davvero bene?
  • Fai il maggior numero di amici e guadagna il rispetto di quanti più sviluppatori greenfield puoi.
  • I nuovi sviluppatori sono capaci di fare le persone, quindi fai attenzione a qualsiasi accenno di critiche o negatività. Dai loro le tue idee liberamente senza colpa o giudizio. Le tue idee non hanno bisogno di presentazioni, basta dirle. Non dire mai, lo facevamo in questo modo, o che non funziona, prova questo. Non dire mai, non lo so, ma potrebbe funzionare. Di 'solo l'idea. O meglio, mostralo.
  • Trova e cogli l'occasione per creare una prova di concetto che potrebbe trasformarsi nel tuo nuovo progetto.
  • Fai attenzione a chi ti assegna il lavoro. Di solito, dovrebbe essere qualcuno nella tua catena di comando. Se sono i tuoi colleghi, respingi un po 'di tempo. Se è qualcuno che controlli, ci deve essere una buona ragione per cui il controllo si sta invertendo. Se si tratta di QA o test, assicurati che sia importante per la tua catena di comando e non sia pianificato in modo tale da ritardare il lavoro promesso in precedenza.
  • Attenzione alla perfezione. Il nuovo sviluppo è spesso riservato alle persone veloci, anche se incrociano gli occhi e non punteggiano le t.
  • Trascorri il tempo imparando e mettendo in pratica le abilità progettuali iniziali adeguate alla tua linea di sviluppo. Ciò potrebbe includere: la creazione di repository di origine, la definizione dell'ambiente di compilazione, la configurazione del server di integrazione costante, la stretta collaborazione con il team hardware per creare nuove schede con pacchetti di supporto delle schede o scrivere potenza sugli autotest. Potrebbe anche aiutare a sapere come lavorare con gli acquisti per acquistare nuovi strumenti di sviluppo, formazione e hardware COTS.
  • Assicurati di andare avanti prima della chiusura del tuo progetto di manutenzione, magari acquistando le tue abilità internamente in team leader e forse manager, o esternamente.
  • Sii fluente in ogni tecnologia che conosci e conosci molte tecnologie.

Un ruolo di manutenzione può essere trasformato a tuo vantaggio in diversi modi.

  • Puoi potenzialmente lavorare su ogni progetto realizzato dal tuo gruppo o persino dalla tua azienda.
  • Se il nuovo sviluppo e la manutenzione sono separati, è possibile seguire potenzialmente un percorso di leadership meno competitivo. Il lead su nuovi progetti è molto ambito, ma il lead per la manutenzione potrebbe essere disponibile per la richiesta. Se hai incoraggiamento e tutoraggio da offrire, i membri di quel team potrebbero apprezzarlo di più.
  • Se il progetto è in manutenzione, è più probabile che si interfaccia con i clienti. Gestito in modo sbagliato, questo pone fine alle carriere. Se gestito correttamente, ottiene un'attenzione positiva fuori dallo sviluppo che è difficile da trovare senza essere un manager.

Detto questo, sono il contro-esempio, non il modello. Gran parte di questa prospettiva deriva dall'esperienza e dall'osservazione.

Ci sono molti nuovi programmi che devono ancora essere scritti.
Sii pronto e ci lavorerai sorprendentemente presto.


4

Ho una brutta notizia per te: molte delle applicazioni di cui l'umanità ha bisogno sono già state scritte, è solo che dovrebbero essere messe a punto per l'ambiente in costante cambiamento.

Un giorno ti verrà chiesto di scrivere una nuova parte del sistema, come un nuovo modulo, e puoi sfruttare le tue conoscenze sullo sviluppo del campo verde.

Fino ad allora, puoi provare a imparare le applicazioni legacy di refactoring per pulire i moduli.

Una buona lettura è " Lavorare con le applicazioni legacy " e " Refactoring to Patterns ". Se non hai letto il Refactoring originale (Fowler), ti preghiamo di farlo. E impara lo sviluppo guidato dai test (TDD), aiuta sempre.

Nel caso in cui tu stia lavorando con PHP, ho scritto un articolo pratico questo codice funziona ancora ...

Divertiti!


1

La via più semplice per fuggire è cambiare completamente il tuo stile di programmazione e aggiungere nuove abilità contemporaneamente. Ad esempio, potresti provare a fare il ricercatore. Potrebbe non essere un lavoro di prestigio per il primo anno, e certamente non è così pagato come i normali lavori di programmazione (nel primo anno se sei un ricercatore / ricercatore associato nel team di un'università - ovviamente come ricercatore senior è carino molto in linea con il resto del settore), ma metterà sicuramente le tue abilità al lavoro sui problemi più difficili che puoi trovare oggi. Dopo un tale lavoro potresti facilmente passare a una posizione migliore, a condizione che tu abbia alcuni progetti interessanti da mostrare al tuo prossimo capo.

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.