Come posso (con tatto) dire al mio project manager o al capofila che la base di codice del progetto ha bisogno di un lavoro serio?

Potresti passare il tuo tempo a discutere del tuo caso; oppure potresti passare il tempo a ripulire mentre vai avanti.

Rispondi Pulisci codice e Principi, modelli e pratiche di sviluppo software agile e applica ciò che impari mentre lavori sul sistema. Alla fine, la gente noterà (per meglio o peggio).

Modifica Consulta anche Lavorare efficacemente con il codice legacy

Da ciò che descrivi, sembra che i problemi riguardino principalmente il mancato rispetto degli standard di codifica e dei problemi di denominazione. Questo non è un disastro , di gran lunga. Per un confronto, questo è un disastro, per davvero.

Forse sei abituato e richiede standard elevati? In tal caso qualsiasi deviazione dalla perfezione potrebbe essere considerata un fallimento. Questa è una trappola in cui è facile cadere quando le tue richieste sono alte, ma è importante mantenere la prospettiva sulle cose.

Ti suggerisco di parlarne come un miglioramento e di aiutare il team ad aggiornare le linee guida e istruirli a iniziare a usarlo per davvero. Mi piace molto usare una definizione di Fatto come un punto di riferimento di qualità e crearne una è una grande squadra esorcizzare da sola. Ma non penso che dovresti fare molto di più di questo, almeno non come nuovo membro del team.

Sicuramente non esagerare con la tua MCSD, le persone ti ridono sinceramente, i MS certs sono carini da abbienti ma non sono in alcun modo una qualifica professionale!

Passo unendo leggermente una nuova squadra, cerca le opportunità per suggerire le modifiche man mano che fai.

Attendi fino a quando non ottieni la disposizione del terreno prima di rimuovere il codice di una squadra.

Potresti considerare che il problema sei tu. NESSUNO delle tre cose che hai menzionato sono degne di una rielaborazione completa di un'applicazione. Sono solo dettagli nitidi.

Ricorda che l'obiettivo dell'applicazione non è quello di avere un codice bello, ma quello di risolvere un problema aziendale. Certo, è bello avere un codice coerente e che segua un buon standard, ma la sua mancanza non è un motivo per spazzare l'intero codice. Solo perché il motore è oleoso non significa che debba essere ricostruito.

Guarda, tutti odiano ogni base di codice che non hanno scritto. In effetti, se aspetti tre anni e guardi il tuo codice, lo odierà e penserai che ha bisogno di una completa riscrittura. La verità è che non è così. A meno che tu non riesca a dimostrare che spendere mesi per rendere il codice esteticamente piacevole per te invece di creare funzionalità per aggiungere valore commerciale, probabilmente stai abbaiando dall'albero sbagliato.

Nulla dice che devi scrivere il codice kludgy solo perché potrebbero essercene alcuni nel codebase. E nulla dice che il codice è semplicemente kludgy perché non aderisce al tuo stile preferito. Basta refactoring mentre vai avanti su parti su cui lavori e scrivi un buon codice quando lavori su nuove cose.

Queste cose vanno bene se ti preoccupi, ma se sei nuovo nel team non scuotere ancora la barca fino a quando non avrai guadagnato credibilità con loro.

Sembra che tu abbia scelto tre cose (relativamente) secondarie su cui preoccuparti. Ci sono altre cose di cui mi preoccuperei di più:

• Il codice è ben documentato?
• Il codice aderisce a specifiche / documenti di progettazione?
• Il codice funziona?
• È facile capire cosa fa il codice?
• Stai pensando di inviare grossi pezzi di questo codebase a TheDailyWTF?

Ci sei stato per una settimana? Non sono sicuro che tu sappia abbastanza ancora da presentare proposte al responsabile del progetto. Anche se hai il sospetto che il codice e le pratiche di questa squadra siano "cattivi", il modo migliore per influenzare queste cose nel tempo è guadagnare gradualmente la loro fiducia e rispetto. Entrare in un progetto e dopo una settimana dire al team che il loro codice deve essere riscritto non è un buon modo per ottenere fiducia e rispetto.

Per i tuoi primi mesi, concentrati sull'impostazione di un esempio migliore e facendo domande sul perché hanno fatto le cose in determinati modi. Stai attento al tuo tono quando fai queste domande. Se ti capita di incontrare il nuovo tipo "conosci tutto", nessuno ascolterà le tue opinioni più tardi quando sarai veramente in grado di influenzare il modo in cui le cose sono fatte.

