Le mie esperienze di tirocinio negativo sono rappresentative del mondo reale? [chiuso]

Sono curioso di sapere se le mie attuali esperienze come stagista sono rappresentative del settore reale.

Come sfondo, sto attraversando la parte migliore di due major informatiche e una laurea in matematica in una grande università; Ho frequentato tutte le classi e le ho adorate tutte, quindi mi piacerebbe pensare che non sono terribile nella programmazione. Ho svolto uno stage presso una delle maggiori società di software e, a metà strada, ora sono rimasto scioccato dalla straordinaria qualità del codice. I commenti non esistono, è tutto un codice spaghetti e tutto ciò che potrebbe essere sbagliato è anche peggio. Ho fatto un sacco di tutoraggio / TAing, quindi sono molto abituato a leggere codici errati, ma i principali prodotti del settore che ho visto briscola. Lavoro 10-12 ore al giorno e non ho mai la sensazione di arrivare da nessuna parte, perché " s infinite ore di tentativi di scoprire un'API non documentata o determinare il comportamento di qualche altra parte del prodotto (completamente non documentato). Finora ho lasciato il lavoro odiando il lavoro e desidero disperatamente sapere se questo è ciò che è in serbo per il resto della mia vita.

Ho disegnato una breve scia di tirocini (gli assurdamente grandi stipendi implicano che non è una posizione di bassa qualità), o è questo il mondo reale?

Lo chiamano Real World ™ per un motivo.

Il 99% di ciò che incontrerai nel mondo reale delle aziende sarà considerato una merda, e per una buona ragione che spiegherò. L'1% che non è considerato merda alla fine diventerà una merda.

# 1 Scrivi codice, # 2 ????, # 3 Profitto!

Prima di tutto le imprese esistono per realizzare un profitto, non esistono per generare montagne di codice accademico perfettamente progettato e incontaminato, teoricamente pulito, ospitato in depositi d'oro di perfezione. Nemmeno vicino, nemmeno quelli nel settore della vendita del codice sorgente che producono.

Nel mondo degli affari il codice è un mezzo per raggiungere un fine . Se alcuni codici risolvono un problema aziendale e fanno più soldi di quanti ne siano necessari per creare e mantenere, allora è desiderabile per l'azienda. Impiegarti a scrivere codice è solo un modo per l'azienda di ottenere codice.

Teoria 0 - Pratica ∞

Idealmente la manutenzione dovrebbe essere più un problema, ma di solito non lo è, perché a breve termine non vince finanziariamente. A lungo termine, il software di solito ha un ciclo di vita relativamente breve, in particolare le applicazioni basate sul Web, diventano rapidamente obsolete e riscritte più spesso.

Le applicazioni aziendali sono quelle che sfornano come quelli che vengono percepiti come infiniti progetti di zombi a causa di molte ragioni basate sullo slancio. Questi progetti sono in realtà successi che continuano perché continuano a fare profitto per l'azienda.

In teoria non c'è differenza tra teoria e pratica. In pratica c'è. - Yogi Berra

In teoria, basi di codice perfettamente pulite e perfettamente pulite con coperture di codice al 100% dovrebbero far risparmiare denaro alle aziende, in pratica non si avvicina nemmeno alla consegna di qualcosa che si avvicini a un ritorno sull'investimento valido.

Fisica del ciclo di vita del software

C'è anche una forza di entropia super potente all'opera nel mondo del software. È un buco nero di inevitabilità che condanna tutti i software a degenerare in una grande palla di fango .

Più si parte da un BBM , meglio è, ma ogni sistema software alla fine ci arriverà con abbastanza tempo. La rapidità con cui ti avvicini al 100% di entropia è determinata da dove inizi e da quanto tempo accumuli debito tecnico e quanto è alto l'interesse su di esso.

I sistemi software degenerano e marciscono a causa della manutenzione, non a causa della mancanza di esso. Un sistema che esiste da anni senza modifiche al codice per definizione soddisfa tutti i suoi requisiti e obiettivi ed è un successo.

Sono i sistemi che richiedono un cambiamento costante perché sono partiti più vicini alla massima entropia, sono quelli che vengono costantemente stimolati e stimolati ed è la manutenzione che accelera il cambiamento negativo.

Abbastanza buono è abbastanza buono

I sistemi a ciclo di vita breve come i siti Web che cambiano costantemente non traggono vantaggio dalla costosa enorme progettazione anticipata con una copertura del codice del 100% nei test unitari, poiché i tempi di ammortamento sono troppo brevi per ricoprire i costi.

