I colleghi non sembrano preoccuparsi delle migliori pratiche [chiuso]

1

Sono un membro di una squadra di 6 ingegneri del software all'interno di un reparto di 400 persone presso un'azienda abbastanza conosciuta. Siamo responsabili delle applicazioni aziendali che il nostro dipartimento utilizza, sia di strumenti di terze parti che di asp.net personalizzati che scriviamo. Il gruppo è in giro dal 2006 e sono entrato nel 2011. Ho cercato di introdurre le migliori pratiche (soc, solido, asciutto, unit test, ecc.), Ma ottengo da circa la metà che semplicemente non si cura. Visto che come gruppo dovremmo seguire lo stesso processo, dovrei rinunciare a promuovere questa roba e seguire il flusso? Ogni riunione in cui discutiamo di questo csn si riscalda un po '. Sto per finire il mio ingegno.

    
posta Dan Appleyard 17.01.2018 - 23:08
fonte

4 risposte

6

soc, solid,dry,unit testing,etc

Tentare di introdurre più nuove pratiche, contro la resistenza, di solito fallirà e, nel tuo caso, lo sarà.

Scegli uno , qualunque cosa tu pensi sia più semplice da implementare e la maggior parte ovviamente utile . Probabilmente ASCIUTTO o unit test (YMMV). La prossima volta che lavori con un collega su una nuova funzione o correzione di un bug, prova a lavorare nella nuova pratica.

Questo può ancora fallire, ma i piccoli passi spesso funzionano meglio di enormi salti.

    
risposta data 18.01.2018 - 01:44
fonte
3

... a 6 person team of software engineers ... around since 2006ish

Vorrei assumere che il turnover del personale sia stato basso, risultando in una squadra che è profondamente sintonizzata del proprio Prodotto; ben sperimentato nelle cose con cui lavorano.

In quanto tali, probabilmente non sentono bisogno di nessuna di queste [buone] cose. Loro sanno cosa stanno facendo. Ovviamente probabilmente significa un sacco di codice ripetuto e disordinato, ma va bene perché sanno [effettivamente] quello che stanno facendo.

Vorrei chiedere qual è il livello di Documentazione ... ma sospetto di conoscere già la risposta.

Questo è in realtà un buon posto per l'azienda.
Il loro team di sviluppo sa di capire che stanno facendo e lavorano in modo rapido ed efficace (presumo), anche se non è nel modo "migliore".

Tuttavia, l'atteggiamento della squadra è miope.
Quando qualcuno lascia il team, per qualsiasi motivo, subirà enormemente a causa della perdita di una proporzione significativa (1/6) di quella Conoscenza del dominio. A quel punto, i cambiamenti diventeranno più fragili, introducendo più bug a causa della mancanza di una struttura / mentalità di test.

    
risposta data 18.01.2018 - 12:44
fonte
2

Vai con il flusso? Sei unico, non scaricare le migliori pratiche per farti trascinare al loro livello di prestazioni quando si tratta di Software Engineering. Ti consiglierei di continuare a fare del tuo meglio ed esprimere le tue opinioni sulle scelte e sui cambiamenti apportati dal tuo team, ma non arrivare al punto in cui perdi produttività nelle riunioni con uno scambio "riscaldato".

Nel frattempo, continuerei a migliorare le mie capacità di sviluppatore mentre cercavo un'azienda che potrei essere adatta. Ci sono aziende appassionate e attente all'output del loro lavoro. D'altra parte, ci sono aziende che potrebbero interessare di meno. Sono appassionato di ciò che faccio, quindi l'azienda per cui lavoro dovrebbe anche essere appassionata, non solo nell'ingegneria del software, ma anche nei servizi che forniscono ai clienti.

    
risposta data 17.01.2018 - 23:22
fonte
2

Ricorda che le "Best Practices" sono un termine piuttosto ampio che dipende in gran parte dal prodotto software. Le migliori pratiche per lo sviluppo del software "shrink-wrap" variano un po 'da quelle per un team di software interno che scrive app line-of-business per l'azienda o il reparto più grande.

Forse dovresti fare un passo indietro e scoprire se il respingimento che stai ricevendo dai tuoi colleghi non è semplicemente il caso in cui sottolinei la serie sbagliata di best practice.

    
risposta data 18.01.2018 - 01:08
fonte

Leggi altre domande sui tag