Sfortunatamente la manutenzione è la regola quando si lavora nell'IT, molto raramente ci sono nuovi progetti e le persone vengono riassegnate regolarmente ai progetti. E sebbene la qualità del codice che dovrai mantenere nella tua vita professionale varierà notevolmente, non avranno mai lo stesso odore di un nuovo progetto di 2-6 mesi.

Tuttavia, ci sono cose che puoi fare forse per rendere la tua vita e il tuo futuro un po 'più vivibili. Comincerei con la scomposizione mentale del progetto corrente in moduli, quindi chiedendo il permesso di rifattorizzare o riscrivere quelli, uno alla volta, in conformità con standard di codifica più rigorosi. Assicurati di scrivere molti test su tutto ciò che scrivi o migliora.

Questo dovrebbe vedere la tua vita lavorativa migliorare lentamente e costantemente, poiché questo approccio ti consentirà di familiarizzare con l'applicazione, migliorare la leggibilità delle parti di esso e rendere i bug meno comuni.

Il modo in cui venderlo al proprietario / leader / capo varia ampiamente a seconda della struttura aziendale e delle personalità coinvolte. Ma se questo è davvero insopportabile per te e non hai il potere di migliorare le cose, allora trovare un diverso tipo di lavoro potrebbe essere meglio.

In generale, sembra che i consulenti in generale lavoreranno di più codice recente e hanno maggiore flessibilità per essere spostati da un progetto a un altro o per concentrarsi principalmente su nuove applicazioni (ish).

Tuttavia, il codice legacy farà sempre parte della professione scelta, e dovrai imparare ad andare d'accordo e convivere con questo fatto.

Sì, è ragionevole dire al tuo manager che non ti piace il tuo lavoro e chiedere qualcosa di divertente.

È anche ragionevole che quel manager ti chieda di resistere. C'è un lavoro che deve essere fatto e il lavoro non può essere sempre divertente.

Un buon manager si renderà conto che sta bruciando la tua utilità e disponibilità a lavorare per lui e cercherà di farlo fare in modo che tu possa dedicare un po 'di tempo a diversi progetti ma questa non è una garanzia! Se sei l'unico sviluppatore in grado di fare questo lavoro, potresti essere bloccato lì.

Per aiutare questa linea d'azione è una buona idea preparare qualcosa su cui vorresti dedicare il tuo tempo: quei progetti che hai iniziato, forse qualche altro progetto o anche un corso per migliorare le tue capacità. Questo ti aiuterà a trasformare una richiesta in un Piano.

Un cattivo manager ti risentirà perché "si lamenta di cose stupide", questo è irragionevole ma non saresti il ​​primo per ricevere respingimenti.

Per evitare ciò, procurati un elenco concreto di cose che rendono il lavoro non divertente: bug stupidi, ticket ripetuti, codice non commentato. Questo trasforma un reclamo in Feedback e renderà le tue domande più ragionevoli.

La mia domanda: sarebbe ragionevole chiedere al mio manager di inserirmi in un altro progetto perché davvero non mi piace il lavoro che devo fare ora e come lo dico?

No, non sarebbe ragionevole. Parte dell'essere un programmatore è mantenere i programmi esistenti sia che si tratti di aggiungere / rimuovere funzionalità o correggere errori. Sei stato fortunato ad aver lavorato su alcuni progetti che hai iniziato da zero, ma non puoi aspettarti che ogni progetto sia così. A volte, per un periodo di tempo, l'azienda non ha bisogno di nuovi progetti avviati da zero (ciò non significa che non lo faranno mai più) e devono solo mantenere i progetti esistenti.

Cosa dovresti fare è assumere la proprietà del tuo progetto attuale. Dimentica il fatto che ha 6 anni e altri 5 programmatori ci hanno lavorato. Se è disordinato e pieno di bug, prendi l'iniziativa per correggere il progetto. Avrai sicuramente un aspetto migliore agli occhi del tuo manager se porti con successo il progetto a uno stato stabile invece di lamentarti di dover lavorare su questo progetto e cercare di avere un lavoro diverso assegnato a te.

Puoi sempre chiedere, ma anche loro possono sempre dire di no.

A meno che tu non abbia nel tuo contratto che lavorerai solo sui progetti che ti piacciono, possono metterti sui progetti come vedono fit.

Potresti documentare le modifiche che vorresti fare (refactoring, scrittura di documentazione, ...) e i vantaggi per l'azienda in termini di tempo guadagnato con meno bug.

