Lavoro come sviluppatore iOS in una piccola società di outsourcing in un team di 4 persone. Lavoriamo su un progetto iniziato un paio d'anni prima che io e altri due sviluppatori entrassimo in azienda. Prima di allora, il progetto veniva svolto principalmente da una persona.

Quando ho iniziato a lavorare al progetto è stato un casino completo. C'è stata molta ripetizione del codice. Ho visto lo stesso 500 di codice copiato in 20 file diversi con variazioni minori. Inoltre, non era esattamente ben organizzato: tutto il codice di creazione dell'interfaccia utente era mescolato nei controller di visualizzazione insieme alla logica.

Ho fatto del mio meglio per refacturing cose qua e là, eliminare pezzi di codice ridondanti, migliorare la struttura dei file del progetto e così via. Sembrava che lo sviluppatore precedente non si occupasse davvero di tutte queste cose o non avesse avuto l'esperienza. C'è stato un tempo in cui ho lavorato da solo su un film piuttosto importante per un paio di mesi. A causa della natura di questa funzione, ho dovuto toccare molto codice nell'intera app, quindi ho cercato di apportare alcuni miglioramenti.

Quando altri sviluppatori si sono uniti al progetto, ho notato che usano uno stile di codifica diverso (a volte uno stile completamente diverso) e spesso non usano funzionalità di linguaggio moderno come gli accessor di proprietà (questo è relativamente nuovo in Objective-C). A volte inventano le loro biciclette invece di utilizzare funzioni simili del framework o trasferiscono concetti da altri linguaggi di programmazione o schemi che hanno imparato nella nostra base di codice. Spesso non riescono a nominare metodi o variabili correttamente a causa del cattivo inglese (Objective-C è una lingua in cui si creano nomi lunghi).

A volte penso che se non fosse per l'IDE penso che scriverebbero tutto il codice senza alcun rientro o formattazione.

Fondamentalmente, odio il codice che scrivono. È formattato / organizzato male e talvolta è radicalmente diverso dal resto del progetto. Mi sento molto arrabbiato quando aggiungono i loro spaghetti al mio pezzo d'arte e questo influenza il mio umore al lavoro e la mia produttività.

Sembra sempre più che non si possano preoccupare di imparare o di non preoccuparsene: fanno semplicemente ciò che è richiesto da loro e vanno a casa. Ho provato a dare loro alcuni consigli quando ne ho avuto l'opportunità (ad esempio, ho commentato il loro PR o si è impegnato su GitHub). Una volta ho chiesto gentilmente di seguire lo stile di codifica e la formattazione della maggior parte del codice esistente (purtroppo non abbiamo un documento formale di stile di codifica). Ma non ha funzionato ...

Come posso affrontare questa situazione senza concentrarmi solo sulla "cattiva cultura aziendale", "laureati inesperti", ecc. E iniziare effettivamente a migliorare la situazione.

Insegna e pratica ciò che predichi.

Sai che questa roba è importante. Conosci il rovescio della medaglia quando non è fatto bene.

Ora la sfida è convincere gli altri. Ciò non avverrà attraverso una singola conversazione, una riunione, conversazioni in corridoio, suggerimenti o all'interno di una richiesta pull.

Questo ha bisogno di:

• Il pubblico riconosce dalla direzione che questi elementi sono importanti
• Linters in modo che le persone possano stare insieme, fare hash e concordare lo stile e quindi lasciare che i computer facciano i controlli
• Sviluppa gli sviluppatori che acquistano completamente e sono disposti a insegnare agli altri
• Riunioni, dimostrazioni, pranzo e impara, ecc. Per insegnare questi approcci
• Persone che vengono misurate sugli articoli di qualità che menzioni durante le loro recensioni
• Standard documentati e pubblicati
• Richieste pull con molti revisori
• Pull Le richieste non vengono unite finché la qualità del codice non è elevata
• Abbinamento frequente del codice
• Revisioni del codice di gruppo per PR complesse

In parole richiede

Comando

