Come sperimentare un graduale miglioramento delle conoscenze mentre un principiante esegue la programmazione di manutenzione .NET? [chiuso]

Vedi la mia risposta qui per un programma .NET.

È sicuramente difficile quando sei l'unico. Devi spingere te stesso. E la rete di siti SE è fantastica. Lo considero il mio personale tutor e mentore. : -)

Un'altra cosa che potresti fare è prendere parte del tuo tempo libero personale e lavorare per migliorare il software dell'azienda. Assicurati di non controllarlo nel repository a meno che non sia stato dato il permesso, ma questo ti server su tre punti - avrai esperienza scrivendo un codice migliore, avrai esperienza di refactoring del codice cattivo / vecchio, e tu (o dovresti) prendi il brownie punti dalla compagnia.

Bene. Mantenere le applicazioni è un ottimo modo per imparare. Dovendo lavorare con un'applicazione .NET 1.1 sarebbe terribile. Ma .NET 2.0 ha la maggior parte delle basi che gli sviluppatori .NET usano ogni giorno. Approfitta dell'opportunità di imparare .NET prima di iniziare con cose come LINQ, WCF ecc. Impara dagli errori fatti dallo sviluppatore precedente e da come li hai risolti. Se qualcosa sembra strano, studia il codice e trova una soluzione migliore.

Quando sei stufo, cerca un nuovo lavoro.

Come per il tuo CV. I progetti open source sono fantastici. Unisciti a uno. Mostrerà anche che puoi lavorare su un team remoto (meglio della codifica solo, ma non buono come lavorare in un vero team). La cosa più importante con l'adesione a un progetto open source è mostrare l'ambizione e lo sforzo per imparare e migliorare.

Costruisci qualcosa di tuo nel tuo tempo libero. Rendi il codice open source, sollecita feedback, incorpora nuove funzionalità. Ecco come cresciamo tutti come sviluppatori.

(questa risposta è influenzata dalla mia esperienza personale - solo un tipo - prendilo per quello che è)

Non importa quanto tu sappia, se non stai spingendo per mantenere il bordo sanguinante, finisci per sentirti lasciato indietro. Le persone e la cultura sul posto di lavoro spesso aiutano questo a succedere e lo fanno apparire piuttosto trasparente. So di aver dato per scontato fino a 2 anni fa, quando sono caduto nella stessa situazione, essendo l'unico programmatore di un'azienda. C'è un lato positivo e un lato negativo.

Buona parte: imparare da solo è difficile perché un sacco di volte non sai nemmeno cosa devi imparare.

Cattivo lato: è troppo difficile da fare per sempre. C'è troppa utilità nell'applicare uno sforzo di gruppo a qualcosa di così complesso come scrivere un buon software.

Dato che è l'inizio della tua carriera, direi di entrare in una squadra di 18 mesi. Stare in un posto di lavoro inferiore a quello causa una bandiera sul tuo curriculum (più ancora quando l'economia è in calo).

Dai un'occhiata ad alcuni libri come "Clean Code ...." e "Refactoring". Puoi sicuramente imparare e applicare buone pratiche di programmazione anche se sei in modalità di manutenzione. La prossima volta ti chiedono di esaminare un bug o un problema per vedere se la tua soluzione aggiunge semplicemente più istruzioni if "inserite chirurgicamente" o se la tua soluzione in realtà finisce con meno linee di codice rispetto a quello che hai iniziato.

Il tuo capo potrebbe essere contrario al miglioramento del software, ma se hai bisogno di aggiustare qualcosa, devi risolverlo. Se succede, quando lo aggiusti, rimuovi anche 5 sezioni di codice copiate / incollate e crei una classe che contiene il lavoro che è stato eseguito 12 volte in vari punti, in modo che sia quello che è. Non devi fare miglioramenti casuali, ma concentrarti su aree specifiche in cui ti chiedono di lavorare.

Ho fatto manutenzione e diventa orribile solo se inizi con un codice non buono e continui ad aggiungere hacker per risolvere problemi specifici qua e là fino a quando il codice non è più un pasticcio di spaghetti di quando hai iniziato. D'altra parte, è bello vedere un software esistente dopo aver corretto 15 bug separati con la stessa funzionalità, ma contenere 3000 righe di codice rispetto a 9000 quando hai iniziato a lavorarci. E con abbastanza pratica, potresti arrivare a un punto in cui non vedrai mai più il 16 ° bug scritto su questo codice.

Direi che se ti interessa e vuoi imparare, potresti imparare di più sul nuovo sviluppo e sulla scrittura di codice pulito, affidabile / gestibile, prima sperimentando ciò che accade quando gli altri prima di non farlo.