Oppure potresti sostenere un nuovo sviluppo del prodotto con pratiche migliori. Ma finché il vecchio progetto ha utenti paganti, qualcuno deve mantenerlo e hanno scelto te Pikachu.

Potresti sostenere di convincere più persone a fare quello che stai facendo (fattore Bus) in modo che tu possa lavorare anche su altri progetti. Se questi diventano più importanti del progetto legacy, quelli potrebbero diventare un'uscita.

Ma ancora: finché ci sono persone che pagano la tua azienda e in estensione pagano i salari dei tuoi capi per questo progetto, e la tua azienda non lo è. T propenso a rinunciare, qualcuno dovrà correggere i bug.

Potresti lasciare e lavorare come libero professionista come ultima risorsa. Lì puoi davvero scegliere i progetti su cui stai lavorando, ma preparati a dover fare alcuni progetti che non ti piacciono molto per tenere le luci accese. Solo i migliori e i più conosciuti possono scegliere quello che fanno completamente.

tl; dr: sii onesto con il tuo datore di lavoro. Di 'loro che sei interessato solo ai progetti greenfield. Tieni presente, tuttavia, che prendere questa decisione limiterà in modo significativo il lavoro che ti verrà offerto, forse al punto che i tuoi servizi non saranno più necessari.

Una delle cose più importanti nello sviluppo di software professionale è la collaborazione su una base di codice condivisa. A meno che tu non sia un solista rock star, il codice base avrà sempre una storia, plasmata da colleghi del passato e del presente - e forse anche te stesso nel passato .

Come hai già detto, leggere il codice è molto più difficile che scriverlo, motivo per cui questa abilità è così importante. Ci vuole molta abilità e pazienza per imparare e comprendere gli angoli e le fessure di un progetto esistente. È più facile - e scontato, più piacevole per lo sviluppatore - ricominciare da capo, magari anche scegliendo le tecnologie e i framework utilizzati.

Il software commerciale serve sempre uno scopo aziendale . Ciò significa che, a meno che non si lavori solo con startup o marketing, il software dovrebbe avere un'aspettativa di vita ragionevole. Gli sviluppatori che fanno il possibile per familiarizzare con le soluzioni esistenti e, in particolare, gli interessi commerciali esistenti , sono quelli che si rendono preziosi e spesso difficili da sostituire.

Come te ho sottolineato, il codice legacy non è sempre (mai?) facile da lavorare, privo di bug o pulito. Quello che ti suggerisco di considerare è di cambiare le cose: ogni frammento impossibile di spaghetti copia-pasta è una opportunità per un grande refactor con unit test; ogni segnalazione di bug è un'opportunità per impressionare l'azienda e gli utenti finali con un servizio clienti impeccabile.

Il mio team attualmente gestisce due prodotti che appartengono alla nostra azienda quando la nostra azienda ha acquistato gli sviluppatori originali. Il motivo per cui questi acquisti sono stati possibili è perché le altre società non stavano andando bene finanziariamente.

Lavoro solo su uno dei due prodotti. All'inizio era come essere un tassidermista che lavora per uccidere la strada. Il team di programmazione originale non dovrebbe mai più essere autorizzato a toccare i computer. Il mio supervisore è responsabile per l'altro prodotto, ed è anche un disastro.

Il vantaggio principale di lavorare su questi incendi di cassonetti è che stiamo ricevendo buone e solide lezioni su come non fare cose, e anche con tre anni nel settore stai imparando qualcosa del genere dai prodotti su cui stai lavorando.

Quindi smetti di considerare la tua situazione come qualcosa con cui non dovresti avere a che fare e invece consideralo come il modo in cui intendi rendere il prodotto della tua azienda migliore di quello che era.

Come primo semplice passaggio, ogni volta che devi capire cosa fa un pezzo di codice, inserisci dei commenti nel codice che spiega esattamente cosa sta facendo il codice. Potrebbe non aiutarti, anche se trovo che sia di grande aiuto per me, ma la prossima persona che guarda il codice non dovrà risolverlo.

Già molte ottime risposte, ma aggiungendo i miei £ 0,02.

Mantenere un vecchio software è più difficile che creare qualcosa di nuovo, è anche un'abilità preziosa in sé.

Essere in grado saltare in una base di codice che esiste da anni, con documentazione scadente o assente e con molti stili di codifica diversi dai molti sviluppatori che ci hanno lavorato è qualcosa che molti datori di lavoro, in particolare nel mondo aziendale, cercano attivamente.

