La gestione del codice legacy aiuta a evolversi come programmatore? [chiuso]


18

Sono uno sviluppatore Java con un po 'più di un anno di esperienza che mi colloca da qualche parte sopra uno junior, ma non ancora tra gli sviluppatori di medio livello. Recentemente mi è stato offerto un progetto a lungo termine che riguarda lo studio di un codice di applicazione bancaria esistente per 4 mesi e quindi l'introduzione di modifiche quando necessario. Come programmatore non così esperto sto cercando modi per svilupparmi e mi chiedo cosa potrebbe dare un progetto del genere.

Considereresti di trattare con un'applicazione grande e probabilmente non così ben scritta una buona pratica per un principiante?



1
Imparare dagli errori degli altri è il modo più sicuro per fare esperienza ...
Michael Borgwardt,

Di recente ho studiato il codice di altre persone per circa un mese. Ottima esperienza di apprendimento, ma ha fatto schifo alla grande. Necessario sperimentare sedativi di tè.
usr

Ci può essere un buon Java, ma è più difficile da trovare per un jr. dev rispetto agli sviluppatori della maggior parte degli altri contesti linguistici iniziali, immaginerei in base all'esperienza che è principalmente come sviluppatore web front-end diventato generalista che è stato esposto a una vasta gamma di back-end. Il problema, penso, è che Java il linguaggio è perfettamente funzionale, ma Java la cultura è di giocare assolutamente a tutto il più sicuro e senza colpa.
Erik Reppen,

Risposte:


34

La risoluzione dei problemi del codice esistente è un modo eccellente per svilupparsi come programmatore. Se il codice è errato, imparerai l'impatto degli errori che hanno commesso e forse ne eviterai alcuni durante la progettazione. Se il codice è buono, imparerai qualcosa su come creare un'applicazione gestibile.

Imparerai anche a gestire la complessità di una vera applicazione aziendale. Dal momento che questo è nel settore bancario, imparerai cose come la regolamentazione federale e i controlli contabili interni che potresti non aver mai pensato. Queste sono buone cose da sapere quando ti viene chiesto di progettare qualcos'altro nel mondo finanziario. E la programmazione finanziaria può essere un settore piuttosto redditizio in cui lavorare, quindi acquisire esperienza bancaria può essere molto utile per te.

Potresti persino imparare che solo perché qualcosa è stato scritto 15 anni fa, in una lingua che preferiresti non usare, non è necessariamente male. Dopotutto, ha funzionato correttamente.

Se, come con la maggior parte delle app legacy, l'applicazione non dispone di test di unità, devi davvero assicurarti che una modifica non influisca su qualcos'altro, potresti imparare come aggiungere quel test e come vendere la gestione sul perché l'aggiunta di quel test è una buona idea.


2
In effetti, se hai 4 mesi per studiare il codice, dovresti dedicare molti di quei 4 mesi ad aggiungere commenti che documentano ciò che apprendi e scrivere test che dimostrano che i componenti chiave funzionano correttamente (come si spera che facciano).
Ross Patterson,

1
@RossPatterson, dato che si tratta di operazioni bancarie, sì, spero che funzionino correttamente ora. In ogni caso, se non ci sono test, il rischio di apportare una modifica è enorme nelle operazioni bancarie e nella scrittura di test unitari per aiutarti a imparare il sistema dovrebbe essere una vendita facile.
HLGEM,

3
La programmazione è sapere come spostare i pezzi. Comprendere un sistema è saper giocare. Non ti pentirai dell'esperienza dal punto di vista dello sviluppo delle abilità. Lavorare per aziende che rubano da vedove e orfani è qualcosa che la tua coscienza potrebbe non tollerare.
Meredith Poor,

8

Penso che sia una pratica eccellente per un principiante chiunque. Imparare dall'esperienza altrui può essere molto efficace.

La vera sfida non è trovare errori, ma entrare nella testa dell'altro sviluppatore e cercare di capire che whyil codice è stato scritto in quel modo. A volte è perché erano sciatti, a volte perché avevano una buona ragione. Supponiamo che lo sviluppatore sia stato buono almeno quanto te, ma potrebbe aver avuto più conoscenza del dominio.