La buona notizia è che tutte queste attività sono generalmente riconosciute come buone pratiche, quindi quando vai a promuoverle o ottenere buy-in dalla direzione dovresti avere buone probabilità di successo e dovresti essere in grado di difendere facendo la cosa giusta. Il management potrebbe comunque non acquistare, questo è un altro argomento e una domanda.

Ho scritto molto su questo argomento su SoftwareEngineering.SE in passato, e mi trovavo in situazioni simili. Pertanto, cercherò di dare alcuni suggerimenti ed evidenziare alcuni problemi che ho notato leggendo la tua domanda.

Ma prima, parliamo di un aspetto importante: il tuo ruolo nell'azienda.

Il tuo ruolo

Potresti avere un mandato esplicito dal tuo capo per migliorare le cose, e anche un posto nella gerarchia in cui altri sviluppatori devono ascoltare i tuoi ordini . Oppure potresti essere tra pari, avere lo stesso ruolo e la stessa autorità, la tua opzione è solo ... beh ... un'opinione .

In entrambi i casi, ciò che conta è meno posto nella gerarchia e altro:

• Cosa pensano gli altri sviluppatori di te. Se ti trattano come un ragazzo fastidioso che chiede loro cose stupide, non andrai lontano. Ho visto molti casi in cui i leader tecnici e i project manager non avevano assolutamente alcuna influenza sul team, perché il team sapeva (o pensava) che quei "leader" non avevano un background tecnico necessario per prendere le decisioni che stavano prendendo. D'altra parte, ho visto diversi sviluppatori che erano effettivamente ascoltati dai loro colleghi, perché sapevano che quegli sviluppatori erano abili ed esperti.

• Quanto è solida la tua squadra e cosa li motiva. Immagina un'azienda in cui ogni sviluppatore viene pagato per KLOC / mese. Qualcosa che dici sullo stile è importante per i tuoi colleghi? Probabilmente no, perché rare sono le persone che vogliono essere pagate di meno. In generale, se questa non è una squadra ma solo un gruppo di persone che lavorano allo stesso progetto, non sarai in grado di migliorare nulla.

A seconda di ciò, puoi decidere se valga la pena fare qualsiasi modifica. Se non hai voce e non c'è coesione di squadra, vai a cercare un altro lavoro. Se sei conosciuto come uno sviluppatore di talento, rispettato e c'è una forte sensazione di squadra, sarai in grado di migliorare le cose relativamente facilmente, anche se di fronte all'ostilità del tuo capo o di altri team.

In tutti i casi, è essenziale non fare pressione sulla tua squadra. Lavora con loro, non contro di loro. Non dare loro ordini, ma guidali verso l'obiettivo.

Ora, i suggerimenti.

Stile

Una volta ho chiesto gentilmente di seguire lo stile di codifica e la formattazione della maggior parte del codice esistente (purtroppo non abbiamo un documento formale di stile di codifica). Ma non ha funzionato ...

Certo che no, dal momento che non è così che dovrebbe essere fatto.

• Lo stile è noioso .

• Il seguente stile è noioso .

• Scrivere documenti in stile codice è noioso ( e dannatamente difficile ; non provare nemmeno a farlo a meno che tu non abbia lavorato con la lingua per più di dieci anni).

• La lettura del documento di stile è noiosa .

• Revisionare il codice per errori di stile è noioso .

• Trollare che il mio stile sia migliore del tuo è eccitante , specialmente quando non c'è assolutamente alcun vantaggio oggettivo di uno stile rispetto a un altro. Seriamente, ogni persona sana di mente sa che il modo giusto di scrivere if (x)è il modo in cui l'ho scritto, no if(x)o if ( x )!

Perciò:

• Non fare recensioni di stile. Questo è il lavoro dei controllori di stile. Quelle applicazioni carine hanno alcuni vantaggi sul tuo cervello: controllano l'intero progetto in pochi millisecondi, non ore o giorni, e non commettono errori e non perdono errori di stile.

• Non scrivere il tuo standard di stile. In ogni caso, sbaglierai e i tuoi colleghi ti trolleranno sul fatto che hai fatto delle cattive scelte.

• Non forzare gli sviluppatori a correggere 2000 errori di stile.