Nel tempo, se il tuo codice è veramente "migliore", gli altri sviluppatori lo vedranno. Cominceranno a venire da te come una risorsa per aiutarli a sistemare i loro, e poi a chiedere il tuo consiglio su come dovrebbero fare le cose. A quel punto, sarete in un'ottima posizione per dire al team (e alla direzione) le vostre opinioni sugli standard di codifica e simili. Quanto dura questo processo varia in base all'organizzazione. Potrebbero essere solo poche settimane in un ambiente molto adattabile, o mesi o anni in una cultura più stoica. Costruisci la tua influenza una persona alla volta.

Non entrerai mai in un nuovo lavoro in cui penserai che la base di codice sia perfetta e che tutto sia stato fatto nel modo giusto. Impara ad accettare questo. Tutto quello che puoi fare con il codice legacy è refactoring e andare avanti a poco a poco. Alcune cose che non vuoi refactoring finché non hai più comprensione di perché hanno fatto quello che hanno fatto. Inoltre, nessuno nel mondo degli affari ti pagherà per sistemare il codice di lavoro, quindi dovresti fare un business case per il motivo per cui ha bisogno di lavoro prima di intensificare e passare il tempo. È meglio aspettare il codice refactor quando c'è un cambiamento che devi fare comunque. Potresti non aver scelto il metodo che hanno fatto per alcune cose, ma se funziona, stai molto attento a cambiarlo e introdurre nuovi bug. Soprattutto quando non ti è stato chiesto di cambiarlo.

Dopo una settimana, non hai la credibilità di dare suggerimenti importanti su come fanno affari. Se porti le cose ora, la gente riderà di te e non ti prenderà mai sul serio. Dimostrati prima con un buon codice e poi le persone saranno più inclini ad ascoltare.

E francamente a nessuno importa che tu sia un Microsoft Certified Professional. Chiunque abbia molta esperienza ha visto tanti cattivi programmatori che hanno avuto quella certificazione come brava gente. Non sto dicendo che ti fa sembrare male avere una certificazione, sto dicendo che non ci crediamo molto perché non abbiamo visto dove sono efficaci ci sta mostrando chi è un buon programmatore.

Probabilmente sarei sulla strada di cercare di capire come presentare la proposta con l'intento che potresti finire per non essere in grado di giustificare adeguatamente la tua posizione. Alcune domande su cui riflettere per creare quella proposta:

• Quanto valore commerciale si ottiene effettuando i tipi di modifiche che descrivi qui?
• Hai preso in considerazione opzioni come riscrivere l'applicazione da zero, modificare il codice esistente per farlo diventare sniffato o semplicemente apportare piccole modifiche nel tempo?
• Sai quali funzionalità e bug sono desiderati ora che ti impedirebbero di apportare le modifiche che desideri?

Anche se posso apprezzare il desiderio di correggere il povero codice base, questo deve essere valutato in modo tale da avere senso da un punto di vista aziendale per farlo.

Al momento non sei nella posizione di impedire il codice errato, quindi dovrai capire come contenerlo.

I PM e i team leader si preoccuperanno solo che non funzioni. La loro prossima preoccupazione sarà quando ti chiederanno di fare cambiamenti e ti chiedi perché le cose "semplici" impiegano così tanto tempo. Ecco dove entrerai.

Inizia ora con il problema di coerenza. Qualunque sia il metodo potenzialmente standard attualmente, prova ad identificarlo e vedi se non riesci a farlo applicare. Se inizi con una metodologia a cui nessun altro è abituato, riceverai un sacco di push back.

Gli altri membri del team potrebbero voler ottenere la certificazione e sarai un'ottima risorsa. Speriamo che almeno vogliano migliorare e guardarti per mostrargli il modo.

Reclami sulla notazione ungherese non ti darà alcuna comprensione ed è probabilmente una delle ultime battaglie nella lista delle priorità.

Sono d'accordo sul fatto che devi essere cauto in merito. È necessario creare una reputazione all'interno del team prima di poter criticare e proporre profondi cambiamenti nel codice o nei processi. Vorrei solo prendere appunti sui miei risultati e amp; suggerimenti per il momento, e prendere l'opportunità di familiarizzare con i membri del team e la direzione, entrare in discussioni libere ma non rifiutare se il discorso si rivolge a problemi di qualità, domande di codifica ecc., a volte anche gettando alcune delle mie domande nello stagno ( ma in una forma generale, non troppo puntata su alcun problema concreto che ho visto all'interno di questa base di codice). In questo modo posso conoscere l'opinione dei membri del team e trovare potenziali alleati.