I sistemi a ciclo di vita lungo come la suddetta linea interna di app aziendali, non beneficiano in realtà di ingenti investimenti di test unitari di copertura del codice al 100%, poiché il tasso di cambiamento nel corso della vita del progetto si avvicina a una costante che è quasi zero in un moda non lineare.

Questo è il motivo per cui i piani di fine vita sono più importanti e i sistemi di sostituzione dovrebbero essere pianificati proprio nel momento in cui qualcosa viene rilasciato, non quando lo ha superato per alcuni anni e insopportabile, quindi un nuovo sistema deve essere messo in atto.

Per quanto ne so, non insegnano la BBM, non ho mai incontrato un neolaureato CS che sapesse di cosa si trattasse, tanto meno perché accada.

Ecco perché Good Enough è Good Enough , niente di più o di meno non lo è.

Slumlords del software

Ci sono signori dei bassifondi immobiliari per un motivo, fanno profitti sugli edifici fatiscenti che possiedono. Il guadagno è maggiore di quello che spendono per la manutenzione incrementale della proprietà fatiscente. In caso contrario, demolirebbero l'edificio e lo rimpiazzerebbero. Ma non lo fanno, perché i costi incrementali sono molto inferiori alla revisione o alla sostituzione dell'intero edificio. Ci sono anche clienti (inquilini) che sono disposti a pagare per la proprietà in rovina.

Nessun proprietario di un edificio, signore dei bassifondi o no spenderanno denaro in una proprietà solo a causa di una nozione accademica di perfezione che non si traduce in un profitto sostanziale rispetto al costo associato.

Nessun cliente pagherà per gli aggiornamenti di un sistema software che funziona in modo accettabile per loro. Nessuna impresa spenderà denaro semplicemente scrivendo e riscrivendo il codice per nessun profitto sostanziale tangibile.

Microsoft è lo slumlord software più dominante e di successo che ci sia. Windows non ha iniziato a ricevere importanti riscritture di base fino a poco tempo fa. E non hanno ancora eliminato tutto il codice legacy dal kernel. Non ha senso per loro, le persone sono più che disposte ad accettare il basso livello di aspettative che hanno fissato nell'ultimo decennio.

Prognosi

Questo è stato un modello per oltre 20 anni in cui sono stato nello sviluppo di software. Non cambierà presto. Questo non è il modo in cui le persone vogliono che esca da qualche sistema di credenze, è una realtà di forze esterne in un'azienda. Le imprese guidano il processo decisionale, i profitti non sono malvagi, pagano il tuo stipendio, la visione a breve o lungo termine è irrilevante, questo è un settore a breve termine di costante cambiamento per definizione. Chiunque si opponga abbastanza bene per realizzare un profitto non capisce gli affari.

Ho trascorso 15 anni a consultarmi e ho imparato molto rapidamente che era abbastanza buono , qualsiasi altra cosa mi stava costando soldi. Sì, volevo che le cose fossero perfette, ma a meno che tu non stia vendendo una base di codice, che nel 99,99999% delle volte stai vendendo una soluzione , tutto quel prefetto codice pulito organizzato elegante è perso e hai solo perso il tuo tempo per cui non verrai mai rimborsato .

Progresso e speranza

Le metodologie agili sono un buon passo nella giusta direzione, almeno filosoficamente. Si rivolgono al caos e al costante cambiamento come cittadini di prima classe e lo accettano. Rifiutano le pratiche dogmatiche, riconoscendo che le metodologie e le pratiche dovrebbero cambiare, nonché i requisiti e le tecnologie.

Accettano l'entropia che viene introdotta dalla mancanza di tempo o dal cambiamento dei requisiti, dal cambiamento del personale e dalla vivacità di un sistema software con il concetto di debito tecnico.

Ma Agile non è una panacea, non cambierà le leggi fondamentali della fisica e le basi di codice marciranno a prescindere. Spetta al management pianificare la gestione del marciume prima che diventi completamente fuori mano e non gestibile.

Agile se fatto correttamente, aiuta a gestire l'entropia, rallentandola, rintracciarla, misurarla e affrontarla in modo pianificato. Non lo fermerà!

Decisione di carriera

Se questo è un vero problema filosofico per te, dovresti probabilmente considerare altre scelte di carriera, perché il modo in cui le cose funzionano ha un valido merito commerciale dietro di esso. I progetti Open Source non hanno precedenti migliori, e in molti casi il codice è persino peggiore della maggior parte del codice aziendale che ho visto.

Sono curioso di sapere se le mie attuali esperienze come stagista sono rappresentative del settore reale.