In primo luogo, non limitarti a .NET, .NET solo gli sviluppatori sono una dozzina di dozzine e vale lo stesso. Prova a padroneggiare la programmazione e non solo una tecnologia specifica. Raccomando l'apprendimento di c e c ++ oltre a c # in quanto queste due lingue avranno l'effetto di darti una maggiore comprensione del perché .NET funzioni come fa. Inoltre, so che a volte potresti non avere questa scelta, ma quando puoi, tirati fuori da un vicolo cieco che hai solo fatto manutenzione. Vai a trovare qualcosa in cui ti trovi in un team di sviluppo. Se non puoi farlo, entra in un progetto open source per il tuo tempo libero. Spesso è molto facile andare d'accordo e di solito sono molto accoglienti con i ragazzi giovani che vogliono imparare. Invia via e-mail il lead del progetto, comunicagli la tua situazione e chiedigli di indirizzarti verso alcuni bug che puoi correggere o alcune funzionalità che puoi implementare. In questo modo otterrai la buona esperienza e le recensioni tra pari necessarie per diventare un buon sviluppatore.

Come altri hanno detto .... inizia creando un portfolio in cui stai utilizzando alcune delle cose moderne in .NET .... non fare affidamento sull'applicazione del tuo datore di lavoro, potresti aspettare anni.

Ho già fatto questo errore prima. Ho passato un intero anno a lavorare su una vecchia e pessima applicazione .NET 2.0 per un datore di lavoro che praticamente nutriva bugie su noi di aggiornare l'intero sito da VB.NET 2.0 a 3.5 in C # nel corso di un anno, era come un mai raggiungere l'obiettivo ... (3.5 era l'ultimo all'epoca).

Alla fine abbiamo effettivamente scritto la nostra prima riga di codice (per convertire l'app VB esistente in c # 3.5) ..... e poi sono diventato ridondante ...

Quindi sono tornato al mercato del lavoro, e non riuscivo a credere a quanto mi mancasse essere bloccato su .NET 2.0 ..... ora avevamo cose come LINQ, Entity Framework, MVC 1.0 ecc. nella maggior parte delle inserzioni di lavoro .... di cui non sapevo molto.

The morale is that it isn't really my employer to blame for this, I take the blame for not being proactive in my own time to learn these new features and create samples...

In questo momento, ho lavorato con un nuovo datore di lavoro su un'applicazione Web ASP.NET 3.5 e non vi è alcun segno di ciò che, in ogni caso, passeremo a ASP.NET 4.0 MVC in qualsiasi momento ... ma non è così fermandomi, sto già imparando su MVC 3.0 nel mio tempo.

Ps. Se puoi hackerarlo, resta con te il tuo attuale datore di lavoro finché puoi, ma riposa nella consapevolezza che è "OK" smettere se davvero non vuoi essere lì - Ho lasciato il mio primo lavoro (motivi personali) dopo 3 mesi ... alcuni lavori "a lungo termine" in seguito sono ancora occupato:)

Parla in modo informale con alcuni dei manager degli altri dipartimenti e guarda come si sentono riguardo alle attuali applicazioni. Almeno uno di loro ha un'idea per qualcosa di nuovo e lo presenterà sotto forma di: "Sai di cosa ho davvero bisogno ..." Ovviamente, non vuoi andare dietro la schiena del tuo manager, ma far apparire il idea. Non si sa mai.

Adatta la tua mentalità. Potresti non riuscire a lavorare su una nuova app, ma nuove funzionalità. Guarda come imparare il codice refactoring. Il tuo manager lo vedrà come una perdita di tempo (non aggiustarlo se non è una mentalità rotta), ma questo è solo parte della tua manutenzione.

Ci sono strumenti che puoi realizzare per il mantenimento del progetto su cui stai lavorando? Ciò ti aiuterà a imparare cose nuove / diverse e allo stesso tempo ti aiuterà a semplificare il tuo lavoro quotidiano.

Bene, la mia risposta è duplice.

1. Non importa dove lavori o con chi lavori, in definitiva sei responsabile per il tuo sviluppo professionale. Esistono molti modi per migliorare la codifica: ecco alcuni suggerimenti . Se sei da solo, specialmente all'inizio della tua carriera, questo rende difficile. Vorrei cercare un mentore o mentori. Ciò significa frequentare gruppi di utenti pertinenti nella tua zona, seguire un corso (online o di persona) o magari pagare un CS studente, o professore, o un programmatore più anziano per fare da tutor.

2. Per molti, se non per la maggior parte delle persone, la risoluzione dei bug è un importante precursore per risolvere problemi di grandi dimensioni e, infine, eseguire la progettazione del programma. Anche se non si fa la programmazione di manutenzione, è importante averlo fatto, perché la maggior parte delle organizzazioni spende la maggior parte del proprio "sviluppo" in dollari per la manutenzione. Qualcuno ha suggerito "Clean Code" e "Refactoring" che sono ottimi suggerimenti, ma è importante notare che scrivere codice mantenibile ha il proprio (piccolo) genere di letteratura - è importante!

La risoluzione dei bug ti offre una panoramica delle peggiori decisioni degli altri, il che è importante! Ma assicurati di avere anche il tempo di guardare le parti del codice che funzionano, non solo le parti rotte. Le aree che non devi toccare sono probabilmente scritte bene e ti forniranno alcuni esempi positivi.

Sono d'accordo con gli altri a non rimanere in pura manutenzione per sempre (a meno che tu non voglia). Scrivere un nuovo codice è molto divertente e generalmente un'esperienza molto più positiva. Ma la programmazione di manutenzione non ti farà certamente del male, e avere qualche anno di allenamento ti renderà sicuramente un programmatore migliore.