tl;dr

Questo non è un problema tecnico, è un problema di persone. Trattalo come tale.

Non sto cambiando nulla!

Sei partito davvero male e non ha nulla a che fare con il codice.

Sembra che le tue capacità personali siano carenti. Non inizi a caricarti per un nuovo lavoro dicendo al team attuale quanto sono pessimi.

Alla gente non piace il cambiamento. E a loro davvero non piace dal "nuovo ragazzo".

Voglio iniziare dal livello basso (ad esempio "questo pezzo di codice è lento / sbagliato / inefficace ") e poi passare lentamente al livello alto (es. iterazioni contro cascata). Ma temo che penserebbero che li sto attaccando, il che non è il caso.

Non sono sicuro della cultura in cui vivi ma di dire a qualcuno "questo codice è sbagliato, io sto meglio e dovresti farlo in questo modo "sarà sempre un attacco.

Cosa fare?

1. Smetti di pensare" io contro loro ". A meno che tu non abbia intenzione di smettere, fai parte di questa squadra. Non sono quei "terribili sviluppatori" contro "me la superstar" e se lo comunichi alla tua squadra, avrai problemi. Nessuno rispetterà mai le tue idee. Non importa se il team lavora come individui. È ancora un team e lo descrivi anche come tale.
2. Scopri se le aspettative vengono soddisfatte. Il team soddisfa le aspettative / i desideri del manager? Se è così, non troverai molte motivazioni da parte di nessuno per migliorare. "Se non è rotto non aggiustarlo." Ma se la squadra sta lottando per raggiungere gli obiettivi di prestazione, allora hai un modo diverso di affrontarlo e puoi presentare tutto come, "hey, non stiamo rispettando le scadenze, ragazzi volete provare a cambiare questo? aiutaci a farlo. "
3. Non sei il manager, lo è il tuo capo. Sembra che tu voglia gestire l'intero processo da solo. Funziona benissimo - per manager / responsabili di team. Ottenere il contributo del tuo capo è importante.
4. Le persone si preoccupano più dei risultati che dei sentimenti confusi. Il tuo manager si preoccuperà molto di più del tuo punto di vista se dimostri effettivamente perché quello che dici è migliore dello stato attuale. Non solo "perché Internet l'ha detto!" ma in realtà dimostrando.
5. Chiedi aiuto alle persone. Trova modi per creare fiducia nel team. Chiedere aiuto / guida è un modo semplicissimo per farlo. Anche se è minore, fallo con la tua squadra. Ti rispetteranno molto di più se dimostri di ascoltare le loro opinioni.
6. Dai il buon esempio. Le persone che non vogliono cambiare normalmente non accettano nuove informazioni e vai "sai che hai ragione Non ho mai considerato una volta che il modo in cui stavo facendo fosse inferiore, ora sono illuminato e cambierò i miei modi." Le persone cambiano cambiando piccole cose, lentamente, in modo sostenuto. Puoi dimostrarlo.
7. Scegli le tue battaglie con saggezza. Il tuo esempio suona come il tuo problema fondamentale è che la squadra ha persone che sono pessime nel loro lavoro. È davvero così cattivo se il codice è inefficiente? Sta effettivamente influenzando le prestazioni finali? Oppure concentrare il prossimo progetto su iterazioni e questioni a cascata (nota che se ti concentri su cose agili e a cascata, sicuramente farai meglio a coinvolgere il tuo capo).

Questo non è l'approccio giusto. Tutto quello che farai è alienare i tuoi colleghi. Quanto ti piacerebbe se qualcuno si assumesse la responsabilità di analizzare tutti i tuoi errori?

La soluzione migliore è lavorare con il tuo manager o supervisore, e il modo in cui lo fai è importante. Invece di sottolineare tutte le cose che i tuoi colleghi stanno facendo in modo errato, dovresti preparare con attenzione un elenco di modi in cui pensi che i tuoi processi potrebbero essere migliorati e come la tua azienda potrebbe trarne vantaggio. In altre parole, non attaccare le persone: fai notare cosa non funziona nei tuoi processi e in che modo il team potrebbe migliorare se queste cose fossero risolte.

