Come comportarsi con un livello di squadra basso o medio?

Introduci buone pratiche, una alla volta . Forse è bene iniziare con test automatici : aggiungere test di regressione in alcuni casi e andare per testare le unità per il nuovo codice. Questo approccio è insegnato in Funzionando in modo efficace con il codice legacy . L'aggiunta di test automatici aiuta ad aderire ai principi SOLID e consente anche di rifattorizzare in seguito ai pattern.

In generale, gli sviluppatori sono sempre interessati a fare il meglio se mostri loro come farlo. Forse iniziare a diffondere le buone pratiche mostrando come farlo. Introduci una buona pratica in una dimostrazione di 1 ora e fallo una volta alla settimana. Un suggerimento, l'ultima cosa mercoledì così le persone possono provare la nuova pratica giovedì e venerdì. L'altro giorno potrebbe funzionare, ma l'ultima cosa venerdì è brutta, le persone vanno a casa loro e non discutono su come implementare al lavoro.

Altro suggerimento, non possiedi il codice, il codice è di proprietà del team. Se sei l'unico recensore ti mette sotto pressione che dovrebbe essere nella squadra. Quindi tutti dovrebbero essere coinvolti nel comprendere che qualità è un must .

Finalmente, non riscrivere tutto. Questa è una ricetta per il destino. Aggiungere test in modo organico e quindi essere in grado di sostituire parti del software è migliore (perché è più sicuro).

Mi piacerebbe seguire ciò che ha detto pietromenna. Un modo per iniziare con i test automatici è in termini di correzione dei difetti. Quando la tua squadra incontra un difetto, prova a guidarli nella direzione di creare un test automatico che simula o sfrutta tale difetto prima crea una correzione per tale difetto. Ciò assicurerà che il difetto non si verifichi di nuovo, e se lo fa, il team saprà immediatamente in modo che abbiano una migliore gestione per risolverlo. È un modo buono, immediato per dimostrare il potere delle buone pratiche che sono i test automatici.

Inoltre, per aumentare ulteriormente ciò che pietromenna ha detto, mi piacerebbe raccomandare quanto segue: Refactoring to Patterns . Una buona conoscenza del materiale di quel libro non richiede sviluppatori di livello superiore a quello che hai, indipendentemente dalla loro esperienza.

Alcuni consigli:

• Non farti travolgere dal lavoro ingrato! (Ad es. Dettagli di codifica)
• Esegui le revisioni del codice insieme al team, aiutali all'inizio, poi possono farlo da sole.
• Sulle nuove funzionalità si pianifica con 1-2 degli sviluppatori esperti che conoscono lo sfondo per la nuova fata.
• Si dice che dovresti spendere l'80% del tempo nelle cose da cui proviene il reddito. (Citazione necessaria) Puoi iniziare a sperimentare con il resto del 20%: creare un microservizio da un modulo esistente, configurare un sistema di integrazione continua per il tuo team, ecc.
• Test automatici +1
• Sicuramente hai bisogno di qualcuno a fondo in DevOps.
• Forse devi imparare le cose di cui nessuno è capace o desideroso.
• Dovresti sviluppare l'atmosfera dell'apprendimento, "fare meglio". Per esempio. Il suggerimento di @ pietromenna di dimostrazioni settimanali e puoi inviare alcuni ragazzi a Meetup o conferenze.
• D'altra parte: non andare troppo lontano con il "hype bandwagons". Ce ne sono molti e sono veloci. :)

Amazon utilizza un'architettura basata sul servizio perché ha un enorme sistema, che può riscrivere (in modo da mangiare pezzi) ogni pochi anni. In pratica, la maggior parte dei tester, programmatori, project manager e responsabili dello sviluppo di Amazon sono tenuti a dare un contributo significativo a un nuovo servizio ogni anno. Ciò significa che i manager di Amazon promuovono costantemente idee "vapor-ware", al fine di ottenere finanziamenti e clienti per nuovi servizi. I nuovi servizi sono in genere progettati per soddisfare esigenze non soddisfatte o sostituire più vecchi servizi o scalare esigenze molto più grandi a causa della crescita di Amazon.

La mia ipotesi è che nessuno di questi motivi per l'adozione di un'architettura di micro-servizi si applichi alla tua situazione. Anche se 150.000 righe di codice sono grandi, probabilmente troppo grandi per una persona da tenere a mente, è abbastanza piccolo che una persona possa apportare modifiche per tutto il corso di un paio d'anni.

Il mio consiglio sarebbe di apportare miglioramenti incrementali. Dai la priorità ai miglioramenti per ottenere "vittorie veloci" prima, poi "insegui" la "frutta bassa appesa" ripetutamente. Cerca di fare sempre le cose "meglio di prima". (Ciò richiede spesso la possibilità di ammettere prontamente che un cambiamento non ha aiutato ed essere in grado di annullare rapidamente e facilmente le modifiche.)