2
Ti aiuta anche a capire che il metodo che pensi che avrebbero dovuto usare non era disponibile al momento della scrittura del codice.
HLGEM,

Sarebbe bello trovare alcuni commenti sul codice o documentazione del progetto in queste situazioni. Altrimenti quel modo strano o strano di implementare una funzione rimarrà un mistero. Lo sviluppatore potrebbe non essere nemmeno più nella società, quindi non c'è modo per te di chiederglielo.
Radu Murzea,

6

Questa è una buona pratica per qualsiasi sviluppatore in qualsiasi momento della sua carriera. Se riesci a rivedere e analizzare il software esistente e trovare modi per migliorarlo, dimostrerai di essere uno sviluppatore prezioso. Non solo imparerai come altri hanno progettato e sviluppato software, ma lungo la strada imparerai cosa non fare, che è una conoscenza preziosa in sé.

Se sei pronto per la sfida, porta avanti questo progetto e miglioralo.


2

Ti aiuterà assolutamente, ma devi stare attento.

Devi assicurarti di imparare dal codice legacy. Come fai a sapere cosa è buono e cosa è cattivo? Forse puoi riconoscere i pro e i contro di diversi modelli / metodi, ma se tu fossi uno sviluppatore junior all'inizio, potresti non essere in grado di farlo.

E rimani troppo a lungo in quel primo lavoro, e potresti non imparare o sviluppare abbastanza competenze e finire lì bloccato.


2

Legacy può significare tutt'altro che sulla base del tuo commento "non ben scritto" Suppongo che Legacy significhi tecnologie e schemi "scadenti" o almeno "obsoleti". Se il codice legacy è valido, non trattenerti e apprenderne ogni riga.

Non credo che ci siano abbastanza chiari avvertimenti contro il tipo di lavori e progetti che deviano la tua carriera e ti bloccano in buchi di lavello senza valore su questo thread fino ad oggi.

Avviso di analogia sportiva: pensi che un sostenitore della linea nella NFL impari di più e diventi più prezioso giocando in squadra con il record peggiore o il migliore? La mia risposta: non solo sono più preziosi avendo giocato per le migliori squadre, ma probabilmente hanno acquisito le migliori pratiche e conoscenze ed evitato di raccogliere le pratiche e gli atteggiamenti di fine carriera.

C'è un sacco di codice anti pattern terribile là fuori che funziona davvero per l'azienda e paga molti stipendi. Propongo che uno sviluppatore che non ha visto abbastanza codice fatto nel modo "giusto" possa confondere il codice anti pattern con una soluzione legittima a un problema. Il business potrebbe dire che la soluzione funziona, ma non è quella che desideri sul tuo curriculum o quella che vorresti vantarti con altri sviluppatori. Ciò è rilevante solo se il tuo percorso di crescita personale include il rispetto dei tuoi colleghi di ingegneria e non solo un aumento temporaneo delle entrate di qualsiasi azienda per cui lavori (suona male, ma alla fine, la migliore ingegneria fa assolutamente la maggior parte dei soldi IMO) .

Sfortunatamente c'è molto codice e molto tempo che può passare prima che venga rivelato il debito tecnologico. E quel debito tecnologico di solito viene riconosciuto esattamente quando è troppo tardi. Chiunque abbia mai provato a fermare il debito tecnologico o gli schemi anti prima, avrebbe potuto essere messo da parte a causa della spesa aggiuntiva percepita o della mancanza di comprensione dell'ect della scalabilità. Come ingegneri è nostro dovere esporre immediatamente il debito tecnologico. I progetti senza ingegneri esperti sono a rischio di colpire un muro di mattoni a un certo punto, in realtà tutti i progetti anche con sviluppatori di talento. La maggior parte delle aziende considera "un certo punto" un sacco di tempo per risolverlo in un secondo momento. Questo rende le scelte di lavoro per gli sviluppatori emergenti una questione molto complicata. Sottolinea inoltre gli obiettivi e le mentalità completamente diversi tra sviluppatori e aziende e quanto sia complicato colmare il divario.

L'obiettivo degli ingegneri è quello di "includere" il vero lavoro scientifico e la considerazione del progetto, mentre l'obiettivo dell'azienda è "escludere" costi e tempi non necessari. Dal momento che gli ingegneri spesso non sanno quale sia il livello di sforzo e tempo fino a quando lo stato finale non viene effettivamente realizzato, lo sviluppo del software si svolge come un buon dramma con personaggi come agile, mischia e kanban che recitano ruoli da protagonista.