• Applica lo stile automaticamente su commit. Il codice che presenta errori di stile non ha spazio nel controllo della versione.

• Fallo dall'inizio del progetto. Impostare il controllo dello stile in un progetto esistente è difficile o impossibile.

Per ulteriori informazioni su questo, leggere la prima sezione di questa altra risposta su SE.SE .

Anche:

• Non essere troppo severo. Ad esempio, scrivere jslintcodice conforme è piuttosto fastidioso, quindi dovrebbe essere fatto esclusivamente quando assolutamente necessario (o se tutti i membri del team sono felici di usarlo). Lo stesso vale per gli strumenti di controllo statico; per esempio, l'analisi del codice di .NET al massimo livello potrebbe essere molto opprimente e deprimente, portando allo stesso tempo pochi vantaggi; lo stesso set di strumenti a livello moderato, d'altra parte, si rivela molto utile.

Revisioni del codice

Ora che non devi preoccuparti dello stile durante le revisioni del codice, puoi concentrarti su cose più interessanti: migliorare (anziché correggere) il codice sorgente.

Persone diverse reagiscono in modo diverso alle recensioni dei codici. Alcuni lo considerano un'opportunità. Altri lo odiano. Alcuni ascoltano tutto ciò che dici loro, prendono appunti e non discutono, anche se potrebbero avere ragione. Altri cercano di discutere su ogni punto. Sta a te trovare un modo per gestire ogni sviluppatore in base alla sua personalità. Di solito è utile:

• Esegui revisioni del codice in privato, specialmente quando lo sviluppatore è junior e scrive un codice davvero negativo.

• Mostra che non c'è nulla di personale: stai rivedendo il codice, non le abilità della persona.

• Mostra l'obiettivo effettivo di una revisione del codice. L'obiettivo non è mostrare quanto sia cattivo uno sviluppatore. L'obiettivo è fornire opportunità di miglioramento.

• Non discutere mai. Non sei qui per convincere, ma per fornire la tua esperienza.

• Non dare per scontato che il recensore sia l'unico che può imparare qualcosa da una recensione. Sei qui anche per imparare, sia leggendo il codice che chiedendo spiegazioni sulle parti che non capisci.

Una volta eseguita la revisione del codice, assicurati che la persona migliori effettivamente il suo codice. Ho avuto alcuni casi in cui gli sviluppatori hanno pensato che la revisione del codice termina al termine della riunione effettiva. Lasciano e tornano alle loro nuove funzionalità, cercando di applicare ciò che hai condiviso con loro solo per il nuovo codice. Avere uno strumento di tracciamento decente per la revisione del codice aiuta.

Nota che indipendentemente dal tuo ruolo particolare nell'azienda e dalla tua esperienza rispetto ad altri, anche il tuo codice dovrebbe essere soggetto a revisione. Non dovresti essere l'unico a rivedere il codice degli altri.

In un recente progetto in cui ho lavorato come capo tecnico, ho avuto difficoltà a spiegare ai miei colleghi che è il loro ruolo fare le revisioni del reciproco codice, incluso il mio. La paura di un tirocinante che sta per rivedere il codice del suo capo tecnico scompare non appena trova i primi problemi nel codice - e chi di noi scrive un codice perfetto?

Formazione

Le revisioni del codice sono un'ottima opportunità per insegnare e apprendere alcuni aspetti della programmazione e della progettazione del software, ma altri richiedono una formazione.

Se sei in grado di formare i tuoi colleghi, fallo. Se la tua gestione è ostile all'idea della formazione, fallo in modo informale. Ho tenuto queste sessioni di formazione in una forma di riunioni informali, o talvolta anche come semplici discussioni, a volte interrotte dalla direzione e perseguite in seguito.

Oltre all'addestramento diretto, assicurati di conoscere abbastanza bene i libri come McConnel's Code Complete e di parlare di quei libri ai tuoi colleghi. Consiglia loro di leggere il codice sorgente dei progetti open source, fornire loro esempi specifici di codice di alta qualità. E, ovviamente, scrivi tu stesso un codice di alta qualità.