No non lo è. È rappresentativo del tuo livello di carriera ed esperienza. Fa tutto parte dell'apprendimento di come le aziende lavorano dal punto di vista del controllo di qualità interno.

Come sfondo, sto attraversando la parte migliore di due major di informatica e una di matematica in una grande università; Ho frequentato tutte le classi e le ho adorate tutte, quindi mi piacerebbe pensare che non sono terribile nella programmazione. Ho svolto uno stage presso una delle maggiori società di software e, a metà strada, ora sono rimasto scioccato dalla straordinaria qualità del codice.

Le tue capacità, la tua esperienza, la tua istruzione non hanno alcun impatto sulla qualità del lavoro svolto da altri. Semplicemente perché non hai l'autorità per modificare tali pratiche. Non importa se sei stato buono o cattivo all'università. Ciò non cambia il modo in cui l'azienda per cui lavori attualmente. Quindi, mentre è fantastico, hai tutto questo background. È davvero a tuo vantaggio e non loro. Ecco perché è importante studiare ciò che ami.

Ho svolto uno stage presso una delle maggiori società di software e, a metà strada, ora sono rimasto scioccato dalla straordinaria qualità del codice. I commenti non esistono, è tutto un codice spaghetti e tutto ciò che potrebbe essere sbagliato è anche peggio. Ho fatto un sacco di tutoraggio / TAing, quindi sono molto abituato a leggere codici errati, ma i principali prodotti del settore che ho visto briscola.

Ciò che ho imparato nei miei molti anni di programmazione è che esiste una differenza tra "qualità del codice" e "codice accettabile". La verità è che o qualcuno con autorità trova il codice sorgente in condizioni accettabili o lo trova inaccettabile ma necessario. Sarebbe bello se tutti potessimo ripulire i progetti in cui siamo coinvolti. Spesso non è nell'interesse o nel budget delle imprese allocare risorse per svolgere tale lavoro. Argomenti logici possono essere fatti fino al sorgere del sole il giorno successivo perché questo sarebbe una buona cosa da risolvere, ma quando la direzione ha deciso che lo stato attuale è "accettabile", allora si può fare ben poco. Tutto è direttamente correlato a chi gestisce le cose. O apprezzano la buona qualità interna o no. Lo apprezzi chiaramente e quindi questo stato attuale ti disturba.

Troverai esempi di questo tipo di problema in qualsiasi settore che dipende dal controllo interno della qualità. Dallo sviluppo del software alla produzione. Devi imparare a vedere questo non come un problema, ma semplicemente come l'attuale condizione del loro codice sorgente. Ecco com'è, ci vogliono X numero di minuti per trovare qualcosa, ci vogliono X numero di minuti per sistemare qualcosa.

Al business non interessa questo tempo extra o lo trova accettabile.

Lavoro 10-12 ore al giorno e non ho mai la sensazione di arrivare da nessuna parte, perché sono infinite le ore in cui provo a capire un'API non documentata o a determinare il comportamento di qualche altra parte del prodotto (completamente non documentato). Finora ho lasciato il lavoro odiando il lavoro e desidero disperatamente sapere se questo è ciò che è in serbo per il resto della mia vita.

Perché era accettabile che tu dedicassi lunghe ore all'università per studiare una materia, ma ora non è accettabile impiegare lunghe ore per studiare il codice sorgente? Sono sicuro che il motivo per cui il datore di lavoro ti ha assunto era perché pensavano che tu potessi gestirlo.

Lascia che ti dia un consiglio. I bravi sviluppatori sanno quando chiedere aiuto ai loro compagni di squadra. Non pensare che le risposte siano sempre nel codice. Mi sono risparmiato ore di tempo semplicemente facendo alla gente alcune domande. Sembra che tu abbia bisogno di aiuto per arrivare a tutta velocità.

In secondo luogo, non conosciamo le condizioni di lavoro. Lavorare per lunghe ore è un dato di fatto in così tante industrie. Che devi risolvere da solo, ma posso dirtelo. Odiare il tuo lavoro non è mai un buon segno. Dovresti affrontare quella sensazione e arrivare alla radice di essa. Mi dispiace che tu abbia trovato questa esperienza negativa.

Ho disegnato una breve scia di tirocini (gli assurdamente grandi stipendi implicano che non è una posizione di bassa qualità), o è questo il mondo reale?

Andavi molto bene a scuola, ma ora hai uno stage e non stai andando molto bene. Sembra che tu sia già nel mondo reale. Fa parte della vita. La domanda è: che cosa hai intenzione di fare al riguardo? Che amico mio, è l'unica cosa che conta. Non possiamo dirti cosa fare. Devi prendere una decisione.

