Come perfezionare l'architettura, cercare soluzioni migliori e non rovinare il rapporto con il team?

Dal tono del tuo post, ho intenzione di indovinare che ti manca empatia e flessibilità. Sei terrorizzato dalla reazione dei tuoi team, il che suggerisce che non puoi immaginare perché potrebbero sentirsi come loro. È difficile. Sarà difficile implementare il cambiamento se non puoi proiettarti nel loro punto di vista.

Per quanto riguarda la flessibilità, pensa a queste affermazioni:

• "... impostazione del modificatore di accesso di una classe su internal anziché public "
• "... Iniezione costruttore invece di In modo errato ma diffuso Iniezione di proprietà usata" (il mio accento)
• "Ma dovrei davvero chiedere il permesso di non usare lo sviluppo Copy-Paste ed estrarre la logica di setup del test ?!"
• "Devo discutere se posso utilizzare un generatore di dati di prova come Autofixture?"

Risponderei:

• Sebbene internal sia migliore di public , è ancora un po 'discutibile poiché internal è semplicemente public locale all'assembly. Molte lingue non ne usano nemmeno entrambi . Quindi, hai violato il codice di qualcuno modificando l'accesso a internal ? Se no e sono semplicemente a disagio, è davvero un problema che devi difendere? Vuoi bruciare la benevolenza su qualcosa di così banale?
• Va bene avere un'opinione sul costruttore e sull'iniezione di proprietà e potrei anche essere d'accordo con te. Ma ti farò conoscere un segreto: no, dove è scritto in pietra che l'iniezione di proprietà non è corretta. Questa è solo la tua opinione. Di nuovo, un'opinione con cui sono d'accordo, ma ancora un'opinione. Si prega di trattarlo come tale.
• Sì.
• Sì.

Tutto ciò si riduce a un paio di concetti. Per prima cosa, dal mio uomo André Gide:

"Trust those who seek the truth but doubt those who say they have found it."

Hai opinioni forti, è grandioso. Anche altre persone hanno opinioni. Si prega di riconoscerli per quello che sono. Lo sviluppo del software è bello, complesso e strano, ma sicuramente non è in bianco e nero. Non conosci il modo migliore di fare le cose . Non perché sei stupido o sbagliato, ma perché è impossibile conoscere il modo migliore per fare qualcosa in una pratica così soggettiva. Se esistesse un "modo migliore", le migliori pratiche non sarebbero un obiettivo così commovente. Pensa a quante cose sono cambiate nella tua carriera!

Questo non vuol dire che non dovremmo ambire alla perfezione. Dovremmo. Ma è proprio perché è un'impresa destinata al fallimento a renderla così bella. (Un po 'come gli esseri umani sono belli perché sono condannati a morire.) Quindi, qual è il più grande requisito per le squadre che cercano la perfezione? È comunicazione Questo è il secondo concetto; essere un comunicatore eccezionale prima di diventare un programmatore fantastico. Perché ad essere onesti, non puoi essere uno senza l'altro. (A meno che tu non stia sviluppando qualcosa completamente da solo come TempleOS .) Ogni volta che cambi un processo o uno strumento: comunica. Ogni volta che rielabori in modo significativo il codice di qualcun altro: comunica. Ascolta il tuo spider-sense . Se senti che qualcuno si arrabbierà, comunicherà.

Con umiltà, l'intuizione per ciò che è meglio e una buona comunicazione, puoi apportare le modifiche migliori per la tua squadra.

Assicurati di effettuare il refactoring solo in punti del tuo codice base in cui hai una ragione per cambiarlo, che è comprensibile per tutti i membri del tuo team (un motivo come aggiungere una nuova funzionalità, correggere un bug o migliorare le prestazioni). Usa quelle occasioni per migliorare il design, non migliorare il design solo per il miglior design. Ciò rende molto più facile giustificare miglioramenti del design rispetto al resto del team.

Il refactoring non è fine a se stesso. Quando scrivi "E per essere onesti sono più veloci", questo mi dà un grande segnale di avvertimento. Quando il refactoring non ti aiuta ad evolvere il tuo software più velocemente, almeno nel lungo periodo, allora stai rifocalizzando troppo e i tuoi colleghi hanno ragione.

Stai pensando in termini di programmatore, e giustamente, ma ci sono altri aspetti da tenere in considerazione.

1. Il codice di refactoring è costoso. È vero che stai già dedicando il tuo tempo alla scrittura sul codice, quindi perché dovrebbe essere un costo se si intende solo aiutare il progetto? Bene per uno, non sta aiutando il progetto a meno che non sia uno sforzo calcolato e deliberato. Se vai contro il flusso del tuo progetto, sei non che aiuta nonostante ciò che pensi in contrario. E uno sforzo enorme, senza guadagni immediati, deve essere fatto per spingerlo in avanti o uno sforzo enorme senza che sia necessario apportare cambiamenti per riportarlo alla sua gloria originale. Tutto questo non apporta benefici esterni al progetto e quindi è molto difficile giustificarlo con uno che non programma affatto (ovvero il capo del project manager che probabilmente sta pagando per tutto questo sviluppo).
2. La coerenza è la chiave. Ciò in qualche modo coincide con il commento di cui sopra, con enfasi su cosa significa avere codice coerente e codice incoerente. Da un lato, le correzioni del codice sono semplici, almeno dal punto di vista in cui inserirlo nel programma, e almeno nessuno può dire che non è ordinato. Ciò non significa che sia ordinato per i vostri standard, ma ciò è irrilevante. La coerenza ha il suo valore. Un progetto incoerente è un incubo con cui lavorare. Nonostante abbia alcuni meriti forse positivi con alcune tecniche, è come avere un po 'di aroma aromatizzato sul tuo gelato. Nessuno vuole qualcosa che sia un mix di componenti buoni e cattivi.
3. Il tuo ruolo è un consulente quando si tratta di decisioni tecniche. Hai ragione a volere che la tecnica cambi, ed è, in effetti, il tuo dovere come programmatore di presentarlo almeno come una possibilità. Detto questo, non tutto è in bianco e nero e altri programmatori non saranno d'accordo con te. Prendilo con un pizzico di sale e sappi che può essere tu ogni tanto un individuo che ha torto. Sarebbe scorretto rimanere in silenzio e persino moreso imporsi ai propri colleghi.

Il modo migliore per testare una tecnica è praticare. Non è sufficiente ascoltare qualche parola d'ordine e provare ad applicarlo al tuo programma. Se non sei sicuro di quella tecnica, non dovresti proporla ai tuoi colleghi almeno finché non sei sicuro che si adatti al tuo programma, e sfortunatamente l'unico modo per saperlo è usarlo in altre circostanze. Il lavoro non è il luogo in cui testare queste tecniche, ma puoi scrivere progetti a casa e testare le tue tecniche lì.

Il mio consiglio è di trattare i tuoi colleghi programmatori con rispetto e rispetto. Se pensi che qualcosa sia degno di menzione, menzionalo sul serio e ascolterà. Inoltre, non prenderlo a cuore se decidono di non adottare il tuo approccio. È ancora solo un business dopotutto.