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

Sono appena entrato a far parte di un (relativamente) piccolo team di sviluppo che ha lavorato a un progetto per diversi mesi, se non un anno. Come con la maggior parte degli sviluppatori che si uniscono a un progetto, ho trascorso i miei primi due giorni a rivedere la base di codice del progetto.

Il progetto (una linea di business interna ASP.NET WebForms di medie e grandi dimensioni) è, per mancanza di un termine più descrittivo, un disastro. Esistono tre problemi immediatamente evidenti con gli standard di codifica:

1. Lo standard è molto lento. Esso descrive più di quello che non lo fanno (non usare la notazione ungherese, ecc ..) per quello che a fare.
2. Lo standard non è sempre seguito. Ci sono incoerenze con la formattazione del codice ovunque .
3. Lo standard non segue le linee guida di stile di Microsoft. A mio avviso, non ha alcun valore deviare dalle linee guida stabilite dallo sviluppatore del framework e dal maggior collaboratore alla specifica del linguaggio.

Per quanto riguarda il punto 3, forse mi disturba di più perché mi sono preso il tempo per ottenere il mio MCPD focalizzato sulle applicazioni web (in particolare ASP.NET). Sono anche l'unico professionista certificato Microsoft del team. A causa di ciò che ho imparato in tutto il mio apprendimento scolastico, autodidatta e sul posto di lavoro (compresa la mia preparazione per gli esami di certificazione) ho anche individuato diversi casi nel codice del progetto in cui le cose semplicemente non sono fatte nel miglior modo.

Faccio parte di questa squadra da una settimana, ma vedo così tanti problemi con la loro base di codice che immagino che passerò più tempo a combattere con ciò che è già scritto per fare le cose a modo loro di quanto farei se lo fossi lavorando su un progetto che, ad esempio, ha seguito standard di codifica, schemi di architettura e best practice più ampiamente accettati. Questo mi porta alla mia domanda:

Dovrei (e se sì, come devo) proporre al mio project manager e al mio team di condurre la necessità di rinnovare il progetto?

Non voglio entrare nel loro ufficio, agitando i miei certificati MCTS e MCPD, dicendo che la base di codice del loro progetto è una schifezza. Ma non voglio nemmeno tacere e scrivere il codice kludgey sopra il loro codice kludgey, perché in realtà voglio scrivere software di qualità e voglio che il prodotto finale sia stabile e facilmente gestibile.

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

Raccogli i principi, i modelli e le pratiche di sviluppo di codice pulito e software agile e applica ciò che impari lì mentre lavori sul sistema. Alla fine, le persone noteranno (nel bene o nel male).

Modifica Guarda anche Lavorare in modo efficace con il codice legacy

Da quello che descrivi, sembra che i problemi riguardino principalmente il mancato rispetto degli standard di codifica e dei problemi di denominazione. Non è di gran lunga un disastro . 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 su cui è facile cadere quando le tue richieste sono elevate, ma è importante mantenere una prospettiva sulle cose.

Ti suggerisco di parlarne come un miglioramento e di aiutare il team ad aggiornare le loro linee guida e istruirle per iniziare ad usarlo davvero. Mi piace molto usare la definizione di fine come parametro di qualità e crearne una è una grande squadra esorcizzata da sola. Ma non penso che dovresti farne molto di più, almeno non come nuovo membro del team.

Sicuramente non andare in giro con il tuo MCSD in giro, la gente ti riderà francamente, i certificati MS sono simpatici, ma non sono in alcun modo una qualifica professionale!

Entra a far parte di un nuovo team, cerca opportunità per suggerire cambiamenti mentre procedi.

Attendi fino a quando non ottieni il terreno prima di eliminare il codice di una squadra.

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

Ricorda che l'obiettivo dell'applicazione non è avere un bellissimo codice, è risolvere un problema aziendale. Certo è bello avere un codice che sia coerente e segua un buon standard, ma la sua mancanza non è un motivo per cestinare l'intera base di 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 odierai e penserai che abbia bisogno di una riscrittura completa. La verità è che non lo è. A meno che non si possa sostenere che trascorrendo mesi a rendere il codice esteticamente piacevole per te invece di costruire funzionalità per aggiungere valore commerciale, probabilmente stai abbaiando l'albero sbagliato.

