Non riesco a programmare perché il codice che sto usando usa vecchi stili di codifica. È normale per i programmatori?


29

Ho il mio primo vero lavoro come programmatore, ma non posso risolvere alcun problema a causa dello stile di codifica utilizzato. Il codice qui:

  • Non ha commenti
  • Non ha funzioni (50, 100, 200, 300 o più righe eseguite in sequenza)
  • Usa molte ifaffermazioni con molti percorsi
  • Ha variabili che non hanno senso (es .: cf_cfop, CF_Natop, lnom, r_procod)
  • Utilizza un linguaggio vecchio (Visual FoxPro 8 del 2002), ma ci sono nuove versioni dal 2007.

Mi sento come se fossi tornato al 1970. È normale per un programmatore che abbia familiarità con OOP, clean-code, modelli di progettazione, ecc. Avere problemi con la programmazione in questo modo vecchio stile?

EDIT : tutte le risposte sono molto buone. Per la mia (non) speranza, sembra che ci sia un sacco di questo tipo di base di codice in tutto il mondo. Un punto menzionato a tutte le risposte è il refactoring del codice. Sì, mi piace davvero farlo. Nel mio progetto personale, lo faccio sempre, ma ... Non riesco a riformattare il codice. Ai programmatori è consentito modificare i file solo nell'attività per cui sono progettati.