Se non c'è documentazione, scrivine un po '. Se non ci sono test automatici, lavora sul refactoring del codice in modo che sia testabile e scrivi alcuni test. Se gli stili di codifica sono ovunque, cerca gli stili consigliati per la lingua o il framework e lavora sul refactoring della base di codice in modo che corrisponda allo stile di codifica consigliato.

Acquisire la reputazione di qualcuno che è felice di lavorare con il codice legacy e chi lo fa bene può essere utile per la tua carriera quanto lavorare su progetti greenfield con i nuovi e brillanti framework.

Col ​​passare del tempo, la quantità di codice legacy in produzione è aumenterà e la domanda di sviluppatori che possano prendersene cura, correggere bug e aggiungere nuove funzionalità aumenterà insieme ad essa, poiché la riscrittura di tali applicazioni con nuove tecnologie è generalmente considerata una cattiva idea per molti buoni motivi.

Buona fortuna!

La manutenzione legacy sviluppa il desiderio dello sviluppatore di buone pratiche

Voglio solo aggiungere la prospettiva di uno sviluppatore principale, perché come sviluppatore sono d'accordo con non voler mantenere il codice legacy, ma come sviluppatore principale Non sostengo che alcuno sviluppatore lo eviti.

Userò un esempio pratico per esporre il mio caso. In qualità di consulente, vengo spesso inviato in un'azienda / progetto con problemi di qualità del codice, dove il mio lavoro è sistemare le cose. Come sospetterai, un codice errato porta a molta manutenzione legacy.

È stata la mia esperienza predominante che gli sviluppatori che scrivono codice errato si trovino in uno dei due campi seguenti:

• Coloro che non conoscevano meglio
• Coloro che pensano di fare la cosa giusta

Il primo gruppo è facile da affrontare, perché migliorerà immediatamente quando mostri loro una buona pratica. Quest'ultimo gruppo, tuttavia, è molto più difficile da convincere in quanto non vedono i benefici delle buone pratiche, che spesso richiedono maggiori sforzi a breve termine. Ripaga i dividendi nel lungo periodo, ma quest'ultimo gruppo spesso non riesce a raggiungere questo punto.

Quasi tutti gli sviluppatori con cui ho avuto a che fare che erano in quest'ultimo campo erano sviluppatori che sono riusciti a passare da un progetto all'altro saltare la manutenzione del proprio codice . Poiché non hanno mai dovuto affrontare le conseguenze delle loro decisioni di progettazione imperfette, non sono mai stati incentivati ​​a cercare di evitare che questi problemi si verificassero prima che si verificassero, quando l'applicazione è stata inizialmente creata.

La soluzione è semplice: gli sviluppatori devono assumerne la proprietà . Se scrivi codice difettoso, gestirai i bug che ne derivano. Se non vuoi spendere il tuo tempo a correggere i bug, spetta a te scrivere codice che non li produca.
Questo crea un incentivo molto semplice per gli sviluppatori a migliorare se stessi, invece di essere spinti in esso contro la loro volontà e senza la loro comprensione del motivo per cui è l'approccio migliore.

Quello che voglio che tu sappia da questo è che la manutenzione precedente è essenziale per gli sviluppatori per ricordare perché hanno bisogno di buone pratiche .
Per analogia, un generale che è in trincea con i suoi uomini prenderanno decisioni migliori (per i soldati) di un generale che siede comodamente in un palazzo dall'altra parte del paese. Uno sviluppatore deve sporcarsi le mani in modo che quando è il generale (= costruisce la nuova applicazione) sa qual è l'impatto delle sue decisioni di progettazione.

Ripulire dopo gli altri

Tu, tuttavia, non devi affrontare i tuoi bug, ma piuttosto quelli delle persone che sono venute prima di te. Al momento mi trovo sulla stessa barca e sono d'accordo con te sul fatto che questa non è una situazione sostenibile.
A nessuno piace la manutenzione legacy e sembrerebbe che il tuo manager non abbia preso in considerazione il fatto che tu esegui esclusivamente la manutenzione legacy sia influenzando il tuo morale e lo sviluppo della tua carriera personale.

Ho passato 3 anni a fare la manutenzione tradizionale, ma è stato un lavoro comodo con una politica di lavoro da casa molto libera. Mi ci è voluto un po 'per capire che mentre l'equilibrio vita / lavoro non era male, la mia carriera era in stallo perché non stavo acquisendo conoscenze di attualità per il settore. Se fossi stato licenziato da quel lavoro dopo 5 anni, il mio bagaglio di competenze sarebbe così obsoleto per altre aziende che dovrei affrettarmi per recuperare il tempo perso.