Concentrati sul contesto, non sulle persone

Come posso affrontare questa situazione senza concentrarmi solo su "cattiva cultura aziendale", "laureati inesperti", ecc.

Quei laureati hanno un obiettivo: acquisire esperienza, imparare cose, diventare più abili. Se, anno dopo anno, scrivono codice scadente e non sanno nulla della programmazione, è probabilmente perché il tuo team o la tua azienda non sta offrendo loro questa opportunità.

Se ti stai concentrando sul fatto che il tuo team ha laureati inesperti, questo non ti aiuterà. Concentrati invece su cosa puoi fare per loro e con loro. Revisioni del codice e formazione sono due delle tecniche per migliorare la situazione.

La cattiva cultura aziendale è una bestia diversa. A volte, può essere cambiato. A volte, non può. In tutti i casi, ricordate che siete parte di questa società, in modo che siano parte della cultura aziendale. Se non riesci a cambiarlo e lo trovi intrinsecamente cattivo, prima o poi, dovrai andartene.

Ottieni le tue metriche giuste

Come misurate esattamente il codice in questo momento? Misuri il numero di commit al giorno per sviluppatore? O il KLOC al mese per programmatore? O forse la copertura del codice? O il numero di bug trovati e corretti? O il numero di potenziali bug rilevati dai test di regressione? O il numero di ripristini effettuati dal server di distribuzione continua?

Le cose che misuri contano, perché i membri del team stanno adattando il loro lavoro ai fattori misurati. Ad esempio, in un'azienda in cui dovevo lavorare qualche anno fa, l'unica cosa che veniva misurata era il tempo che si trascorre in ufficio. Inutile dire che questo non è stato incoraggiante per fornire codice migliore, o per lavorare in modo più intelligente, o ... beh, per funzionare affatto.

Capire il rinforzo positivo e negativo e regolare i fattori misurati nel tempo è essenzialmente la leva che hai sui membri del team. Se fatto correttamente, consente di ottenere risultati che non saranno raggiunti da una semplice gerarchia.

Le cose che ti danno fastidio, le rendono misurabili. Misurali e rendi pubblici i risultati. Quindi collaborare con altri membri del team per migliorare i risultati.

Ad esempio, consideriamo che i membri del team commettono troppi errori di ortografia nei nomi di classi, membri di classe e variabili. Questo è fastidioso. Come hai potuto misurarlo? Con un parser, puoi estrarre tutte le parole dal codice e, usando un correttore ortografico, determinare il rapporto tra parole contenenti errori e errori di battitura, diciamo 16,7%.

Il tuo prossimo passo è concordare con il tuo team il rapporto obiettivo. Potrebbe essere il 15% per il prossimo sprint, il 10% per il prossimo, il 5% in sei settimane e lo 0% in due mesi. Tali metriche vengono ricalcolate automaticamente ad ogni commit e visualizzate su un grande schermo in ufficio.

• Se non raggiungi il rapporto obiettivo, la tua squadra potrebbe decidere di dedicare più tempo alla correzione degli errori di ortografia. Oppure il tuo team potrebbe considerare meglio calcolare il rapporto per sviluppatore e visualizzare queste informazioni anche sul grande schermo. Oppure la tua squadra potrebbe scoprire che l'obiettivo era troppo ottimista e che dovresti rivederlo.

• Se raggiungi il rapporto target, il passo successivo è assicurarti che il numero di errori e errori di battitura non aumenti nel tempo. Per questo, puoi creare un'attività aggiuntiva nella tua build che controlla gli errori di ortografia e fallisce la build se viene trovato almeno un errore. Ora che ti sei sbarazzato di questo problema, il tuo grande schermo può essere riutilizzato per mostrare le nuove statistiche pertinenti.

Conclusione

Credo che ogni aspetto menzionato nella tua domanda possa essere risolto attraverso le tecniche che ho incluso nella mia risposta:

• Quando altri sviluppatori si sono uniti al progetto, ho notato che usano uno stile di codifica diverso (a volte uno stile completamente diverso)

  Devi imporre automaticamente lo stile su commit.