Nel migliore dei casi, potresti scoprire che una parte significativa del team (e / o della direzione) vede gli stessi problemi come te, solo che non c'è stata alcuna iniziativa per fare qualcosa su di loro o nessuna risorsa assegnata da gestione. Insieme hai più parole per convincere la direzione, se necessario.

Come suggerito da @Mike, è sicuramente necessario fare un po 'di pulizia, ma, di nuovo, è meglio essere pazienti con esso. Se inizi troppo velocemente, potresti alienare altri membri del team che potrebbero prenderlo come critica personale. Il tuo manager può anche prendere parte a una pulizia / refactoring completa del codice come segno del fatto che non sei sufficientemente concentrato sull'attività reale. Quindi dovresti ottenere un mandato al refattore prima di intraprenderlo a un livello più serio. Piccole modifiche locali sono probabilmente OK.

Inoltre, per convincere la direzione, hai bisogno di una logica aziendale. La gestione viene raramente spostata dalle descrizioni di come lo stile di codifica è incoerente. Devi mostrare loro quale valore possono apportare le modifiche proposte all'azienda - la linea di fondo è il denaro. Se riesci a mettere insieme un calcolo convincente sui benefici a lungo termine dei vari cambiamenti proposti e mostra che il saldo complessivo è chiaramente positivo, hai migliorato notevolmente le tue possibilità.

Fai da te. Se apprezzi determinati stili di codifica, allora lavora sul codice che viola gli stili di codifica . Esegui il checkout di un pezzo di codice offendente dal controllo del codice sorgente, riformatta il codice in base al requisito degli spazi bianchi dello stile (ad esempio) e invia il codice aggiornato con il messaggio "Conform to the rule of the guide on the whitespace."

Dopo una settimana la cosa peggiore che probabilmente puoi fare è andare direttamente al management con questo. Con ogni probabilità hanno messo un sacco di tempo nel codice e hanno un certo grado di orgoglio in esso. Probabilmente verrai fuori come un vero "conosci tutto".

Quello che farei se fossi in te è migliorarlo mentre vai avanti. Man mano che ne hai più familiarità e mentre lavori su più di esso avrai la possibilità di migliorarlo. Sarebbe a quel punto che inizierei a mostrare i benefici di ciò che state facendo ad altri colleghi di lavoro. Dopodiché, quando le riunioni di progettazione escono per nuovi moduli, presenta un argomento per ciò che percepisci come il modo migliore.

E onestamente, gli standard esistono per una ragione ma, se funziona e funziona bene, vale 100 volte di più nel mio libro (specialmente dopo una settimana in). Sarei più preoccupato se avessi aperto il codice e visto un sacco di errori logici o qualcosa del genere.

Non andare direttamente alla gestione con questo "problema".

In primo luogo, parla ai tuoi colleghi e scopri da loro perché le cose sono come sono. Quindi puoi valutare meglio se c'è un problema o no. Potresti essere sorpreso da ciò che impari. Puoi anche trovare alleati nel volerlo ripulire.

Se non hai idea di come sei arrivato dove sei, in primo luogo, è molto più difficile uscirne.

Un sacco di buoni suggerimenti qui già, e io sono del non-bruciare-i-tuoi-ponti-fino a-hai-dimostrato-te-prima opinione come gli altri. Quello che vorrei aggiungere è discutere le cose con i tuoi compagni di squadra molto prima di alienarli andando prima al project manager o al team lead. E certamente mostrali prima di questo, che dovresti essere preso sul serio.

Sembra anche che si tratti più di un problema stilistico che stai riscontrando con il codice. Prendere in consegna il codice di qualcun altro e tenere il naso mentre si sta usando per il modo in cui lo hanno scritto è solo una parte del lavoro, anche se è una cosa banale come il modo in cui lo formattano. Consegnare uno dei tuoi "bambini" a qualcun altro perché li manipoli con le loro mani sudice è anche peggio ...

Se alla fine è più di questo - e il problema è più funzionale che solo stilistico - se vai alla guida del team / pm è meglio lanciare la necessità di una rielaborazione in termini di dove risparmiare denaro e fatica in un futuro progetto di sviluppo. Buon vecchio refactoring.