D'altra parte, qualcuno deve supportare questo progetto. Quindi non puoi semplicemente adottare un approccio "non io", perché ogni sviluppatore promuoverà lo stesso approccio "non io" e quindi la direzione è passibile di nominare qualcuno che abbia disegnato la paglia corta (questo potrebbe essere il modo in cui sei finito in questa posizione per cominciare).

Risolvere il problema

Avvicinati al tuo manager e spiegagli che mentre capisci che il progetto legacy richiede supporto, è uno spreco di morale quando non fai altro ma gestisci il vecchio codice. Chiedi se il tuo manager considererebbe la possibilità di assegnarti un progetto part-time diverso (non legacy).

Nella mia esperienza, i manager più ragionevoli lo capiranno (probabilmente sei stato assegnato a questo perché gli altri 5 sviluppatori che hanno lasciato tutti hanno sostenuto lo stesso punto) e vedranno il vantaggio di tenerti (qualcuno che sa già il progetto legacy) sul progetto part-time, invece di doverti lasciare e dover trovare un nuovo sviluppatore che non conosce il progetto legacy.

Ma nella mia stessa esperienza, ci sono anche aziende in cui il morale dei dipendenti è notevolmente più basso nell'elenco delle priorità, dove impiegano un approccio più rigoroso "fai quello che ti diciamo di fare".
L'unico consiglio che posso dare qui è di lasciare un ambiente così tossico. Non lasciare che la tua carriera si sprechi facendo un lavoro che odi per un'azienda che non apprezza la tua soddisfazione lavorativa (in misura ragionevole).

Se non ti piace quello su cui stai lavorando, parti per un'altra azienda. I programmatori sono molto richiesti.

Assicurati di trovare in anticipo i tipi di lavoro che farai. Non criticherò nessuno per aver lasciato nella tua situazione, sembra orribile. Ma se fossi assunto sapendo che avresti lavorato a questo tipo di progetto, sarebbe di cattivo gusto lamentarsene.

Raramente c'è molto spazio per cambiare il tuo lavoro quotidiano all'interno di un azienda, queste cose tendono ad essere a lungo termine e sono quasi sempre inferiori alla semplice ricerca di un altro lavoro facendo qualcosa che si desidera fare.

Dipende dall'azienda. Nel mio ultimo lavoro, la mia azienda offre soluzioni IT al governo e alle banche. Quindi ogni volta è un nuovo tender e un nuovo progetto. Faccio parte del team di sviluppo, che prende parte alle gare d'appalto, alla progettazione e alla realizzazione dei progetti. Dopo il rilascio in produzione, il team di manutenzione subentrerà e ci contatterà solo per problemi che non possono gestire. Quindi un'azienda di natura diversa potrebbe essere una soluzione.

Ma puoi vedere la tua situazione sotto una luce diversa.

Se il software che stai mantenendo è cattivo, allora aggiustalo . Se va oltre la soluzione, spiega al tuo supervisore perché è così e proponi una soluzione.

Ciò che consideri una brutta situazione, potrebbe invece essere un'opportunità per mostrare al tuo supervisore di cosa sei capace.

Se il tuo supervisore ti vede in una luce positiva, dovresti una possibilità molto migliore di essere assegnato ai progetti che vuoi fare, o convincerlo / lei a riassegnarti.

Nel mio attuale contratto di 2 anni, sto mantenendo un software scadente come te. Il fornitore originale è andato via da tempo e la qualità del codice è scadente. Il mio supervisore è riluttante a grandi cambiamenti poiché la cultura aziendale è molto riservata e odiano correre rischi. Ho presentato i pro e i contro di varie opzioni per aggiustare la parte su cui sto lavorando, mi ci è voluto molto ma alla fine li ho conquistati. Qualche mese dopo, il mio supervisore sta parlando di offrirmi una posizione permanente.

Gli eroi nascono dall'occasione.

Mettiti negli altri panni Conosci il tuo allenatore, ascolta la sua squadra? È un manager ragionevole? Cerchi di soddisfare le esigenze degli sviluppatori? È comunicativo? Questo è molto importante, il tuo manager ha un ruolo ... porta a termine il lavoro, presenta i risultati. E per questo, qualcuno deve occuparsi del progetto legacy.

• Ha un altro sostituto?
• Ha un altro progetto più attraente per le tue preferenze che ti dà motivazione, forse il 50% del tuo tempo ?.
• Può darti il ​​via libera per ricreare una parte del progetto?