Ogni modifica al vecchio codice deve essere commentata nel codice (anche con Subversion come controllo della versione), oltre alle meta informazioni (data, programmatore, attività) relative a quella modifica (questo è diventato un disastro, c'è un codice con 3 linee usate e 50 vecchie righe commentate). Sto pensando che non è solo un problema di codice, ma una gestione del problema di sviluppo del software.


43
Sì, certo, è normale. Sei stato addestrato a lavorare in un certo modo e la maggior parte della tua formazione è inutile quando affronti una base di codice che è stata implementata in un modo abbastanza diverso. Detto questo, i principi fondamentali non sono cambiati molto, e dopo lo shock iniziale inizierai ad
adeguarti

12
Non ti stai perdendo molto non usando i commenti. Se qualcosa la gente li abusa.
JohnFx,

22
@JohnFx Non essendo in disaccordo con te, ma avendo affrontato più di poche stronzate legacy senza commenti, direi che preferisco i commenti ridondanti / obsoleti piuttosto che nessun commento.
yannis,

25
Questo sembrerà malvagio - ma sono contento che tu provi questo tipo di dolore all'inizio della tua carriera, poiché sarà una grande motivazione non scrivere codice come quello che stai mantenendo.
Bork Blatt,

19
Una delle abilità più importanti che puoi sviluppare come programmatore è quella di essere in grado di comprendere e riformattare il codice di altre persone. Se non lo padroni, non sarai mai un buon programmatore. Sei fortunato ad aver avuto la possibilità di imparare l'abilità.
Paul Tomblin,

Risposte:


0

Ok, sarò schietto. Questo è un brutto posto in cui lavorare ... Sono stato in tali situazioni, e di solito finisce con te che sei stato inghiottito da questo codice. Dopo circa un anno, ti abituerai e perderai la presa su come le moderne alternative possono essere utilizzate per svolgere lo stesso compito più facilmente, in un modo più mantenibile e anche più veloce in fase di esecuzione in la maggior parte dei casi.

Ho lasciato un posto di lavoro come quello, perché, dopo solo un mese, mi sentivo trascinato in un vecchio codice skool. Ho provato a provarlo, ma ho deciso di non farlo. Non ho potuto usare il codice pulito e ho iniziato a perdere le competenze a causa della mancanza della pratica quotidiana. Ogni approccio moderno ha dovuto essere approvato da 3 livelli di sviluppatori, cosa che non è mai avvenuta, perché l'idea era che le cose potrebbero rompersi quando si usano approcci moderni. E la natura fragile del codice che viene fuori quando non si usano gli approcci moderni è abbastanza spaventosa.

Non fraintendetemi, ci sono casi in cui le persone progettano in modo eccessivo soluzioni e io sono contrario. Ma essere trascinati nelle convenzioni e nello stile di programmazione degli anni '80 per un lungo periodo di tempo fermerà i tuoi progressi e anche, penso, le opportunità di carriera.

Inoltre, devi guadagnare denaro, quindi a volte devi fare ciò che non ti piace esattamente. Tieni d'occhio i sintomi del burnout e trasforma la codifica in un compito banale in quei casi.


1
Come puoi dire che è un brutto posto in cui lavorare? Non c'è nulla di sbagliato nel codice inline legacy. Il codice legacy ha un posto in questo mondo senza codice legacy avremmo nuovi exploit nelle applicazioni che usiamo quotidianamente.
Ramhound,

1
@Ramhound: Perché ho esperienza di prima mano in questi luoghi. Non ti sarà permesso usare container efficaci, non sarai in grado di usare costrutti sicuri, non avrai input in architettura. La paura del cambiamento è la ragione principale. E se rimani in un posto simile per più di un anno, verrai trascinato al suo interno. Il codice moderno rende i tuoi progetti più semplici, veloci e sicuri! Sono abbastanza sicuro che il posto sia pieno di memoria grezza che volteggia, costruzione di query SQL al volo, molto probabilmente nemmeno parametrizzata, e così via.
Coder,

1
Il codice legacy di Ramhound è ok. Scrivere codice legacy oggi non è ok.
Renato Dinhani,

@Coder, questa è stata una descrizione perfetta del lavoro e, come te, ho lasciato il lavoro dopo un mese e alcuni giorni. La cosa migliore che ho fatto e ora, nel mio tempo libero, sto imparando molte cose utili.
Renato Dinhani,

Aggiornamento dopo 6 anni: ho lasciato quell'azienda pochi giorni dopo aver postato questa domanda e guardando indietro, è stata la decisione migliore che ho preso. Ho avuto l'opportunità di lavorare in molti altri progetti in altre aziende e nessuno di loro aveva le stesse cattive pratiche o la mancanza di qualità che ho trovato in quel primo lavoro. Stare a casa imparando lo stato attuale del mercato del lavoro mi ha permesso di lavorare in progetti più interessanti e aziende migliori.
Renato Dinhani,

35

Questo stile di codifica (se vuoi persino chiamarlo qualsiasi tipo di stile) è un cattivo stile di codifica.

Si possono scrivere brevi funzioni con nomi di variabili descrittivi e controllo del flusso sano nella maggior parte dei linguaggi moderni (Visual FoxPro è moderno, sì).

I problemi che stai riscontrando riguardano una cattiva base di codice, niente di più, niente di meno.

Tali basi di codice esistono e sono molte: il fatto che tu abbia problemi con esse attesta quanto possano essere cattivi (e che tu abbia una buona formazione).

Quello che puoi provare e fare è migliorare le cose in cui puoi - rinominare le variabili, estrarre i punti in comune e dividere le funzioni di grandi dimensioni in quelle più piccole ecc ... Ottieni una copia di Lavorare in modo efficace con il codice legacy ...

Sono su un progetto C # con una pessima struttura, non a miglia di distanza da ciò che descrivi. Ho appena combinato 12 funzioni separate (ovvio copia-incolla) in una che accetta un singolo parametro.


33
I bravi programmatori possono gestire qualsiasi tipo di storia dell'orrore. Non sarà divertente, ma è per questo che ti pagano i soldi per farlo. Il lavoro non dovrebbe essere divertente e giochi.
tp1

9
@ tp1 - Sì, ma devi ammettere che la prima base di codice che incontri può essere un vero shock per il sistema.
Oded,

10
@Renato: tutti i programmatori lavorano per mantenere il codice molto più che per scrivere / progettare nuovo codice. E tutto il codice che viene costantemente modificato peggiora nel tempo a meno che non si spenda molto sforzo per prevenirlo. I bravi programmatori sono anche più bravi a gestire basi di codici errate, che lo facciano o meno, quindi i manager spesso assegnano loro tali compiti e pochi sono in grado di evitarli completamente. Direi davvero che un programmatore non può pretendere di essere veramente bravo a meno che non abbia una certa esperienza con il codice cattivo (che potrebbe anche essere il suo).
Michael Borgwardt,

13
@ RenatoDinhaniConceição, non prenderei mai in considerazione l'assunzione di uno sviluppatore per realizzare progetti originali che non si sono occupati della manutenzione, NON PUOI essere un bravo designer senza questa esperienza (non farlo è una delle principali cause di cattivi progetti in la mia esperienza). Non puoi essere un buon programmatore ed essere cattivo nella manutenzione. Potrebbe non piacerti, ma è necessario capire come progettare bene. E la capacità di svolgere un duro lavoro di perseveranza è anche una caratteristica di un buon programmatore. Se fosse facile non avrebbero bisogno di noi.
HLGEM,

8
@ tp1 Il lavoro dovrebbe essere divertente e giochi, altrimenti stai sbagliando.
Kevin McCormick,

18

Non è davvero "vecchio stile", tranne nel fatto che le (attuali) buone pratiche di progettazione non erano sempre così popolari. Questo è solo un brutto codice. Il codice errato rallenta chiunque. Alla fine ti abitui, ma è solo perché ti abitui a stranezze specifiche nel tuo sistema specifico. Dato un nuovo progetto, potresti trovare modi completamente nuovi di scrivere codice errato. La cosa buona è che sai già come identificare questi odori di codice.

La cosa più grande che puoi fare è non propagare il problema . Non prendere queste cattive pratiche come una convenzione a meno che non lo sia la tua squadra. Mantieni pulito il nuovo codice in modo da non forzare un refactor. Se è così male e hai tempo, prendi in considerazione un importante fattore di riflessione ... ma in pratica raramente hai quel lusso.

Prendi in considerazione l'aggiunta di commenti mentre capisci le cose e cambia piccoli pezzi come pratici. A meno che tu non stia programmando da solo, devi risolverlo con la tua squadra; se non ci sono convenzioni, dovresti prenderti un po 'di tempo per elaborarle e magari impegnarti a migliorare lentamente la base di codice se la mantieni regolarmente.

Se trovi una funzione totalmente isolata con nomi di variabili errati e la stai risolvendo comunque, potresti anche rendere i nomi delle variabili qualcosa di utile, rifattorizzare gli if. Non apportare modifiche alle funzionalità comuni a meno che non si effettui il refactoring di gran parte di esso.


4
"le buone pratiche di progettazione non erano sempre così popolari" Non si tratta necessariamente di popolarità. Ciò che è considerato un buon design o la migliore pratica si evolve nel tempo. È qualcosa da tenere a mente quando si guarda il vecchio codice.
Burhan Ali,

@BurhanAli, abosiolutamente, quella che era una buona pratica nel 2000 quando la nostra applicazione era stata progettata originariamente non è necessariamente una buona pratica ora. Gli sviluppatori più giovani spesso non hanno idea che ciò che è stato loro insegnato come best practice potrebbe non esistere nel momento in cui il codice è stato scritto o potrebbe non funzionare con la lingua precedente utilizzata dal software.
HLGEM,

2
Non penso che le funzioni a 500 righe siano mai state considerate "buone" ... il libro principale che ho imparato a assemblare negli anni '80 diceva che forse avresti dovuto spezzare le cose in subroutine quando hanno iniziato a diventare troppo grandi per ramificarsi dalla fine all'inizio. Questo arriva da qualche parte tra 40-120 linee su quel processore (6502).
mjfgates,

11
  • non hai commenti: correggilo mentre lo impari
  • non hanno funzioni (50, 100, 200, 300 o più righe eseguite in sequenza)

Ciò probabilmente risale a una precedente iterazione del codice. A questo punto, farei attenzione alle sottili differenze tra blocchi di codice apparentemente simili che sono diventati "caratteristiche". Ma indipendentemente da quanto sia brutta l'idea di questo tipo di struttura, è abbastanza semplice da capire ... quindi non sono sicuro di dove avresti problemi con esso.

  • usa molte istruzioni if ​​con molti percorsi - in realtà non sono sicuro di cosa intendi qui
  • ha variabili che non hanno senso (es .: cf_cfop, CF_Natop, lnom, r_procod) -

Vorrei sottolineare la cautela con il bit "rinomina variabili". C'è una buona probabilità che semplicemente non capisca ancora il gergo e i nomi delle variabili avranno molto più senso dopo che ci sei stato per un po '. Per non dire che non possono esserci anche nomi variabili problematici, ma i tuoi esempi sembrano avere una logica per loro, se sapessi quali sono gli acronimi comuni sul tuo sito. Questo ovviamente non è così importante se sei una squadra di 1.

  • usa un linguaggio con cui non ho familiarità (Visual FoxPro 8 del 2002) - Questo è il tuo problema, non il codice

7
+1: Questo è il tuo problema, non il codice :)
aleroot

