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

Naviga le tue risposte
14

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

  1. Sforzi di ottimizzazione prematuri / non necessari
  2. Deduplicazione prematura con astrazioni discutibili
    Ad esempio, utilizziamo un'architettura VIPER modificata. Ha introdotto una classe base per il componente Router (usando i generici) come parte dell'implementazione del primo stack di viper senza sapere realmente cosa esattamente verrà duplicato in altri router. Ora siamo bloccati a dover fornire un tipo UseCase contenente casi d'uso, ma la maggior parte dei router non ha più casi d'uso, solo uno.
  3. Inventare soluzioni generiche per le funzionalità future potenziali speculative
    Ad esempio, ha scritto un manager per la visualizzazione di tabelle di celle statiche quando avevamo solo due schermate come questa nell'app e non era a conoscenza del fatto che il design si allontanasse dai noiosi moduli verticali a più interfacce utente personalizzate, quindi il gestore è inutile.
  4. Optando per la complessità accessoria

Come faccio a combattere questo quando esibisce anche una barriera linguistica con un pessimo inglese?

    
posta Earl Grey 29.12.2016 - 15:03
fonte

1 risposta

13

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

  • Accoppiamento. Due set di occhi possono aiutare a difendersi da una persona, ma un'implementazione complicata.
  • Revisione codice. I negozi moderni esaminano il 100% di tutte le modifiche al codice di più persone
  • Copertura del test. Assicurati che ci siano test semplici. Test eccessivamente complicati possono riflettere codice eccessivamente complicato
  • Un sacco di discussioni sul prodotto minimo vitale. Spezzare 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 si sentirà contro-intuitivo come prima è la resistenza probabile.
  • Discussioni frequenti su come ottenere biglietti e modifiche minori.
  • Votazione dei punti storia da parte dell'intero team per aprire discussioni sulla complessità e l'approccio.
  • Istruzione. Assicurati di pranzare e apprendere, sessioni di formazione, ecc. In modo che le persone possano ottenere esposizione a buone pratiche e perché sono brave.

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

Alla fine della giornata penso che la soluzione migliore per cambiare il comportamento esistente sia avere una persona dedicata a guidare il cambiamento. Nelle organizzazioni Agile (probabilmente la maggior parte oggi), ci vuole una persona dedicata come lo scrum-master per porre costantemente le domande giuste e guidare l'approccio allo sviluppo. Alla mia ultima organizzazione ne avevamo una decina, una per squadra per aiutare la gente a guidare questo tipo di problemi. Ciò elimina la necessità per uno sviluppatore di un membro del team di provare a convincere gli altri che "il loro modo è giusto", che spesso può portare a scambi di sangue e sangue sporco.

    
risposta data 29.12.2016 - 15:24
fonte

Leggi altre domande sui tag

Real World - Principio di sostituzione di Liskov Come si può progettare l'autenticazione utente dalle applicazioni client?