Non lo sai per certo .... quindi, sì, devi parlare con lui. Non in modo impegnativo, no se ti piace il posto di lavoro. Ma devi parlargli del tuo disagio, perché neanche la partenza dei dipendenti è un buon risultato, ... nessuna azienda / manager ottiene benefici per le dimissioni di uno sviluppatore. E non gli chiedi più soldi, o meno ore, o telelavoro, o qualcosa che interferisca con le politiche / risorse dell'azienda. Si tratta di provare a riorganizzare le allocazioni della squadra, è più "fattibile". E non verrai licenziato per avergli fatto sapere di un disagio. Ma l'unico che può aiutarti a risolvere il tuo disagio è lui, se vuoi restare lì ovviamente.

Chiedigli un breve incontro privato .
Rilassati , niente emozioni di rabbia, niente toni esigenti.
Questa è una conversazione con un membro del team che può aiutarti a trovare una soluzione a un disagio.

Anche se non fa nulla per te e non si può fare nulla. Non è nelle tue mani, hai fatto quello che potevi per essere commosso. Perché se non dici niente e trovi un nuovo lavoro, nel momento in cui gli dici, la prima cosa che ti dirà è 'Non sapevo che ora ti sentissi così, potremmo provare a risolverlo' . Quando lasci un'azienda per soldi, chiedi prima un aumento, questo è lo stesso, prima di iniziare a cercare lavoro, lascia loro la possibilità di trovare una soluzione in cui entrambi gli interessi siano soddisfatti . Pensa in modo da ottenere motivazione e allo stesso tempo fornire valore al team / cliente

Ci sono buone probabilità che tu possa trarre vantaggio dall'ascolto della mia storia, quindi eccolo.

Sono stato assunto presso la mia azienda per lavorare a un progetto in particolare (in parte perché ero l'unico ragazzo che hanno intervistato che conosceva tutta l'elettronica, ma alla fine è stato in gran parte irrilevante). Dopo averci lavorato per circa sei mesi, sono giunto alla conclusione che l'architettura fosse una perdita totale nonostante il codice base fosse solo un anno e mezzo vecchio a quel punto. All'epoca pensavo che stavo guardando un codice base di tre anni e l'azienda aveva una storia di cattive pratiche di controllo del codice sorgente. In effetti il ​​loro utilizzo del controllo del codice sorgente era abbastanza ok (è migliorato) e il prodotto è stato realizzato con una produzione big bang.

Ho riferito per analogia che le fondamenta erano incrinate e il terreno era instabile. In effetti era necessaria una riscrittura totale ma in quel momento non poteva essere concessa e lo sapevo. Concordammo per analogia che, se necessario, avrei piantato travi a I attraverso le fondamenta per fungere da piloni. Nel decennio successivo, quando le cose si sono interrotte o sono diventate insostenibili o il profiler ha individuato gli hotspot, ho sostituito quasi tutta l'architettura originale, al punto che ora sono rimaste solo un paio di dozzine di linee. Ma ora le stesse travi a I si sono incrinate e sono state rinforzate e la casa-divenuta-skycraper mostra la sua età e di nuovo diventa difficile da lavorare e temo di insegnare ai nuovi programmatori tutto ciò che è necessario per aggiungere nuove tabelle al database come non va bene gli esempi rimangono. Ogni spiegazione di come funzionano le cose ora è diventata una lezione di storia.

Non lavoro più molto sul prodotto, ma ogni volta che è necessario apportare una modifica che infrange le regole dell'architettura, lo faccio , non perché solo io posso farlo, ma perché conosco essenzialmente tutte le regole nella mia testa e quindi posso scegliere il modo più semplice per mantenerne le conseguenze.

Ma solo ora ho l'esperienza per fare veramente bene e progettare un'architettura che possa essere mantenuta per vent'anni o più. Alcuni dei problemi sono decisioni sbagliate dell'architettura originale in cui ho sostituito l'implementazione con un lavoro quasi simile che conserva molte delle stesse decisioni. Alcuni dei problemi sono le mie decisioni sbagliate. E il settore è cambiato e vogliamo sostituire l'architettura fat-client con un'architettura web. Sai cosa, ora è il momento. Non ho il set completo di competenze per un'architettura web, ma ne ho la maggior parte e so a chi rivolgermi per il resto.

La scelta deve essere tua, ma potresti avere qui il posto per far passare le travi a I attraverso le fondamenta. Se scegli di farlo, imparerai e diventerai forte.