Se il manager vede e comprende il valore dietro ciò che tu sta dicendo, è probabile che agisca; forse non è l'azione esatta che desideri, ma è probabile che le cose migliorino. In caso contrario, puoi continuare a provare a guidare ispirandoti e si spera che le cose migliorino da sole. Tuttavia, se vuoi preservare qualsiasi tipo di rapporto di lavoro con i tuoi colleghi, non cercare di dire loro come lavorare se il modo in cui funzionano non è una tua responsabilità.

In passato ho cercato di attenermi ai seguenti principi e mi è sembrato che funzionasse bene:

• Mi sono sforzato di iniziare con un "periodo di apprendimento tranquillo": Per un periodo di alcuni mesi,

  Stai zitto e impara. Non giudicare nulla. Integrati nel team e nell'azienda. Sii produttivo. Costruisci fiducia e reputazione. Mostra la tua competenza.

  (Immagino che tu abbia già provato anche una versione simile.) Spesso vedi cose che pensi siano negative ma poche settimane dopo impari perché sono come sono.

• Se noti problemi o affronti cose che ritieni non ottimali,

  Raccogli dati: ore trascorse su un semplice cambiamenti, bug che compaiono, messaggi di posta arrabbiati inviati in giro, ecc.

  Qualsiasi cambiamento che intendi suggerire necessita di fatti per dimostrare che è necessario e utile. Mi piace prendere appunti nel mio "diario" personale (uno di questi bei vecchi libri bianchi fatti di vera carta).

  In uno dei miei progetti ho avuto la sensazione che fare un cambiamento fosse particolarmente costoso perché non c'erano test automatizzati e il test manuale era molto combinato. Quindi ho tracciato le ore che ho dedicato a ciascuna attività, tenendo le ore per l'implementazione effettiva separate dalle ore di test.

• Dopo un po 'le tue osservazioni (o note) ti aiuteranno

  Ottieni un'immagine chiara di quali sono i problemi principali. Individuali (solo!)

  Non riesco a immaginare che tu possa farlo "dal basso verso l'alto" come hai detto. È piuttosto dall'alto verso il basso: emerge un problema e cerchi di trovarne la causa principale.

• Risolvi solo un problema alla volta. Utilizza i dati che hai a portata di mano e prova a

  Elaborare un suggerimento per migliorare questo problema,

  che mostra il problema e la potenziale vittoria utilizzando i tuoi dati. Usa un buon momento e scegli il modo meno offensivo. Inoltre, prova a suggerire un cambiamento il più piccolo possibile con il maggiore impatto positivo. È molto più probabile che piccoli cambiamenti vengano accettati / approvati dal team rispetto a quelli più grandi.

• Non puntare mai il dito. Renditi un prezioso amico di ogni tuo team.

  Anche tu commetti degli errori, comunque. E immagino che, il più delle volte, le cose brutte che incontri non siano state "create" da un "cattivo ragazzo". Si sono evoluti perché non ci si è presi abbastanza cura di impedirlo. È sempre un buon consiglio non incolpare le persone per un problema, ma affrontare i processi, il modo in cui il team lavora insieme, ecc.

Sicuramente non inizierei a un livello basso - "questo codice è inefficiente" o simili. Questo causerà solo molta difesa per un guadagno minimo.

Mescolare e abbinare un progetto agile e un progetto a cascata è incredibilmente difficile. Le persone a cascata vogliono stabilire l'interfaccia tra i tuoi progetti (formato di file, layout di tabella, api, qualunque cosa) in anticipo, quindi se ne vanno e scrivono su quell'interfaccia. Vuoi solo iniziare con l'interfaccia più semplice possibile, i pezzi che sai per certo di aver bisogno, e poi venire da loro dicendo che devi aggiungere o modificare qualcosa e farli reagire. Per te, questo è responsabile, agile e veloce, perché non hai passato un'eternità a discutere di design in un momento in cui non potresti conoscere le risposte. Per loro, questo è un cowboy, che li fa sobbalzare, cambiando costantemente il terreno sotto di loro. È una ricetta per il disastro.