Posso dirti che sembra che la tua esperienza alla tua età sia stata di gran lunga migliore di tutte le opportunità che ho avuto. La vita per me negli anni '90 è stata una lotta per pagare l'affitto e trovare il mio prossimo contratto. Considerati fortunato.

Dopo 25 anni e una varietà di aziende e settori posso dire:
Sì, è abbastanza comune.
Questo è il motivo per cui gli ingegneri sono pagati abbastanza bene di solito, devono essere bravi a imbattersi in disordinati hodge-podge e essere ancora in grado di apportare modifiche resistendo al desiderio pressante di riformattare l'intera dannata cosa e scoprire che diavolo dovrebbe davvero essere facendo. Ho provato l'emozione per te lì - è normale sentirsi così per il codice che incontri!

Il codice che vedi sarà spesso passato attraverso interminabili iterazioni da diversi programmatori con approcci e standard diversi e convenzioni di denominazione diverse, ecc. Ecc.

Quello che succede è che la pressione di $ è sempre attiva. È sempre allettante descrivere come e perché un codice migliore è l'unico modo a lungo termine, ma in molti lavori l'orologio sta cercando una soluzione a breve termine. Solo 1 ingegnere impiega poco tempo per distruggere gli standard in un progetto. Ci vuole un ottimo manager che sappia prevenire questo e difendere l'approccio giusto (quando ragionevolmente possibile) per affrontarlo davvero.

Una cosa è certa, il termine "buon codice" è troppo soggettivo per essere utile. Naturalmente non è soggettivo per te, puoi elencare i motivi / gli elementi specifici. Tuttavia altre persone elencano oggetti e priorità diverse, alcune nemmeno tecnica, che si pensa siano importanti, e dunque è soggettivo.

Come Drekka, questo inizia a sembrare deprimente, quindi lasciami provare a diventare un po 'più positivo, perché è certamente vero che: -

• Ci sono organizzazioni, spesso quelle con i maggiori componenti tecnici che stanno facendo le cose giuste.
• Più nuova è l'azienda ... e il codice ... più pulito tende ad essere. gli spaghetti crescono a causa del tempo e delle persone.
• Alcune persone fanno TDD e BDD, altri no. La gamma è enorme.
• Dopo circa 10 anni, attualmente, l'intera base tecnologica cambia in modo che coloro che rimangono nel settore possano avere difficoltà a tenere il passo dei neofiti.

Infine, come sottolinea Anthony Blake, ci sono sempre 3 fattori: tempo, costi e qualità.
Mi piace l'espressione correlata: "pick 2" !

Ci sono molte opinioni su questo perché le esperienze di ognuno sono diverse.

I miei sono che circa la metà degli sviluppatori che incontro sono ben intenzionati, ma di media capacità. C'è un piccolo gruppo di persone brillanti nella parte superiore e un piccolo gruppo nella parte inferiore che ci sta provando ma fondamentalmente dovrebbe fare qualcos'altro perché non lo capiscono davvero. Sfortunatamente c'è anche un altro piccolo gruppo di sciocchi incompetenti che pensano di essere molto più intelligenti di tutti gli altri e di solito sono abbastanza in faccia su come dovresti seguirli.

Per quanto riguarda il progetto, ho svolto molti lavori e mi è stato immediatamente chiesto di "occuparmi" di un progetto consolidato, di solito uno che l'azienda ha appena scoperto di aver davvero bisogno dopo aver perso l'ultimo sviluppatore. Di solito trovo esattamente quello che hai descritto sopra: spaghetti senza documenti, troppo ingegnerizzati, buggy. A volte posso ripararlo, a volte ricomincio da capo. Non ha nemmeno bisogno di essere un vecchio codice, l'ho trovato anche su nuovi progetti su cui mi è stato chiesto di "dare una mano".

Devi prendere il cuore dal fatto che la maggior parte delle aziende darà ai tirocinanti i lavori scadenti. Quelli divertenti vengono dopo che hai fatto due cose: 1 - hai provato te stesso e 2 - hanno dedicato del tempo a lavorare su cose diverse dalla correzione degli errori degli altri. In altre parole, devi mostrare abilità e iniziativa.

Il vero trucco per gestire il codice errato è capire cosa è salvabile e cosa no. Questo deriva dall'esperienza e dalla ricerca.