Il suo ultimo punto era grammaticalmente errato; Non riuscivo a capire il suo significato originale. Ho indovinato, e potrei aver indovinato, quindi potrebbe non aver significato che non aveva familiarità con Visual FoxPro.
Myrddin Emrys il

A proposito di FoxPro, la mia domanda è stata modificata. Ho detto che è un linguaggio prolisso e per me questo non va bene, ma è un'opinione personale. Lo capisco, ma non mi piace, e il punto principale è l'età del linguaggio. Non è stato aggiornato nella mia azienda, ma ci sono nuove versioni (Visual FoxPro 9 dal 2007).
Renato Dinhani,

3
@ RenatoDinhaniConceição, è comune non aggiornare un prodotto di database poiché gli aggiornamenti rompono le cose che attualmente funzionano e non c'è tempo o denaro da spendere per apportare modifiche che non sono necessarie se si mantiene la versione precedente. Questa è una scelta aziendale.
HLGEM,

1
@renato, la maggior parte delle applicazioni di database non sono facilmente compatibili con le versioni precedenti.
HLGEM,

11

Mi sembra un'opportunità .

È chiaro che puoi già vedere molti problemi nel modo in cui le cose vengono fatte e gestite. Puoi lamentarti del fatto che è tutta spazzatura e che non puoi fare nulla, oppure puoi usarla come un'occasione d'oro per mostrare davvero al tuo datore di lavoro il tuo valore.