Ti suggerisco di far emergere questa difficoltà alla prossima persona con cui devi lavorare. Discutilo e decidi insieme se progetterai completamente la tua sovrapposizione / interazione prima o inizierai semplicemente e sii pronto a cambiarlo mentre procedi. Davvero ascolta la resistenza che ricevi dall'altro sviluppatore. Non si sbagliano automaticamente. L'agilità è eccezionale quando possiedi tutti i tuoi limiti, ma può causare lavoro extra quando non lo fai. In alcuni progetti, quel lavoro extra è ancora inferiore ai giorni o alle settimane di speculazioni e discussioni che hanno portato alla creazione di un design non ottimale a cui sei rimasto bloccato. Ma non su tutti i progetti. In questo caso, potrebbe avere senso progettare completamente il confine tra te e l'altro sviluppatore prima che qualcuno inizi. Quindi vai avanti e sii agile all'interno del tuo silo.

Per il problema più ampio, che pensi che (a) scrivano codice scadente, (b) dovrebbero essere agili come te, (c) dovrebbero usare una base di strumenti coerente e moderna e (d) dovrebbero fare più test e altro condivisione del codice tra i progetti: procedi con molta attenzione qui. Hai provato a essere bravo e vedere se vogliono copiarti, e non lo fanno. Non è del tutto chiaro per me che tu veda i vantaggi per loro di rimanere nel modo in cui sono stati. Non li convincerai mai a cambiare i loro modi senza capire perché (al di là dell'inerzia) non lo fanno. Probabilmente avrai anche bisogno del supporto esplicito del tuo manager per guidare una guida "best practice" che cambia drasticamente il codice esistente e insegna a questi sviluppatori come farlo da ora in poi. Farlo da solo? Continueranno a spazzarti via perché non hanno tempo per questo, hanno un codice da elaborare.

Benvenuto nel mondo degli affari.

Il cambiamento richiede tempo. In una grande azienda possono volerci decenni se quello che hanno funziona abbastanza bene (e in effetti potrebbe essere stato leader del settore anni fa, quando hanno adottato tali pratiche). Lavorando per IBM, sto ancora utilizzando alcuni strumenti i cui back-end risalgono all'era del "green screen", perché FANNO funzionano, sono fortemente integrati con altri strumenti (e quindi difficili da sostituire individualmente ) e poiché nessuno ha trovato fondi e tempo sufficienti per investire nel passaggio in un modo che non comporti rischi inaccettabili.

Problemi simili si applicano anche a livello di pratica aziendale. Cambiare gli strumenti comporta dei rischi ... o il rischio di sottovalutare il costo e di non rispettare i propri impegni, oppure il rischio di sovrastimarlo e sembrare che non fossi abbastanza aggressivo. La direzione vuole essere in grado di fare previsioni, quindi potrebbe avere paura di impegnarsi in entrambi i modi e di restare fedele a ciò che ha.

Il cambiamento può arrivare, ma deve iniziare piccolo ed essere costruito esternamente. Inizi dando un esempio di come il nuovo approccio ti aiuti, per un periodo prolungato. Alla fine hai prove sufficienti per convincere un team leader a provarlo in un piccolo gruppo (o diventi un team leader che può farlo), in un modo che non influisce negativamente sul resto dell'azienda. Costruisci verso l'esterno da lì. Aspettatevi che il cambiamento richieda tempo; le corazzate non si avviano, non si fermano né girano molto rapidamente.

Idem sulla qualità del codice e sulle pratiche di codifica. Ricorda che la coerenza (essere in grado di leggere e mantenere il codice dell'altro) ha la meglio e impara a lavorare con lo stile di codifica che preferiscono. (Un buon programmatore può leggere quasi tutti gli stili, sebbene il tizio che pensava che i punti e virgola appartenessero all'inizio delle dichiarazioni potrebbe essere stato un'eccezione.) Ricorda che se stai mantenendo il codice del prodotto esistente, devi ridurre al minimo il rischio di introdurre nuovi bug, il che significa che le patch locali sono preferite a meno che tu non possa dimostrare forti ragioni per cui quelle più grandi saranno più facili da creare, più facili da mantenere e avranno vantaggi per i clienti. Per metterlo in prospettiva, ricorda che molti clienti eseguono codice vecchio di anni piuttosto che l'ultima versione e aggiornano solo quando è assolutamente necessario, proprio perché non sono disposti a rischiare che un nuovo bug metta giù la loro attività.

E, sì, patch minime si sommano a codice brutto. Alla fine questo viene risolto, ma non prima della prossima versione principale e non a meno che non ci sia un vero problema con il vecchio codice.

Quando si presenta l'opportunità di implementare qualcosa di nuovo, POI puoi considerare di spingere per i vantaggi di un nuovo approccio. Ma la manutenzione, per definizione, è legata ai vecchi processi e cambia molto lentamente. Sfortunatamente, l'adozione delle migliori pratiche accademiche richiede molto tempo ... e spesso, nel momento in cui lo sono, qualcos'altro è il nuovo più recente e più grande.

Prendi un piccolo cambiamento alla volta , fino a quando / a meno che tu non sia in grado di implementare cambiamenti più grandi. Mostra, non limitarti a dire. Sii paziente e tenace. Ricorda che le cose sono come stanno perché FUNZIONANO e impara a far funzionare il sistema attuale abbastanza bene da poter spiegare esattamente quali sarebbero sia i vantaggi che i rischi del passaggio.

Oppure fai la cosa ad alto rischio di avviare la tua azienda e fare le cose a modo tuo ... che ti insegnerà rapidamente perché tutti sono così nervosi per i rischi che non sanno ancora quantificare; arriverà qualche giovane punk con l'approccio alla moda di questa settimana e dovrai spiegargli che la compagnia deve aspettare un'opportunità pulita per tagliare ... e nel frattempo hai bisogno che lui lavori su ciò che hai ora e se non può farlo non ha futuro con l'azienda.

Finora buone risposte, specialmente da Roger, enderland ♦ e Kate Gregory, ma mi piacerebbe aggiungerle.

TLDR

Inizia con il livello alto metodologie perché risulteranno in una qualità superiore della parte di basso livello. Fai in modo che il tuo manager e i tuoi colleghi capiscano cosa trarranno dall'aggiunta di metodologie di alto livello, fai in modo che desiderino che cambi , l'unico modo per far cambiare la loro cultura è farli desiderare per cambiare .

Risposta originale

Suggerisco che invece di iniziare a criticare il codice inefficiente dei tuoi datori di lavoro di iniziare lentamente, collaborando con il tuo manager, con nuove metodologie , uno per uno, dove il guadagno di ogni passo viene spiegato in dettaglio. Una cultura aziendale può cambiare solo se i datori di lavoro vogliono che cambi , capendo perché dovrebbe cambiare , finendo con loro volendo che cambi .

Ordine suggerito delle metodologie:

Standup - Avvio molto lento

Inizia con stand-up. Se riesci a far capire al tuo manager e ai tuoi dipendenti che la migrazione delle informazioni su cosa viene fatto e da chi e in quale progetto la tua azienda è meno rischia di essere fregato se qualcuno improvvisamente non è in grado di continuare il suo lavoro, rendendolo un rompicoglioni per il prossimo datore di lavoro che deve riprendere il suo lavoro. Se i tuoi colleghi pensano che sarà più facile per loro assumere il lavoro di qualcun altro migrando le informazioni impiegando solo cinque minuti al giorno per farlo, allora è un potenziale inizio.

TDD - Stanno ancora in grado di fare le proprie cose, ma in un modo più strutturato

Penso che sia un buon passo successivo. È difficile e quasi inutile fare unit test sul codice legacy (in realtà, la definizione, secondo alcuni esperti, di un codice legacy è una base di codice che non ne ha o pochi unit test), ma la scrittura di unit test per nuovi metodi garantisce che i nuovi metodi faranno effettivamente ciò che ci si aspetta da loro - con il risultato di meno bug a cui gli sviluppatori devono pensare, meno spese per l'azienda (il tuo manager dovrebbe essere trovato di quello), e modella il flusso dei sistemi invece del contrario. Leggi lo sviluppo guidato dai test (TDD) e scopri come TDD renderà più facile la vita dei tuoi colleghi e finiranno per farlo, soprattutto perché possono fallo da soli e non devi interagire con nessun altro che lo faccia. La parte più importante è che uno unit test può essere scritto in pochi secondi o minuti, se fatto in precedenza, rendendolo non così noioso, e in realtà inefficiente e inutile com'è, se viene scritto in seguito.

Inventa il concetto di SOA: sbarazzarsi di sistemi strettamente accoppiati

L'architettura orientata ai servizi (SOA) garantirà un accoppiamento debole architettura che consente di sostituire e mantenere i moduli facilmente, da chiunque, senza richiedere alcuna conoscenza delle altre parti dei sistemi. Chiedi ai tuoi colleghi se sono disposti a mantenere i sistemi super strettamente collegati di qualcun altro dopo cinque anni di sviluppo e manutenzione e chiedi loro se sono più interessati a dover comprendere ogni singolo concetto nel sistema o se preferiscono farlo solo dover capire sottoinsiemi molto piccoli del sistema, anche permettendo loro di riscrivere quella parte molto specifica da zero se lo desiderano, perché è possibile solo con un'architettura super orientata agli oggetti o SOA.

Revisione del codice: migrazione della conoscenza senza dover interagire troppo con gli altri

Puoi chiedere ai tuoi colleghi se desiderano essere più preziosi. Avere conoscenza nei vari sistemi che ci sono li rende più preziosi. Migra il rischio che piacerà molto al tuo datore di lavoro e offre ai tuoi colleghi un grande vantaggio se uno di loro non è in grado di continuare il suo lavoro. 15 minuti al giorno cambierebbero molto, e permetteresti a loro di evidenziare i difetti degli altri, senza farti sembrare il cattivo , a meno che non sia il tuo turno da rivedere, allora va bene perché beh, avresti dovuto rivedere il codice.

La lista continua

Il punto è iniziare con -le cose di livello; finirà in una qualità superiore delle cose di livello inferiore.

Le cose che ho detto di ogni cosa probabilmente non convinceranno tutti, ma la chiave è far sì che i tuoi colleghi vogliano cambiare, altrimenti non lo faranno . Lascia che capiscano perché dovrebbero cambiare trovando le parti accattivanti delle metodologie di alto livello e le cose miglioreranno.

Hai elencato tre problemi. La maggior parte di esse sembrano best practice accettabili (non c'è niente di sbagliato in questo), ma ce n'è una su cui penso dovresti concentrarti, perché potrebbe essere il problema principale come lo vedranno tutti in azienda, "Il processo di sviluppo complessivo è lento ... "Dai anche il motivo, inefficiente.

La parola "agile" viene lanciata, ma come tutto questo, è relativa. Dovresti concentrarti su alcuni problemi reali che tutti stanno avendo. Quanto tempo ci vuole per le richieste di modifica? Le modifiche sono incomplete, ad es. "La nuova correzione è stata visualizzata nella Sezione A ma non nella Sezione B. Perché no?" Queste sono le cose che interessano agli utenti. Otterrai più buy-in dal resto dell'azienda se i risultati delle modifiche suggerite ne trarranno vantaggio. Ovviamente, essere in grado di implementare le cose più velocemente può essere migliore per tutti.

Hai menzionato il codice duplicato. È un no-no tra i programmatori, ma per progetti più grandi e specialmente quelli con molto codice legacy, il refactoring non sarà facile. Sembra fantastico in teoria, finché non scopri che nessuno concederà alla squadra il tempo per farlo a scapito delle richieste attuali. Argomentare contro il debito tecnico non è facile.

Come compito iniziale, cerca di riunire il team e discutere lo sviluppo di standard di codifica. Sei la nuova persona, quindi l'hai riconosciuto subito. Guarda qual è la reazione di tutti. Potresti ricevere un respingimento perché non possono essere d'accordo o "abbiamo provato ma nessuno ha rispettato". Forse il pasticcio attuale è una motivazione sufficiente per convincere tutti a voler fare qualcosa al riguardo. Di nuovo, potresti non avere il tempo.

Se vedi che questo gruppo ha difficoltà ad andare d'accordo, inizia con qualcosa di semplice; andate a pranzo insieme. In queste situazioni informali, potresti scoprire quali sono i veri problemi. Potrebbe essere la mancanza di conoscenza o forse l'ambiente creato in questa azienda è più preoccupato di spegnere gli incendi quotidiani.

Non arrenderti, ma non aspettarti nemmeno che cambi dall'oggi al domani. Hai un compito importante davanti a te, amico mio.

A meno che non sia compito tuo cambiare le loro pratiche lavorative E non lo hai scritto per iscritto, non farlo, perché come altri hanno detto, non funzionerà.

La persona che dovrebbe farlo è il tuo manager. È il ragazzo che devi persuadere. Prova un appello pragmatico all'efficienza, con esempi.

Se non è interessato? Impara a conviverci (e assicurati che il tuo culo sia coperto) o trova un altro lavoro. È orribile, lo so. Ci sono stato.

(Forse non si tratta di persone, ma di politica - o qualcuno li avrebbe colti in queste pratiche molto tempo fa.)

Sembra che tu sappia davvero cosa stai facendo, ma fai attenzione a non partire con il piede sbagliato con i tuoi nuovi colleghi. Se sei così bravo, dovresti essere in grado di dare un contributo positivo ai depositi di ogni persona. È probabile che i programmatori migliori non si preoccupino di migliorare il loro codice, quindi se puoi lavorare con loro, fallo. Quelli che rifiutano i tuoi miglioramenti probabilmente non sono i tipi con cui vuoi lavorare.

Ma un avvertimento: sii assolutamente certo che i tuoi contributi non abbiano compromessi negativi. Se ci sono degli svantaggi nei tuoi suggerimenti, sarai ritenuto responsabile se le cose vanno male.

Il mio standard personale è che insisto sul fatto che qualsiasi modifica che apporto al codice sviluppato da altri, dove non sto architettando le cose, non ha assolutamente svantaggi (o se esistono potenzialmente intangibili, cioè "è di più leggibile? ", che sono minimi.) Usando questo come mio standard, sono ancora in grado di:

• refactoring del codice, scrivere e migliorare unittest, sollevare eccezioni più specifiche
• correggi gli errori creati a causa dell'utilizzo di codice deprecato e sostituisci le strutture che vengono eliminate gradualmente con i nuovi costrutti
• riduci le righe di codice utilizzando funzioni e metodi incorporati che coprono il caso d'uso, migliora l'efficienza del codice eliminando la materializzazione delle strutture dati dove non è necessario e sostituendo il flusso di controllo imbarazzante con un flusso di controllo più snello
• migliorare le docstrings / la documentazione (dall'ortografia alla semantica) e apportare miglioramenti allo stile del codice (poiché abbiamo una guida allo stile! )

E faccio tutto quanto sopra senza modificare gli input e gli output di avviare codice ished, quindi nulla nella produzione si interrompe.

In questo modo, puoi costruire una reputazione per sapere cosa stai facendo. Mentre lo fai, creerai credibilità presso i knowledge worker con cui lavori. Se sei in grado di sostituire componenti goffi o cattivi con altri migliori, ti apprezzeranno ancora di più. Costruendo la tua credibilità, svilupperai la tua capacità di persuaderli ad adottare le pratiche che ritieni avranno forti risultati.

Mi sono trovato in una situazione simile due volte e ho scoperto come molti altri che non c'è assolutamente modo di migliorare le cose a meno che i tuoi colleghi non vogliano cambiare.

C'è un modo semplice per verificare se o non sono disposti, suggerire al team di andare a una conferenza o seguire un corso sugli argomenti di programmazione pertinenti. Potrebbero anche esserci gruppi di utenti o anche gruppi di interesse generale di programmazione che hanno riunioni aperte ogni tanto che il tuo team potrebbe visitare. materiale di lettura o video che le persone possono guardare (i video di zio Bob funzionano meravigliosamente in questa situazione).

Con questo non devi sottolineare alcun problema o errore che pensi stiano facendo, il La risposta del team a questi suggerimenti ti dirà tutto ciò che devi sapere su quanto siano interessati a migliorare le cose. Se sono entusiasti di provare queste cose, hai una possibilità, se non sono interessati dovresti risparmiarti la sofferenza e uscire da lì il prima possibile.

Devi pensare a cosa motiva le persone. "Sarebbe più facile per me sostituirti nel tuo lavoro se avessi aderito alle seguenti pratiche:" non è una grande motivazione: la maggior parte delle persone non vuole essere sostituita. Spendere sforzi extra per codificare in un modo che qualcun altro subentra ha ha il suo valore anche al di fuori di una filosofia di assunzione e licenziamento poiché il codice non legato a determinate persone consente di reagire in modo più flessibile ai cambiamenti dei carichi di lavoro .

Ma in una situazione "nessuno tranne $ x toccherà questo codice comunque prima che il progetto sia finito", la domanda sulla manutenibilità di chiunque rispetto allo sforzo ha risposte diverse.

Per quanto riguarda il riutilizzo del codice: una filosofia del C ++ è fornire gli strumenti per creare soluzioni generiche. Il 95% del "codice riutilizzabile" prodotto dagli aspiranti programmatori non viene riutilizzato. E il motivo è che per molte attività semplici il costo del "riutilizzo" è più elevato per un programmatore esperto rispetto alla semplice scrittura improvvisata, specificamente adatta al codice in questione.

Se dici a un autore di bestseller che può raddoppiare il suo output utilizzando i tuoi modelli di testo che sono già stati pre-controllati per errori di ortografia e grammatica e ha solo bisogno di adattarsi ai nomi e ai verbi corretti, e hai anche parametrizzato un numero di posti per gli avverbi: riesci a immaginare quanto sarà eccitato?

Riesci a immaginare quanto sarà eccitato se qualcun altro può mantenere il suo romanzo se è solo adeguatamente documentato e parametrizzato?

E nessuno vuole consultare manuali e documentazione per alcune cose banali che può scrivere in quello che per lo meno sente come impiegare meno tempo e sicuramente meno sforzo mentale.

Se hai un team altamente qualificato di costruttori di organi che lavorano su uno strumento, scoprirai che tutti h come set di strumenti personali che ha affinato nel corso degli anni. E ognuno ha le sue specialità e stili di lavoro caratteristici.

Se affermi "ecco la direzione. Abbiamo deciso di standardizzare gli strumenti di Paul. Abbiamo acquistato / realizzato 20 set di strumenti esattamente come quelli di Paul, e tutti ora lavoreranno con loro in futuro.". Anche se tutti sono d'accordo che Paul è il miglior costruttore di organi della compagnia, pochi saranno contenti di questo cambiamento. Gli strumenti probabilmente non funzioneranno bene per i costruttori inesperti e funzioneranno in modo diverso dai loro strumenti per quelli esperti.

Nemmeno Paul sarà felice perché tutti continueranno a correre da lui e incolparlo.

Il punto di una squadra non è che tutti possono essere sostituiti, ma che riescono a lavorare in un insieme coerente. Se stai cercando di ridurre al minimo i processi al minimo comune denominatore di cui ti senti soddisfatto, non stai migliorando l'output o il morale del lavoro.

Sviluppa il tuo stile. Gioca la tua parte nella squadra. Se lo stai facendo bene e in modo convincente, alla fine porterà a "chiediamo a user1807, questo suona come qualcosa che potrebbe aver preconfezionato nella sua borsa dei trucchi."

Cosa dovresti controllare dopo essere stato lì circa la metà un anno non è il modo in cui viene svolto il lavoro, ma piuttosto il modo in cui viene comunicato: ritieni che le riunioni di comunicazione / team avvengano in modo tale che le ruote veramente sostanziali non corrano il rischio di essere reinventate molto costose?

Fai le cose, come giocatore di squadra, a modo tuo. Vedrai come questo aiuta i progetti o no, gli altri vedranno come aiuta i progetti o no. Le persone imparano e questo include te. E la gestione.

Fare le cose in modo coerente e diverso da quello a cui si è inclini è una questione di disciplina. L'autodisciplina va bene, ma non sei nella situazione di disciplinare gli altri.

Se diventa evidente alla direzione che questo potrebbe essere un buon passo, prima o poi sarai a capo del team. Non ha senso cercare di stimolare la direzione per quel risultato: un team lead che non è accettato dal team non otterrà nulla impopolare. Avresti muri di pietra. Quindi sii un buon team leader per te stesso e un buon membro del team per gli altri.

Problema n. 1: insieme di individui

Se uno sviluppatore può fornire e mantenere un'API coerente, perché preoccuparsi delle convenzioni? Loro sono la persona che conosce il codice. Nessun altro manterrà l'implementazione. Preoccupati principalmente dell'API.

Problema n. 2: reinventare la ruota

In effetti questo è un problema. Il codice comune deve essere separato in un repository aziendale o di team. Questo dovrebbe essere deciso nel corso di diversi incontri dedicati con l ' intero team.

Problema n. 3: no agile

Riconosci che agile non è l'unico vero miglior approccio possibile allo sviluppo del software. Garantisce sviluppatori mediocri.