L'altra opzione di carriera che hai è quella di smettere di lavorare per aziende affermate e cercare di lavorare in startup. Quindi non ci sarà alcun codice legacy merda da mantenere in modo da avere la possibilità di aiutare a costruire qualcosa di meglio. Il rovescio della medaglia è che la pressione da consegnare ai progetti di avvio spesso significa che le scorciatoie e gli hack sono usati quando non dovrebbero esserlo.

I programmatori sono troppo spesso disposti ad assumersi un debito tecnologico per consegnare in anticipo o in tempo. Sfortunatamente l'impatto di questo debito tecnologico è spesso mascherato, ridotto al minimo, ignorato o respinto dagli sviluppatori e dal management fino a quando non è troppo tardi e sono in difficoltà.

Scusa se questo sembra deprimente. Sono sicuro che qualcun altro può fare un pezzo più positivo. :-)

Ci sono alcune grandi risposte qui, ma vorrei aggiungere la mia parte;

Benvenuti nel mondo reale - purtroppo questo è molto comune.

Fare riferimento allo schema seguente;

Con il software aziendale, puoi scegliere solo 2 o sopra e devi sacrificarne uno.

Come sembra aver scoperto, la maggior parte del mondo aziendale va con velocità e prezzo.

Non totalmente indicativo del settore, ma dalla mia esperienza limitata di oltre 5 anni. Lavorerei durante il tuo tirocinio e prenderei quante più lezioni possibili dall'esperienza. Cerca segni distintivi e indicatori. Ad esempio per la tua prossima posizione dovrai senza dubbio passare attraverso una serie di interviste. Questo processo è una strada a doppio senso e ti dà la possibilità di farti un'idea di un'azienda. Questo è di vitale importanza e probabilmente porterà alla tua felicità e al tuo benessere.

Per riassumere le cose, individuare i segni rivelatori;

• Chi gestisce l'azienda? È un singolo manager, il team di marketing (se è così, stai alla larga), il team di sviluppo, ecc. Questo angolo significa che potresti ottenere più o meno leva per i progetti, il tempo speso per i progetti, ecc.
• C'è un apprezzamento tecnico? Guarda come la direzione, il supervisore e i membri del team si trattano a vicenda. Sono stato in un'intervista in cui i manager hanno fatto tutti i tipi di movimenti delle sopracciglia una volta che il lead tecnico ha iniziato a parlare. Dopo di ciò e apprendendo che non hanno usato il controllo del codice sorgente: non potevi mostrarmi la porta abbastanza velocemente.
• Obiettivo aziendale? L'azienda vive giorno per giorno, come negli obiettivi finanziari quotidiani, o ha un piano a lungo termine di cui fai parte. Lo sviluppo del software avviene generalmente nel corso di mesi, quindi avere un'azienda di natura schizofrenica di solito porta a software disordinati.
• Scava in giro pesantemente - quando fai domande tecniche e vedi se le persone si mescolano. Controllo del codice sorgente, controllo dei documenti, processo di rilascio, segnalazioni di bug, stile di gestione, T&C, ecc.

Quindi vivi e impara e pensa al tuo prossimo ruolo. Avere una brutta esperienza non è poi così male, perché sarai meglio istruito sul mondo del lavoro e degli affari.

Bene, sto correndo per il mio secondo decennio nel settore, e posso dirti che il codice pulito perfetto accade molto raramente, e quando succede, non rimane a lungo in quel modo. In generale ti ritroverai costantemente a riparare gli errori del passato, mentre (purtroppo) sarai costretto da vincoli di tempo e da una cattiva leadership a commettere gli errori del presente.

A meno che non ci si trovi in ​​un tipo molto specifico di software, la pressione per ottenere un prodotto funzionale fuori dalla porta prevale su tutte le altre preoccupazioni e l'ottimizzazione oltre un certo punto è considerata inutile. Se il programma viene eseguito in 5 minuti e ne abbiamo solo bisogno in 5 minuti, nessuno ti concederà alcune settimane per ridurre il tempo di esecuzione a 2 minuti.

Se, per miracolo, hai quella perfetta confluenza di gestione competente, un obiettivo chiaro, denaro, talento e tempo e produci un prodotto pulito e superiour ... L'unico modo in cui rimarrà in quel modo è se non tocchi mai di nuovo . La manutenzione e l'estensione hanno quasi sempre una priorità molto bassa, le modifiche sono sempre necessarie senza preavviso e finiscono per essere erroneamente sospese.

Ieri stavo pensando a questo progetto. Per me è stato un sogno irrealizzabile, che ho fatto rimbalzare fuori dalla porta un pezzo di schifo davvero minimamente funzionale. L'ho visto come una perdita di tempo e risorse.