• e spesso non usano le funzionalità del linguaggio moderno come gli accessor di proprietà (questo è relativamente nuovo in Objective-C).

  Sia la revisione del codice che la formazione sono qui per trasferire la tua conoscenza della lingua.

• A volte inventano le loro biciclette invece di utilizzare caratteristiche simili del quadro

  Sia la revisione del codice che la formazione sono qui per trasferire la tua conoscenza del framework.

• o trasferire concetti da altri linguaggi di programmazione o schemi che hanno imparato nella nostra base di codice.

  Questa è un'ottima cosa Sembra un'opportunità per te di imparare da loro.

• Spesso non riescono a nominare metodi o variabili correttamente a causa del cattivo inglese

  Le revisioni del codice dovrebbero anche concentrarsi sulla denominazione corretta. Alcuni IDE dispongono anche di correttori ortografici.

• A volte penso che se non fosse per l'IDE penso che scriverebbero tutto il codice senza alcun rientro o formattazione.

  Certo che lo farebbero. Lo stile è noioso e dovrebbe essere automatizzato.

• Fondamentalmente, odio il codice che scrivono.

  Ricorda dalla parte delle recensioni del codice: “L'obiettivo non è mostrare quanto uno sviluppatore sia cattivo. L'obiettivo è fornire opportunità di miglioramento. "

• È formattato / organizzato male e talvolta è radicalmente diverso dal resto del progetto.

  Controllo automatico dello stile .

• Mi sento molto arrabbiato quando aggiungono i loro spaghetti al mio pezzo d'arte

  Aspetta cosa?! Pezzo d'arte?! Indovina un po? Alcune persone (incluso te tra sei mesi) potrebbero trovare il tuo codice lungi dall'essere un'opera d'arte. Nel frattempo, capisci che considerare il tuo lavoro come un'opera d'arte e il loro lavoro come una merda non aiuterà nessuno. Compreso te.

• Sembra sempre più che non si possano preoccupare di imparare o di non preoccuparsene: fanno semplicemente ciò che è richiesto da loro e vanno a casa.

  Naturalmente faranno ciò che è richiesto da loro. Ricorda: contesto, non persone e ottieni le metriche giuste . Se il contesto richiede da loro di diventare il migliore in quello che fanno, lo faranno. Se il contesto richiede di produrre il maggior numero possibile di KLOC al mese e niente di più, lo faranno anche loro.

Implementare gli standard di codifica e attenersi a questi, modelli di progettazione, libreria di frammenti di codice che è possibile utilizzare come linee guida, ecc.

Gli standard di codifica possono variare dal decidere se usare spazi o tab, quali schemi di progettazione provare e usare, convenzioni di denominazione, ecc. Ciò andrà ben oltre anche se tutti codificano diversamente.

Se possibile, implementa gli standard di codifica e le revisioni del codice - per iniziare la revisione ogni singolo check-in. Con un piccolo team sarà una vendita difficile per le persone che non capiscono che spendere un extra di 2x o 3x sul tuo codice in anticipo ti farà risparmiare 20x o 30x sul tempo di sviluppo complessivo, ma questo è un altro concetto che vale la pena comprare -in on.

Non proverei a implementare tutto in una volta, e farei del mio meglio per convincerli a elaborare anche degli standard - non solo il rientro, ma proverei a farli pensare a cose che hanno incontrato nel loro codice che hanno ha reso le loro vite più facili o più difficili.

Considera di avere un incontro un giorno alla settimana per le recensioni su ciò che è andato bene o male per ogni persona durante quella settimana - potresti anche offrire a ogni persona la possibilità di dire ciò che qualcun altro ha fatto di più utile quella settimana - cose del genere . Potresti guardare libri XP / Agile per altre idee come questa. Essere una piccola squadra, di nuovo, potrebbe essere una vendita difficile.