Nulla dice che devi scrivere codice kludgy solo perché potrebbero essercene alcuni nella base di codice. E nulla dice che il codice sia kludgy solo perché non aderisce al tuo stile da compagnia. Rifletti mentre procedi sulle parti su cui lavori e scrivi un buon codice quando lavori su nuove cose.

Queste cose sono OK di cui preoccuparsi, ma se sei nuovo nel team non scuotere ancora la barca, fino a quando non avrai acquisito una certa credibilità con loro.

Sembra che tu abbia scelto tre cose (relativamente) minori di 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 codice a TheDailyWTF?

Sei stato lì per una settimana? Non sono sicuro che tu ne sappia abbastanza per fare proposte al project manager. 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 guadagnare fiducia e rispetto.

Per i tuoi primi mesi, concentrati sul dare l'esempio migliore e porre domande sul perché hanno fatto le cose in determinati modi. Fai attenzione al tuo tono quando fai queste domande. Se ti capita di essere il nuovo "tutto-in-uno", nessuno ascolterà più tardi le tue opinioni quando sarai davvero in grado di influenzare il modo in cui le cose vengono fatte.

Nel tempo, se il tuo codice è davvero "migliore", gli altri sviluppatori lo vedranno. Inizieranno a venire da te come una risorsa per aiutarli a sistemare i loro, e poi per chiedere il tuo consiglio su come dovrebbero fare le cose. A quel punto, sarai in un'ottima posizione per dire al team (e alla direzione) le tue opinioni sugli standard di codifica e simili. Quanto tempo impiegherà questo processo varia a seconda dell'organizzazione. Potrebbero essere solo alcune 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 accettarlo. Tutto ciò che puoi fare con il codice legacy è refactor e andare avanti a poco a poco. Alcune cose che non vuoi refactoring fino a quando non hai una maggiore comprensione del perché hanno fatto quello che hanno fatto. Inoltre, nessuno nel mondo degli affari ti pagherà per correggere il codice di lavoro, quindi dovresti presentare un caso aziendale per il motivo per cui ha bisogno di lavoro prima di aumentare e passare il tempo. È meglio aspettare il refactoring del codice quando c'è una modifica che è necessario apportare comunque. Potresti non aver scelto il metodo che hanno fatto per alcune cose, ma se funziona, fai molta attenzione a cambiarlo e introdurre nuovi bug. Soprattutto quando non ti è stato chiesto di cambiarlo.

Dopo una settimana, non hai alcuna credibilità per dare importanti suggerimenti su come fanno affari. Se fai emergere le cose adesso, le persone rideranno di te e non ti prenderanno mai sul serio. Mettiti alla prova con un buon codice prima e poi le persone saranno più inclini ad ascoltare.

E francamente a nessuno importa che tu sia un professionista certificato Microsoft. Chiunque abbia molta esperienza ha visto tanti cattivi programmatori che avevano quella certificazione come brave persone. 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 andrei sulla strada del tentativo 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 nel creare quella proposta:

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

Mentre posso apprezzare il desiderio di correggere la base di codice scadente, questo deve essere ponderato in modo che abbia senso dal punto di vista aziendale farlo.

Al momento non sei in grado di prevenire il codice errato, quindi dovrai capire come contenerlo.

Ai PM e ai team leader importa solo che non funzioni. La loro prossima preoccupazione sarà quando ti chiederanno di apportare modifiche e si chiederanno perché le cose "semplici" impiegano così tanto tempo. Ecco dove entrerai.

Inizia ora con il problema della coerenza. Qualunque sia il metodo potenzialmente standard attualmente, prova a identificarlo e vedi se non riesci a farlo applicare. Se inizi con la metodologia che nessun altro ha familiarità, avrai un sacco di respingimenti.

Altri membri del team potrebbero voler ottenere la certificazione e tu sarai una grande risorsa. Speriamo che almeno vogliano migliorare e guardarti per mostrar loro la strada.

Lamentarsi della notazione ungherese non ti procurerà simpatia ed è probabilmente una delle ultime battaglie nell'elenco delle priorità.