Bene, sorpresa, sorpresa, tutti l'hanno adorato e ha funzionato bene. Quindi sono tornato al tavolo da disegno e l'ho fatto bene. E la nuova versione è stata fantastica! Ma poi c'è stato un turnover nella gestione e l'intera faccenda è stata scartata a favore di una "nuova direzione aziendale".

La seconda iterazione ha avuto un dispiegamento davvero mediocre all'interno dell'azienda, e non ho mai sentito un'altra cosa a riguardo, il che è divertente perché so che almeno ~ 10 unità aziendali lo stanno ancora usando (il software che stiamo commissionando per fare il lavoro è in ritardo di quasi 2 anni) e apparentemente non si rompe mai.

Questo ci porta al mio ultimo punto. Anche se produci qualcosa di miracoloso, il fatto che funzioni così bene significa che NESSUNO ne avrà la minima familiarità, e quando si romperà (di solito perché hanno fatto qualcosa di stupido) allora malediranno il tuo nome peggio di loro maledire mai quell'idiota che ha scritto quella cosa che si rompe ogni terzo martedì.

È difficile dire cosa consideri un codice di qualità orribilmente bassa, ma sì, pochi programmatori sono molto bravi (per definizione). Man mano che il software si evolve, le persone commettono errori. Nel tempo questi si accumulano e la pressione aziendale (e la pigrizia / ignoranza del programmatore) rende il refactoring ... Non comune.

Non posso davvero parlare per tutti, ma ecco cosa posso dire.

Non lavoro più di 30 anni nel dominio, ma ho visto abbastanza per dire alcune cose. Un progetto ha una vita simile a un essere umano. La progettazione iniziale potrebbe non adattarsi alle esigenze attuali per dire un progetto dopo 20 anni di sviluppo. Detto questo in un lasso di tempo, molte persone hanno cambiato il codice e hanno aggiunto cose che all'inizio non dovevano essere possibili.

Non è davvero difficile immaginare brutti codici su progetti legacy o progetti piuttosto vecchi. Non possiamo aspettarci che tutti comprendano appieno i progetti iniziali. È triste ma è così.

Detto questo, devi tenere presente che il refactoring di un progetto legacy non è sempre possibile e a volte nemmeno desiderato. Ho lavorato in un'azienda in cui stavano sviluppando il sostituto del progetto a cui stavo lavorando. Non mi è stato permesso di riformattare troppo il mio progetto temendo che avrebbe funzionato meglio del nuovo progetto. Sono abbastanza sicuro che questo progetto non potrebbe mai funzionare meglio di uno nuovo. la frase era un po 'come "Non renderlo migliore, fallo funzionare".

Alla fine non avrai spesso quel tipo di progetto, come spesso leggo e ascolto. Dovresti provare a trovare lavoro con le startup anziché con le grandi società. Le start-up sono piuttosto interessanti e alla fine puoi andare avanti velocemente se vedi che non sta andando come vuoi anche tu.

Inoltre, una cosa che puoi fare, davvero non prometto nulla, ma se ritieni che il codice sia davvero così male e necessiti di refactoring. Condividilo con il team. Tieni presente che le persone che hanno scritto quel brutto codice potrebbero lavorare con te. Non si tratta di ferire il sentimento delle persone, ma se vedi che il progetto a cui stai lavorando crollerà dopo qualche tempo e le persone passeranno più tempo a capire cosa fa invece di migliorarlo. È meglio parlare e comunicare il problema piuttosto che tenerlo per te. Se sei abbastanza fortunato potresti finire con il refactoring del progetto.

Se finisci per refactoring il progetto, potresti finire per essere la persona indicata per cattive scelte di design! E quindi potresti capire perché il refactoring non accade così spesso. Spero che se l'intera squadra debba rifattorizzare, allora nessuno verrà messo in discussione. Spareranno a tutti =)

Vorrei provare a riassumere una risposta a queste domande con una semplice citazione:

All code turns to crap given enough time and hands.

Il resto sono solo storie ...

La qualità del codice dipende principalmente da due fattori.

Il primo è sempre denaro. Le aziende che hanno un'elevata pressione sopravvissuta di solito pagano salari bassi, coinvolgono sviluppatori meno esperti, hanno orari stretti e né tempo né denaro per sfruttare i loro sviluppatori.

Il secondo è la gente. Innanzitutto chi decide sui budget deve optare per la spesa in qualità di codice, quindi deve coinvolgere le persone che vogliono "viverlo". Come puoi immaginare, potrebbe risultare difficile convertire un programmatore top-down-Delphi cinquantenne ben pagato (nessun intento di stereotipi, mi dispiace) in uno sviluppatore Java aggiornato che realizza e costruisce CI codice debolmente accoppiato. Molti sviluppatori hanno un'avversione per le lezioni di (forse più giovani) compagni, a loro non piace qualcuno che pesca nel loro stagno - o fa tintinnare il trono.