Ora, non ti aiuterà se ti avvicini al tuo datore di lavoro e gli dici che tutto deve cambiare. Quindi il trucco è giocare per un po ', porre MOLTE domande e quando ti viene richiesto di scrivere codice dovrai giocare secondo le loro regole con tutti i commenti ecc., Poiché dovrai tenere altri sviluppatori informato utilizzando il sistema che preferiscono attualmente, mentre allo stesso tempo puoi introdurre sensibili rifatturazioni che non ti rischiano nulla. È possibile estrarre un paio di metodi e, se la tua lingua lo supporta, introdurre alcuni test unitari. Quando ti viene chiesto perché l'hai fatto in questo modo, o se ti viene detto che stai facendo qualcosa di "sbagliato", evita di diventare difensivo o polemico mentre fai una presentazione sonora della tua posizione per il tuo stile di programmazione preferito. Per esempio, puoi fare riferimento a libri come il Clean Code di Bob Martin oppure puoi fare riferimento ad altri libri, articoli o persino a domande e risposte che hai riscontrato su Programmers.SE. Tutto ciò che puoi trovare utile per supportare la tua posizione con fatti che potrebbero essere al di là della tua esperienza agli occhi delle persone con cui stai lavorando.

Per quanto riguarda l'eccessivo commento, alcuni di questi possono essere chiariti se si aggiungessero alcuni nomi descrittivi per le variabili e i metodi, ma si potrebbe anche essere in grado di fare un caso per un buon sistema di controllo della versione, e usando quello per tenere traccia delle modifiche, delle date, ecc. e per l'uso di uno strumento per confrontare le diverse versioni dei file sorgente se non si è già in possesso del VCS scelto.

Come ho detto, questa è un'opportunità per contribuire al miglioramento di un team di sviluppo che suona come se si fosse perso per così dire. Hai l'opportunità di distinguerti come esperto e competente e come qualcuno che può dare l'esempio. Queste sono tutte cose buone che ti aiuteranno in seguito man mano che la tua carriera avanza.