Hai menzionato problemi di lingua. Se questi lavoratori sono locali (o appaltatori in loco o assunzioni a tempo pieno), ciò non dovrebbe costituire un problema eccessivo, ma se sono appaltatori d'oltremare che lavorano in remoto, lasciatemi dire che nella mia esperienza personale questo non è mai sarà risolto, o cavalcalo fino a quando la direzione non capirà che non funzionerà o prenderà in considerazione la possibilità di lasciare l'azienda. Non entrare in una situazione in cui sei responsabile del loro lavoro e non perdere tempo a cercare di correggere le pratiche di sviluppo del team. Molto probabilmente il tuo lavoro si evolverà nel passare il 100% del tuo tempo a far funzionare il loro codice. Molti appaltatori d'oltremare sono grandi programmatori, a proposito, mi riferisco solo al caso in cui la società appaltante ti ha inviato il tipo di talento che hai descritto.

I sintomi che descrivi suggeriscono fortemente una mancanza di coesione di squadra .

In tale situazione, gli standard di codifica, la formazione, le procedure o gli strumenti non saranno il proiettile d'argento che potrebbe migliorare sostanzialmente la qualità. Devi prima sviluppare uno spirito di squadra, una comunicazione aperta e costruttiva e una proprietà condivisa del prodotto.

Sintomi :

• "fanno solo ciò che è richiesto e vanno a casa": suono sono demotivati. Non erano più entusiasti quando arrivarono?
• "loro" contro "noi" / "io" / "io": mancanza di fiducia reciproca?
• "Ho dato alcuni consigli: ho commentato PR su Git": il tono della critica scritta è talvolta interpretato erroneamente come aggressivo o arrogante nonostante l'intenzione costruttiva. Perché non discuterne faccia a faccia?

Sei una piccola squadra: usa questo vantaggio! Alcune idee per iniziare:

• Prendi decisioni importanti collettivamente. Discutere apertamente di disaccordo. "Discutere" non è imporre un punto di vista, ma ascoltare e cercare di trovare un terreno comune.
• Hai eseguito il refactoring di parti importanti del codice, quindi hai una proprietà davvero forte. Lasciali comprare. Lascia che abbiano una parola da dire.
• E per argomenti molto delicati ma altamente soggettivi come la formattazione del codice, affidate in outsourcing il dovere a una graziosa stampante automatizzata che si riformatterà secondo gli standard e senza sentirsi ad ogni check-in.

Citazione del giorno:

Se vuoi andare veloce, vai da solo. Se vuoi andare lontano, vai insieme

Puoi rispondere alla tua domanda "Cambia la tua azienda o cambia la tua azienda". Per coloro che non lo sanno, questo significa che rimani e combatti per portare il cambiamento che vuoi vedere nella tua azienda, o cambiare la compagnia per cui lavori (es. Lasciare e lavorare in un altro posto).

La seconda parte è la più semplice. Lascia e trovi un'azienda che condivide gli stessi valori con cui lavori. Il primo non è così semplice a causa di ... persone.

Quello che devi fare è cambiare le persone. Pensare che siano rotti e che tu debba ripararli non funzionerà. Le persone sono esseri emotivi. Questo può facilmente degenerare nelle guerre personali. Così...

Prima di tutto, devi scoprire perché la situazione è così. Parla con tutti. Scoprire. Quello che vedi ora è il risultato di decisioni prese nel corso degli anni (o forse non prendere alcune decisioni importanti al momento giusto). Non giudicare e non saltare alle conclusioni.

Ciò è stato causato da sviluppatori inesperti? È stato causato dal management che ha cercato di ridurre i costi assumendo laureati economici anziché sviluppatori più esperti e costosi? Si tratta di persone pigre e mal intenzionate o persone sconfitte da un sistema rotto? Le scadenze ti costringono a fare "ciò che deve essere fatto" per farlo funzionare o la gente semplicemente perde tempo e non si preoccupa troppo di ciò su cui sta lavorando? eccetera.

Il problema con questo campo di sviluppo software è che le persone imparano sul posto di lavoro. Se lavorano in un ambiente schifoso, prenderanno cattive abitudini. E le abitudini tendono ad attaccarsi ed essere difficili da scuotere. Quindi non sanno meglio perché è tutto ciò che sanno. Non tutti gli sviluppatori sono appassionati di ciò che fanno per investire tempo nel miglioramento o nella ricerca del miglioramento. Alcuni sono entrati in questo business per vari altri motivi. Quindi scopri perché le persone sono come sono.