Assicurati di conoscere te stesso prima di fare qualcosa di drastico

Tre anni sono ancora abbastanza piccoli, quindi non farei niente di drastico come cambiare lavoro o carriera finché non ti sarai assicurato di sapere di cosa si tratta sul mantenimento del codice legacy che non ti piace. Ad esempio, è possibile che tu abbia bisogno di imparare un nuovo strumento o tecnica e che tu possa effettivamente imparare ad apprezzare il mantenimento del codice legacy. Se hai un mentore, sarebbe una buona cosa discuterne con loro. Se non hai un mentore, dovresti provare a trovarne uno.

Insoddisfatto = scarso rendimento = successo in carriera = è ora di cambiare

Una volta che sei sicuro di non essere tu, è il lavoro, quindi renditi conto che farai il tuo lavoro migliore solo se sarai felice, o almeno soddisfatto del tuo lavoro. Se sei attivamente infelice o odi il tuo lavoro, si vedrà nel tuo lavoro. Questo danneggerà la tua carriera a lungo termine. Quindi non ti stai facendo alcun favore rimanendo in una situazione che ti rende attivamente infelice (a volte non abbiamo scelta, ma se lo fai, e la maggior parte delle volte lo facciamo, allora devi fare un cambiamento).

Cosa dovresti fare?

Dì al tuo capo le tue preferenze e se il tuo capo non può o non vuole onorarle in un lasso di tempo ragionevole, trova un lavoro che possa e volere. Nota che quasi nessun lavoro (incluso se sei il capo di te stesso) soddisferà le tue preferenze il 100% delle volte; questa è solo la vita. Ma una buona corrispondenza è quella che è accettabile per te e mescola compiti che ti piacciono con alcuni compiti che puoi almeno tollerare. Ma se ti ritrovi a odiare il tuo lavoro, è tempo di cambiare.

Un'ultima cosa

Se lavori per molte ore o nei fine settimana senza pause adeguate, potresti subire un esaurimento, che può far sembrare insopportabile anche i compiti più piacevoli. Quindi parte del fare il punto della tua situazione include assicurarti che il tuo odio per il tuo lavoro provenga davvero dal lavoro e non dallo stress indotto dal burnout. Se il problema si rivela essere il burnout, deve essere affrontato in modo diverso rispetto a se semplicemente non gli piace il tuo lavoro.

Ecco una strategia che potresti utilizzare. Ma fai attenzione, questo potrebbe metterti in una posizione sfavorevole con il tuo manager.

Dì loro che alcuni moduli sono schifosi e devono essere riscritti da zero, non puoi aiutarli con il cerotto. Potrebbe trovare qualcun altro o lasciarti riscrivere. Se riesci a riscrivere, è quasi come un nuovo progetto, dovresti esserne felice.

Ho visto entrambi i lati di questo. Ho riscritto codice scadente che mi richiederebbe più tempo per capire e correggere che riscrivere. E ho visto persone riscrivere codice che pensavo fosse OK e gestibile (e rompere il mio budget).

L'ho affrontato per molto tempo. È diventato qualcosa di insopportabile.

Sfortunatamente, il lavoro consuma la maggior parte del tempo della giornata ed è molto disgustoso svegliarsi pensando di avere a che fare con un sacco di codice difettoso. È una brutta sensazione.

Amo creare e inventare; ecco perché sono diventato un programmatore molto tempo fa. Nemmeno io sono un genio, brillante ma piuttosto creativo.

Ora che hai esperienza, lascia il tuo lavoro e cercane uno che meriti di più la tua devozione. L'ho fatto 2 mesi fa e ora non riesco a capire perché non l'ho fatto prima.

Dopo alcune volte ho scoperto che comincio a "odiare" un codice di base, ho iniziato a cercare il motivo.

E ho scoperto che è perché ha alcuni inconvenienti che mi danno costantemente fastidio e rimangono non risolti. La seccatura sta quindi aumentando e ...

Quindi il modo per eliminare l '"odio" è identificare e correggere le cose che ti preoccupano di quel codice!

Che cos'è cosa più importante, le conosci già (dato che ti danno fastidio) ma non ti importava di dare la priorità.

Ne hai già nominate alcune: "non è facile capire il codice, soprattutto se non c'è documentazione". Durante l'esame del codice, è necessario aver identificato che queste e queste parti sono sciatte e soggette a errori; qui e qui, non ci sono test quindi non c'è modo di sapere se il codice è (ancora) corretto in tutti i casi, ecc.