Quindi, detto questo, e anche considerando il fatto che hai un codice legacy accanto a ogni azienda, direi che ne ottieni molto nella vita reale. Quello che potresti fare è comportarti come un boy-scout: vai nel bosco, raccogli un po 'di immondizia e puliscilo. La prossima volta avrai meno problemi da fare.

Benvenuti nel codice con un budget! C'è una grande differenza quando lo sviluppo viene spinto dalla direzione per essere fatto troppo presto, senza pianificazione e con angoli taglienti. Ho avuto un'esperienza simile di shock nel mondo reale quando ho ottenuto il mio primo lavoro di programmazione fuori dal college. Nessuna documentazione! Nel corso del tempo ho imparato molto, scrivere e mantenere la documentazione formale aggiornata è solo una perdita di tempo. Fortunatamente per me, quella era una squadra fantastica. Era guidato da un ragazzo che sapeva cosa stava facendo e agli altri membri del team importava davvero scrivere il codice nel modo giusto. Da allora, le mie esperienze sono state simili alle tue. Un sacco di codice orribile, un sacco di codice cattivo, un sacco di "sviluppatori" all'oscuro. Per ogni buon sviluppatore, sembrano esserci 100 cattivi.

Non sei condannato a odiare il tuo lavoro per sempre. Devi solo trovare un'azienda abbastanza intelligente da riconoscere i benefici a lungo termine che è disposto a investire un po 'in anticipo. Sono riuscito a dimostrare che fare le cose nel modo giusto invece che nel modo più veloce è vantaggioso e sono diventato molto rispettato e fidato per quello nelle aziende in cui ho lavorato. Nel tempo, il codice spaghetti è stato risolto o diventa obsoleto e il tuo codice prende il sopravvento. Preparati a scendere a compromessi. A volte il modo più cool o più robusto di programmare qualcosa è semplicemente eccessivo ed è ok farlo nel modo più rapido e sporco.

Ho fatto uno stage presso una delle maggiori società di software

Non tutte le aziende sono uguali. Nella maggior parte delle aziende troverai team maledetti e basi di codici software scadenti. Ma puoi anche trovare grandi team e ottime basi di codice.

Penso che i ragazzi di Solaris abbiano fatto una descrizione molto buona e onesta del tipo di basi di codice che troverete nelle grandi aziende: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

Finora ho lasciato il lavoro odiando il lavoro e desidero disperatamente sapere se questo è ciò che è in serbo per il resto della mia vita.

No, sto programmando da più di 15 anni e lo adoro ancora.

Questo non vuol dire che tutto sia stato perfetto. Ho visto alcune basi di codice orribili e anche alcune fantastiche. Il trucco è trovare il posto giusto per te.

Una grande azienda è molto diversa da una piccola. All'interno dello stesso team aziendale A a volte è molto diverso dal team B. Trova quello che ha il giusto equilibrio per te (ad es. Progetti stimolanti, una cultura che ti piace, una buona paga, eccetera)

In bocca al lupo!

Ho visto cose simili come te. Ho due esperienze di casi quando si verifica.

1. Quando lo sviluppo è troppo guidato dal progetto. L'unica cosa che conta è fornire funzionalità in tempo, quindi firmare. Il prossimo cambiamento sarà fatto da qualcun altro, da qualche altro team / project manager con un nuovo budget.
2. Quando un software viene gestito da poche persone per un lungo periodo di tempo, gli sviluppatori tendono a diventare pigri, poiché conoscono comunque il loro software. I principi accademici sono lontani.

È triste, ma è così che è in alcuni punti.

Scopri se puoi apportare una piccola modifica in meglio, abituarti o passare a un'altra azienda e chiedere di schermare del codice durante l'intervista :-)

Questa sarà una risposta breve.

L'istruzione è molto utile per farti sentire qualificato e idealista. Questa è una buona cosa e dovresti cercare di aggrapparti all'idealismo.

Se sei assolutamente obiettivo e puoi guardare indietro al tuo lavoro in futuro, non sarà un'esperienza molto appagante. A meno che tu non menti a te stesso o non impari nulla, vedrai molti modi per migliorare ciò che hai fatto.