2
Innanzitutto, tutte le risposte qui sono buone e mi hanno aiutato. Questa risposta non è stata votata né commentata, ma mi piace molto. Penso che il punto di porre molte domande e di non andare sulla difensiva sia molto importante. Ho parlato con il mio capo di alcuni punti che ho citato qui e, come previsto, non ho il potere di fare grandi cambiamenti, ma sento che un po 'verrà cambiato in meglio dopo. Grazie, S. Robbins e gli altri per le parole sagge.
Renato Dinhani,

1
Bene, l'ho fatto una volta e ci sono riuscito. È estenuante. Non lo farò mai più. Questo è davvero difficile: non puoi lasciarti andare PRIMA del refactoring, il codice è debole, quindi è probabile che esploda sul tuo viso in qualsiasi momento e dovrai affrontare una resistenza molto importante a causa degli habbit di lavoro delle persone (tra gli altri problemi). So di lavorare solo per le persone a cui interessa la qualità del codice.
deadalnix,

1
@deadalnix I primi lavori raramente offrono l'opportunità di scegliere le persone con cui lavori. Spesso non saprai quante persone si preoccupano davvero della qualità del codice fino a quando non lavori con loro per un po '. La mia risposta aiuta l'OP a capirlo. La tua dichiarazione sull'incapacità di test unitario prima del refactoring è palesemente errata. Cercare di refactorizzare prima dei test unitari aumenta il rischio complessivo. Inseguire i bug senza test è inefficiente ed estenuante. Le persone che si preoccupano della qualità del codice si concentrano fortemente su test e tecniche di codifica pulite. Non capisco la tua obiezione implicita, felice di parlare di questo offline :-)
S.Robins,

@ S.Robins L'inseguimento del bug senza test è inefficiente ed estenuante e il refactoring senza unittest è molto rischioso (ed entrambi si combinano bene). Questo è esattamente il motivo per cui una simile situazione è un incubo. La base di codice legacy massiccia non è di solito irremovibile (piena di stati globali, dipendenze hardcoded dal sistema di produzione o da altri sistemi, nessuna separazione di preoccupazioni, ripetizione del codice di massa, ecc.). Dovrai lanciare un primo passaggio di refactoring per rendere il codice non leggibile. Penso che entrambi siamo d'accordo sull'aspetto della codifica del problema, ma ci siamo fraintesi.
deadalnix,

1
È anche un'opportunità per raccogliere contenuti per thedailywtf.com
Arkh,

8

Benvenuto nella giungla !

Sfortunatamente, spesso iniziare a lavorare in un'azienda significa affrontare questo tipo di situazioni, a meno che tu non lavori per un'azienda strutturata e ben organizzata, queste situazioni sono abbastanza comuni ...

Il mio consiglio è:

  1. Inizia a studiare e familiarizza con: linguaggio di programmazione utilizzato (Clipper / dBase) e ambiente (Visual FoxPro)

  2. Leggi e analizza la base di codice e inizia a commentarla

  3. organizzazione / refactoring del codice (risolvendo il problema di troppe righe eseguite in sequenza)

Avere problemi ad affrontare una base di codice simile è normale, ma può diventare una grande sfida cercando di migliorare la qualità del codice e dare "il tuo tocco" al programma migliorando la base di codice e forse rendendolo un programma migliore ...


7

Per rispondere alla tua domanda: Sì, persone / aziende di tutto il mondo utilizzano l'infrastruttura che può essere costruita su un codice scadente. Quando ti integri in tali situazioni, può essere molto difficile da affrontare.

L'estate scorsa ho lavorato come stagista sviluppando un'applicazione che il team addetto al controllo qualità avrebbe utilizzato in un reparto specifico. Il team addetto al controllo qualità ha utilizzato molti script autonomi (VBScript, Perl, Bash) per eseguire test su database e simili e ha voluto riunirli tutti in un'unica applicazione. Il problema con questo, tuttavia, è che quegli script sono stati usati altrove nell'azienda (quindi non è stato possibile modificare la funzionalità principale / i nomi delle variabili) e il codice è stato "aggiunto" per quasi 10 anni; molta merda si era accumulata.