Poi c'è la gestione. Il management non è consapevole della situazione o semplicemente non gliene importa? Scoprire. Devi assolutamente avere il supporto della direzione se vuoi migliorare le cose. Se qualcosa che impiega 3 mesi per costruire all'improvviso inizia a richiedere 4 mesi perché ora devi scrivere test, fare revisioni del codice, discutere alla lavagna con il team per decidere su buone soluzioni, accoppiare il programma, ecc., Puoi essere certo che la direzione noterà la differenza di orario. Qualcosa che cambia da 3 a 4 mesi è facile da osservare e misurare. Avere una solida base di codice, un prodotto gestibile, una buona architettura stabile, elementi che rendono migliore una struttura del prodotto non è così facile da misurare. Quanto tempo le migliori pratiche ti acquistano a lungo termine non possono essere misurate in anticipo, forse nemmeno dopo il fatto. D'altro canto, un ritardo di un mese è un gioco da ragazzi. Quindi avere il supporto gestionale su questo. Preparati a fare una vendita difficile.

Guarda anche il contesto del business. Questo sta influenzando il tuo modo di lavorare? Hai opportunità da seguire a tutti i costi, incluso il sacrificio della qualità del codice o delle migliori pratiche?

Cambiamo prospettiva per un momento.

Mi sento molto arrabbiato quando aggiungono i loro spaghetti al mio pezzo d'arte e questo influenza il mio umore al lavoro e la mia produttività.

Scusa ... tu cosa? Arte? So che la maggior parte di noi è qui per il riconoscimento dei nostri colleghi e lo ottieni solo se sei un buon sviluppatore, ma il tuo codice viene visualizzato in un museo accanto a un dipinto? Deve provocare emozioni nelle persone che lo guardano? Lacrime di gioia e felicità? Sì, sono sarcastico e sto deliberatamente esagerando perché voglio dire di mantenere il senso della realtà. Non attaccarti emotivamente al tuo codice.

Lavoravo con un ragazzo che gettava felicemente la squadra, il progetto e la compagnia sotto l'autobus solo per imporre la sua "arte" a tutti. Era il "detentore della verità" e, per definizione, tutti erano semplicemente inesperti, ciechi, non disposti a imparare, non gli importava, o semplicemente stupidi. Non diventare quel ragazzo. Come sviluppatore di software, il tuo compito è quello di scrivere un buon codice, un codice testato, un codice gestibile, un codice che aggiunga valore commerciale e che possa continuare a farlo in continui cambiamenti futuri. E devi fare tutto ciò con limiti di budget e di tempo. Questo è ciò che significa essere uno sviluppatore di software professionale. A meno che tu non sia una galleria d'arte, l'arte fa male agli affari. Sii pragmatico e mantieni una visione equilibrata delle cose. " Come ignorare il cattivo codice che i miei colleghi scrivono e concentrarsi solo sul lavoro"ha chiuso la tua domanda a causa del modo in cui hai inquadrato il problema. Fai un passo indietro e guarda tutto.

Come posso affrontare questa situazione senza concentrarmi solo sulla "cattiva cultura aziendale", "laureati inesperti", ecc. E iniziare effettivamente a migliorare la situazione.

TL; DR: osserva attentamente la situazione per scoprire perché le cose sono finite in quella situazione. Accetta che la situazione sia così e vedi come puoi migliorare da lì. Scopri qual è l'opinione di tutti su questo. Scegli le tue battaglie. Forzare il cambiamento non funziona. Collabora per apportare le modifiche. Dovresti provare a mostrare come le cose possono essere migliorate, non sottolineare quanto siano brutte. Convinci tutti che quello che vuoi fare è per il bene più grande a lungo termine. Falli salire a bordo.

E fallo a piccoli passi.

Se porti troppi cambiamenti tutto in una volta, le persone si sentiranno scoraggiate e si arrenderanno. Le modifiche richiedono tempo. Cambia la tua azienda o cambia la tua azienda. In bocca al lupo!