Un take away potrebbe essere quello di stare lontano da un codice errato fino a quando non avrai visto abbastanza buon codice per non essere "corrotto". Adoro il detto che gli sviluppatori senior creano soluzioni semplici a problemi complessi. Come saggi, gli sviluppatori di livello medio junior creano soluzioni complesse per problemi semplici e complessi.

Un altro take away potrebbe essere che è necessario lavorare su codice buono e negativo in diversi punti per ottenere comprensione. Se non hai fatto nessuno dei due, fallo e preparati a disimparare tutto quando trovi un sistema migliore. Penso che questa sia probabilmente una traiettoria più comune per la maggior parte degli sviluppatori.

Quest'anno sono di parte perché mi sento come se stessi scalando una montagna "salsa segreta" estremamente complicata. Mentre aumenterò la mia capacità di decifrare alcuni dei peggiori schemi che abbia mai visto, è così "personalizzato" e "unico" che non credo che la mia lotta aumenterà la mia commerciabilità o le mie abilità utilizzabili nel mio futuro.

Al fine di mantenere la mia sanità mentale, sto solo ridacchiando a un ritmo costante e abbracciando ogni blocco stradale come alla pari per il corso. Avendo appena rivisto i miei obiettivi annuali con il mio capo che includono scavare da questo buco ereditato, penso che potrebbe essere una scalata sacrificale. Potrei sopravvivere al processo con recensioni negative e lentezza percepita. Questo è un avvertimento realistico e presuntuoso per quelli di voi che si chiedono quale lavoro prendere.

Disclaimer: questo post vivrà molto più a lungo delle mie opinioni, quindi prendilo con un pizzico di sale. Domani potrei amare il codice legacy! (Ne dubito).


1

Dipende molto da come si definisce "eredità" in questo contesto. Lascia che ti faccia un esempio da C e C ++. Molti programmatori C ++ definiscono una cattiva pratica l'uso delle stringhe C nelle applicazioni C ++, altri non richiedono alcun mixaggio, mentre altri, a loro volta, sostengono che sia puro e assolutamente inutile utilizzare qualsiasi bit di codice C perché sono vecchi, ovvero " codice "legacy". Alcuni vanno oltre ed evitano di usare pre-C ++ X (sostituisci la 'X' con il numero appropriato) idiomi standard, stile - questa è sintassi, per il suo stile "legacy".

Lasciando da parte i problemi di prestazioni di stream e stringhe C ++ e alcune peculiarità STL, è sicuramente una buona pratica dare un'occhiata a cosa c'è dentro la tua tanto amata direttiva sui preprocessori #include <string.h>. Se segui il percorso dell'implementazione e ti ritrovi su una macchina unix / linux su /usr/include/string.h(e ottieni fonti di implementazione libc, ad esempio da gnu.org ) e leggi strcmp.co strlen.co strtok.c, scommetto che sentirai "Che bel mondo "introduzione graduale.

C'è, tuttavia, un avvertimento in questa prosa - vale a dire classi e metodi deprecati. In Java molte cose legacy sono ancora accessibili all'interno di un ambiente recente, ma se ricordo bene, non tutto. Nel settore IB, per esperienza personale, non tutti i software sono scritti da buoni programmatori. Molti laureati avevano avuto un'esposizione pressoché nulla alla programmazione nel mondo reale prima di iniziare a lavorare come analisti / sviluppatori. Ma non generalizzare questa affermazione. Conosco molte persone che utilizzano Java e C # al centro di ambienti ad alta produttività e bassa latenza. Non sono d'accordo con loro, ma bene, per fortuna sono affari loro. Se fossero diventati veri HFT, sarebbero stati spinti molto indietro nella linea. Ma ancora facilmente deducibile da questa frase è il presupposto (e in molti casi il fatto) che il codice Java sia altamente ottimizzabile. E se riesci a eccellere nell'ottimizzare, se necessario, non solo correggere questo o quello, diventeresti prezioso come sviluppatore. È molto soddisfacente, tra l'altro, capire quanto hai contribuito. Ci proverei.

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.