Ecco cosa puoi fare al riguardo, però:

  1. Chiedi aiuto: i tuoi colleghi colleghi che hanno dovuto esaminare questo codice probabilmente conoscono le sue idiosincrasie. Ciò che è ottuso e confuso per te va benissimo per loro. Quindi chiedi aiuto!
  2. Rifattore quando possibile: se si deve consultare / mantenere questo codice per un lungo periodo di tempo, rifattorizzarlo ogni volta che è possibile. Anche se stai eseguendo una ricerca e una sostituzione con un nome di variabile, ogni piccolo aiuto aiuta. La società che ho internato per l'estate scorsa aveva un problema simile nell'usare nomi di variabili scadenti. Ogni volta che ho potuto ho fatto scorrere il loro codice attraverso un pettine a denti fini, cambiando i nomi delle variabili, ottimizzando la logica (raggruppando varie funzioni in 1, ad esempio), ecc. Fai lo stesso ogni volta che ne hai l'opportunità!

Come sempre, purché le funzionalità esterne del codice funzionino correttamente, non importa come funzionano gli interni.


+1 per "chiedi aiuto". Lavorare in gruppo aggiunge costi ma porta anche benefici.

7

Farò alcuni commenti che sono diversi da molti dei rispondenti qui. Molti dei miei commenti possono essere ovvi per te, ma è comunque necessario che tu lo dica.

  • Fai attenzione a modificare il codice che non capisci, fino a quando non lo capisci.
  • Se lavori in un ambiente di squadra, con il codice su cui lavorano i tuoi compagni di squadra, discuti delle modifiche con loro prima di apportare le modifiche. A nessuno piace un "sicario solitario" che entra e cambia codice con cui tutti gli altri hanno familiarità. Questo non vuol dire che i tuoi cambiamenti non sono garantiti o la cosa "giusta" da fare.
  • Ottieni l'adozione per le tue idee. Porta tutti a bordo con le tue idee, quindi puoi usare le abilità del tuo team per fare il refactoring, invece di caricarti di tutto il carico di lavoro.
  • Ottieni buy-in di gestione. Potrebbero essere in grado di allocare fondi per farti andare e ricodificare il codice.
  • Parla con il management in termini di comprensione dei vantaggi del re-factoring della propria base di codice. Codice più gestibile significa meno tempo dedicato alla risoluzione dei bug, all'aggiunta di funzionalità ecc. Ciò significa uno sviluppo economico. Tempi di risposta più rapidi ecc.

È facile aggiungere suggerimenti di codifica e best practice puri senza comprendere la politica del tuo ambiente. Le persone con cui lavori potrebbero non voler cambiare o dedicare il tempo a cambiare la tua base di codice, ma prova a vendere l'idea a tutti prima di saltare e cambiare tutto (che ha rischi intrinseci in sé e per sé)

Spero che sia di aiuto.


1
Inoltre: prova, esegui backup, usa il controllo versione. Se sei nuovo, ci sono cose che stanno succedendo nella fonte che semplicemente non capirai e ciò che sembra un cambiamento innocuo può causare problemi che non prevedi.
Scott C Wilson,

Aggiungerei ulteriormente. Non modificare nulla fino a quando non hai un test fallito che richiede un'azione . Inizia a scrivere test. Quando hai un test fallito, assicurati che sia importante. Quindi hai un forte mandato da cambiare. Anche in questo caso, attendere che il sistema sia saturo di test. Cerca sempre di lasciare il sistema buono o migliore (mai peggio) di quello che hai trovato.
emory

5

Una delle cose che sporge è il tuo commento modificato

Ogni modifica al vecchio codice deve essere commentata nel codice, oltre a meta informazioni (data, programmatore, attività) relative a quella modifica (questo è diventato un disastro, ci sono codici con 3 righe utilizzate e 50 vecchie righe commentate). Sto pensando che non è solo un problema di codice, ma una gestione del problema di sviluppo del software.

Ho anche un progetto in cui ho ereditato una base di codice FoxPro legacy con molti dei problemi che descrivi. Una delle prime cose che ho introdotto al progetto è stato un buon repository di codice sorgente. FoxPro può integrarsi con SourceSafe, ma quel prodotto è doloroso da usare.

Ho preso una copia dello strumento scx di Paul McNett http://paulmcnett.com/scX.php e l'ho integrato nel mio ciclo di sviluppo. Fa un ottimo lavoro nell'estrarre il codice binario FoxPro in un formato di testo che può quindi essere inserito in un repository di origine, come Subversion, Mercurial o persino git. (È possibile trovare utile il progetto SubFox su http://vfpx.codeplex.com .

