Come impedire a un collega di introdurre estrema complessità e astrazione?

Sto attraversando un momento molto difficile perché il mio collega sembra esibire

Sforzi di ottimizzazione prematura / non necessaria
Deduplicazione prematura con astrazioni discutibili
Ad esempio, utilizziamo un'architettura VIPER modificata. Ha introdotto una classe base per il componente Router (usando generics) come parte dell'implementazione del primo stack viper senza sapere esattamente cosa verrà duplicato in altri router. Ora siamo bloccati a dover fornire un tipo UseCaseche contiene casi d'uso, ma la maggior parte dei router non ha più casi d'uso, solo uno.
Inventare soluzioni di uso generale per potenziali funzionalità speculative future
Ad esempio, ha scritto un manager per il popolamento di viste di tabelle di celle statiche quando nell'app erano presenti solo due schermate come questa e non era a conoscenza del fatto che il design passasse da noiose forme verticali a più personalizzate UI quindi il gestore è inutile.
Optando per la complessità accidentale

Come posso combattere questo quando mostra anche di avere una barriera linguistica con l'inglese scadente?

architecture

— Conte grigio
fonte

Hai provato le revisioni obbligatorie del codice per dare l'opportunità di discutere cosa sta succedendo? Hai provato con lui il white boarding per trovare una buona soluzione prima che si sieda per iniziare a scrivere codice?

— Becuzz,

Puoi fare un esempio in cui potrebbero verificarsi situazioni come in 2 o 3?

— morbidCode

Sento il tuo dolore, @EarlGrey. Probabilmente non ho mai visto un caso in cui la codifica "generica" super up front in realtà funziona come previsto in futuro.

— Graham,

Conosco persone che chiamano utilizzando un quicksort invece di un bubbleort un'ottimizzazione prematura. Qual è la tua soglia?

— Pieter B,

Il tuo collega sembra dimenticare / ignorare il principio di YAGNI .

— Bart van Ingen Schenau,

La tua descrizione sembra la codifica che ho fatto negli anni '90. Non è facile esibirsi in modo appropriato per il mondo moderno. Consiglio di concentrarmi sui seguenti fattori:

Accoppiamento. Due serie di occhi possono aiutare a proteggersi da una persona eccezionale, ma complicata.
Revisione del codice. I negozi moderni esaminano il 100% di tutte le modifiche al codice da parte di più persone
Copertura del test. Assicurati che ci siano test semplici. Test troppo complicati possono riflettere un codice troppo complicato
Molte discussioni sul prodotto minimo praticabile. Suddividi le funzionalità nei componenti più piccoli possibili. Va bene avere un ticket per cambiare il database, un altro per popolare le tabelle di riferimento e poi un terzo per aggiornare l'interfaccia utente (la parte che sarà effettivamente visibile agli utenti finali), ma sembrerà contro-intuitivo non appena la resistenza è probabile.
Discussioni frequenti su come avere biglietti e modifiche più piccoli.
Votazione della storia da parte di tutto il team per aprire discussioni sulla complessità e l'approccio.
Formazione scolastica. Assicurati di avere pranzo e apprese, sessioni di allenamento, ecc. In modo che le persone possano essere esposte alle buone pratiche e al perché siano buone.

Da tutto quanto sopra, i miei due principali punti di interesse sarebbero le revisioni del codice e le storie più piccole.

Alla fine della giornata penso che la migliore soluzione per cambiare il comportamento esistente sia quella di avere una persona dedicata a guidare il cambiamento. Nelle organizzazioni Agili (probabilmente oggi la maggioranza), ci vuole una persona dedicata come la scrum-master per porre costantemente le domande giuste e guidare l'approccio allo sviluppo. Nella mia ultima organizzazione ne avevamo una dozzina, una per squadra per aiutare le persone a risolvere questo tipo di problemi. Ciò elimina la necessità che uno sviluppatore di un membro del team stia cercando di convincere gli altri che "la loro strada è giusta", che spesso può portare a scambi acrimonici e sangue cattivo.

— Michael Durrant
fonte