Sono d'accordo che devi essere cauto su questo. Devi creare reputazione all'interno del team prima di poter esprimere critiche e proporre profondi cambiamenti nel codice o nei processi. Vorrei solo prendere appunti sulle mie scoperte e suggerimenti per il momento, e cogliere le opportunità per fare conoscenza con i membri del team e la direzione, entrare in discussioni gratuite ma non rifiutare se il discorso si rivolge a problemi di qualità, domande di codifica ecc., A volte anche lanciando alcune mie domande nello stagno (ma in una forma generale, non troppo puntate su qualsiasi 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 della squadra (e / o della direzione) vede gli stessi problemi di te, solo che non c'è stata alcuna iniziativa per fare qualcosa al riguardo o nessuna risorsa concessa dalla direzione. Insieme, hai più voce in capitolo per convincere il management, se necessario.

Come suggerito da @Mike, è sicuramente necessario eseguire da soli alcune operazioni di pulizia, ma è meglio essere pazienti. Se inizi troppo in fretta, potresti alienare altri membri del team che potrebbero prenderlo come critica personale. Anche l'immissione in una vasta pulizia / refactoring del codice può essere presa dal tuo manager come un segno che non sei abbastanza concentrato sull'attività effettiva. Quindi dovresti ottenere un mandato per refactoring prima di intraprenderlo a un livello più serio. Tuttavia, piccole modifiche locali sono probabilmente OK.

Inoltre, per convincere il management, sono necessarie motivazioni aziendali. La gestione viene raramente spostata dalle descrizioni di quanto sia incoerente lo stile di codifica. Devi mostrare loro quale valore possono apportare all'azienda le modifiche proposte - la linea di fondo è il denaro. Se riesci a mettere insieme un calcolo convincente in merito al costo rispetto ai benefici a lungo termine di varie modifiche proposte e a dimostrare che il saldo complessivo è chiaramente sul lato positivo, hai notevolmente migliorato le tue possibilità.

Fallo da solo. Se apprezzi determinati stili di codifica, lavora sul codice che viola gli stili di codifica . Esegui il checkout di un codice offensivo dal controllo del codice sorgente, riformatta il codice in base ai requisiti degli spazi bianchi dello stile (come esempio) e impegna il codice aggiornato con il messaggio "Conformi alla regola della guida di stile sugli spazi bianchi".

Dopo una settimana la cosa peggiore che puoi probabilmente fare è andare direttamente al management con questo. Con ogni probabilità hanno dedicato molto tempo al codice e ne sono orgogliosi. Probabilmente verrai fuori come un serio "sapere tutto".

Cosa farei se fossi in te è migliorarlo man mano che procedi. Man mano che acquisisci familiarità con esso e mentre lavori su di esso, avrai la possibilità di migliorarlo. Sarebbe a quel punto che inizierei a mostrare i benefici di ciò che stai facendo ad altri colleghi. Dopodiché, quando le riunioni di progettazione propongono nuovi moduli, presenta una discussione su 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). Sarei più preoccupato se aprissi il codice e vedessi tonnellate di errori logici o qualcosa del genere.

Non andare direttamente alla direzione con questo "problema".

Innanzitutto, parla con i tuoi colleghi e scopri da loro perché le cose sono come sono. Quindi puoi fare una valutazione migliore se c'è un problema o meno. Potresti essere sorpreso da ciò che impari. Puoi anche trovare alleati nel volerlo ripulire.

Se non hai idea di come sei arrivato a dove sei in primo luogo, rende molto più difficile uscire.

Molti buoni suggerimenti qui già, e io sono del non-bruciare-i-tuoi-ponti-finché-non-hai-provato-te stesso-prima opinione come gli altri. Quello che aggiungerei è discutere bene con i tuoi compagni di squadra prima di alienarli andando al project manager o al team leader per primo. E certamente mostragli prima che dovresti essere preso sul serio.

Sembra anche che si tratti più di un problema stilistico con il codice. Assumere il codice di qualcun altro e trattenere il naso mentre si abitua al 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 affinché lo manipoli con le loro mani sporche è anche peggio ...

Se alla fine è più di questo - e il problema è più funzionale che solo stilistico - se vai al comando / pm della squadra, è meglio porsi la necessità di una rielaborazione in termini di dove risparmierebbe denaro e sforzi in futuro progetto di sviluppo. Buon vecchio refactoring.