In generale, il mondo intero lo sta facendo intorno a te. Quindi, quando guardi al lavoro del passato, a parte le eccezioni, sembrerà inferiore e bisognoso di miglioramenti. Se non ti senti così, significa che stai facendo un lavoro sbagliato o che sta pagando troppo bene.

La buona notizia è che puoi trarre vantaggio dagli errori degli altri e dal confronto con il passato. Se tutte le applicazioni funzionassero bene e fosse facile mantenere nuovi sviluppatori non sarebbero necessari. A mio avviso, la manutenzione di alcuni altri sviluppatori cruft è un'esperienza di apprendimento utile e dovrebbe essere un elemento di formazione obbligatorio per tutti gli sviluppatori di cielo blu.

La tua esperienza negativa è fin troppo tipica delle grandi società di marca famose che molti sviluppatori imparano ad affrontare con molta più cautela e trepidazione di quanto non abbiano fatto la prima volta che hanno avuto l'opportunità di lavorare in una. Fondamentalmente, più livelli di gestione hai, più si difende la mediocrità. I dirigenti intermedi non riferiscono ai dirigenti superiori in merito alla qualità del codice. Riferiscono sulle funzionalità fornite in X quantità di tempo e offrono presentazioni powerpoint sulla caratteristica dell'interfaccia utente che sperano che funzioni abbastanza a lungo da farcela. Se tutto crolla su se stesso un mese dopo, di solito questo è il problema di qualcun altro e loro lo sanno.

Quindi sì, gli sviluppatori che sono sollevatori in tali luoghi tendono a non preoccuparsi troppo. Non potrebbero sopravvivere lì se lo facessero. Ho sentito dire della Silicon Valley, che se vuoi essere pigro, lavora per uno dei grandi nomi. Se vuoi un lavoro entusiasmante, cerca una startup più recente che non sia ancora un nome familiare. Lavoro a Chicago e posso garantire un fenomeno simile qui.

Come regola generale (con molte eccezioni, ne sono sicuro), troverai un apprezzamento maggiore per il codice di qualità nelle aziende più piccole, gestite o possedute da persone che continuano a scrivere codice. La compensazione è spesso inferiore, ma il lavoro è spesso molto più gratificante secondo me.

Come sviluppatore entry-level non avrai probabilmente molto controllo su chi lavori all'inizio, ma dirò che avere un nome importante sul tuo curriculum per un anno o più eccita sicuramente i recruiter e le persone delle risorse umane. Inoltre, puoi imparare un po 'che non impareresti altrimenti lavorando per qualcuno completamente terribile nei primi sei mesi circa e ti aiuta anche a capire meglio quali sono le migliori pratiche e perché e quali mode.

E, naturalmente, quando lavori con strumenti aziendali più diffusi, tenderai a scoprire che i livelli di talento mediano saranno piuttosto scadenti. Se le tue abilità primarie sono una combinazione di Java e C #, espandi leggermente i tuoi orizzonti. Potresti trovare una nicchia più felice a medio livello scrivendo Erlang o Python o: o JavaScript.

E non lasciare che nessuno ti dica qualcosa di diverso. Potresti non avere scelta in merito a come procedere, ma il codice merda è costoso! @ # $ Ing.

La tua domanda si è concentrata sugli stage. Non ne ho mai avuto uno programmatore, ma ho fatto uno stagista presso una stazione radio, non proprio applicabile qui.

La tua domanda menzionava anche le tue esperienze durante i tuoi stage. Le tue esperienze di tirocinio e le risposte che hai ricevuto finora riassumono praticamente tutte le mie esperienze, dopo quelli che ora sono ventisette anni di scrittura di software (iniziata a metà giugno 1985).

Non ci avevo mai creduto durante la scuola quando i nostri istruttori dissero che c'è più pensiero che scrivere un codice. Avevano ragione. E, se stai cercando di capire il codice di qualcun altro, è peggio senza commenti e quasi altrettanto male con i commenti. Prova a sostenere un sistema di riscossione delle imposte comunali cresciuto in casa senza commenti, documentazione, build formale e controllo del codice sorgente.

Ogni volta che puoi fare bene senza che sia una violazione diretta degli ordini standard, allora fai bene. Ricorda sempre, è più facile scusarsi per aver fatto qualcosa che non hai chiesto il permesso di fare piuttosto che non avere il permesso non essere concesso e andare contro un ordine diretto.

Non dimenticare gli standard che ti hanno insegnato a scuola. Non sono inutili, ma molto probabilmente tali standard sono gli asintoti nei limiti di calcolo. Puoi sempre provare ad avvicinarti a loro, ma potresti non raggiungere mai il loro valore.

In bocca al lupo.