Questi strumenti forniscono la cronologia e consentono ai programmatori di andare avanti con il compito di mantenere il codice. Ci vuole sicuramente del tempo per imparare a usare questi strumenti, ma poiché sono tutti gratuiti, non ha davvero senso non investire un po 'di tempo in essi. (anche se non riesci a far muovere i progetti Job in quel modo).


4

Concordo fortemente con la risposta di funkymushroom. Se sei un ambiente di squadra, assicurati che gli altri sappiano che stai refattore o riorganizzando il codice, se hai mai intenzione di ottenere buoni incarichi futuri.

Per esperienza personale lo so, sebbene non sia il tuo stile di codifica, se stai mantenendo il codice, che anche altri modificano e mantengono, rimani nello stile del codice esistente. L'aggiunta di commenti e chiarimenti va bene, ma il layout e le convenzioni di base dovrebbero rimanere. I vecchi guru / pistole del progetto si aspettano che il codice sia simile a quello che vedono da anni.

Quando un cliente urla di un bug, la tua direzione andrà alle vecchie pistole per risolvere il problema il più rapidamente possibile. Se queste vecchie pistole, quando sono sotto pressione, ti trovano "ripulito il codice" e quindi ora devono passare il tempo a capire dove hai spostato o rinominato quella variabile che conoscono ha bisogno di essere modificata, il tuo nome nella società verrà cambiato in " fango".

Una volta che la crisi è finita, prima la vecchia pistola ti incolperà lentamente l'aggiornamento critico. Successivamente troverai che manterrai il codice pulito fino a quando sarai in azienda. Alla fine, quando saranno disponibili nuovi progetti interessanti, i tuoi manager chiederanno ai guru su chi dovrebbe lavorare il progetto, e se li hai fregati una volta, non riuscirai mai a raggiungere il nuovo progetto, fino a quando il tuo foraggio non verrà buttato via alla fine per rispettare una scadenza.

Se hai imparato al college il modo "giusto" di codificare e ora sei nella forza lavoro, dimentica quel modo "giusto". Questi non sono incarichi universitari, questi progetti non durano solo un semestre, possono vivere per anni e dovranno essere mantenuti da un gruppo di persone con diversi livelli di competenza e diversi livelli di interesse nell'ultima tendenza CS. Devi essere un giocatore di squadra.

Puoi essere la più grande programmazione hot shot a scuola, ma sul posto di lavoro, il tuo primo lavoro, sei un principiante con zero crediti di strada. Le persone che hanno programmato per anni non danno un grido alla tua scuola o ai tuoi voti, è quanto giochi bene con gli altri e quante interruzioni porti nella loro vita.

Nei miei 20 anni, mi sembra che siano stati licenziati più programmatori di assi, principalmente perché chiedono di fare le cose nel modo "giusto". A meno che tu non porti qualcosa di molto, molto, molto unico nel tuo lavoro, sei sostituibile. Potresti essere stato il migliore della tua classe, ma l'anno prossimo qualcun altro sarà il migliore della sua classe e cercherà un lavoro.

Lo guardo come il tuo lavoro principale, è quello di mantenere il tuo lavoro, fino a quando decidi di cambiare lavoro. Per mantenere il tuo lavoro significa che devi giocare bene nel parco giochi che qualcun altro ha costruito e pagato.

So di sembrare negativo, ma c'è sempre speranza. Man mano che acquisisci esperienza, ottieni successo, acquisirai influenza e sarai in grado di spostare le cose in un modo migliore. Quando si scrive un nuovo codice o su un nuovo progetto, premere per le modifiche desiderate. Se si tratta di un nuovo codice, le vecchie pistole non si aspettano che sia il modo in cui lo hanno lasciato e quando vedono i vantaggi potrebbero imparare e adattare il nuovo modo.

Il vecchio sistema può cambiare, ma richiede tempo. Cambiare qualcosa introduce rischio e rischio di odio per le aziende e devi prenderti tempo e lavoro per rendere la compagnia a proprio agio con il cambiamento.

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.