Mi sembra che tu stia mettendo il carrello davanti al cavallo.

Qual è il problema principale che il tuo team sta affrontando e quali tecnologie potrebbero aiutarti a risolverlo?

Ad esempio, se ci sono molti bug, in particolare bug di tipo regressione, il test unitario può essere un punto di partenza. Se la tua squadra non ha tempo, forse un quadro può aiutare (a medio-lungo termine). Se le persone hanno difficoltà a leggere il codice degli altri, lo styling potrebbe essere utile.

Ricorda che lo scopo dell'attività per cui lavori è fare soldi, non fare codice.

Java? Moderno?! Hai fallito al primo ostacolo. Se vuoi essere veramente moderno ed evitare il "suicidio professionale", allora devi scrivere il codice Rust. Certo, la prossima settimana cambierà tutto e dovrai imparare qualcosa di ancora più nuovo da tenere aggiornato!

Oppure, potresti accettare che nessuna quantità di tecnologie buzzword o di metodologie o strutture o qualsiasi altro du jour cambierà il fatto che vuoi costruire prodotti di qualità che funzionino. Non importa se non usi agile se stai producendo il giusto output. Certo, se non lo sei, allora potresti voler cambiare le cose, ma è probabile che nessuna pratica particolare risolverà i problemi. Rimarranno problemi umani che possono essere risolti in un numero qualsiasi di modi diversi.

Per quanto riguarda il suicidio professionale, se sai cosa stai facendo e sei flessibile, allora non hai bisogno di nessuna delle cose che hai menzionato. Le persone continueranno a inventare nuovi modi di fare il vecchio lavoro e sarai sempre al passo con i tempi. Oppure puoi semplicemente usare qualsiasi tecnica che la tua compagnia attuale usi a prescindere. Quando cambi la tua azienda, impari e utilizzi semplicemente le tecniche che usano.

Troppi bambini restano appesi a tutti i nuovi strumenti che potrebbero usare, dimenticando che questi strumenti sono inutili nelle mani di un principiante. Apprendi la pratica prima, una volta che sei uno sviluppatore esperto puoi iniziare a "aggiustare" le pratiche di sviluppo con "nuove cose interessanti", ma a quel punto ti sarai probabilmente reso conto che non sono così importanti come pensi attualmente, e solo per essere usato quando sono veramente necessari.

Molte aziende sono bloccate in questo modo; potresti anche essere sorpreso di scoprire che alcuni dei tuoi colleghi sviluppatori sono autodidatti e sono diventati sviluppatori senza alcun background formale. Questi sviluppatori sono spesso più bravi nel loro lavoro, poiché saranno quelli che sono spinti ad apprendere nuove competenze e ad avere successo invece di fare semplicemente il lavoro. Sfortunatamente questo può anche significare che, mentre sono eccellenti nella programmazione, potrebbero non essere consapevoli dei vantaggi di queste pratiche. Il fatto è che queste sono le migliori pratiche, non le pratiche comuni . I migliori li usano, ma non hanno tutti i requisiti per avere successo, sono semplicemente degli strumenti per facilitare il successo.

Hai assolutamente ragione, sarà travolgente provare a implementare tutto in una volta. Probabilmente brucerai te stesso (e forse la tua squadra) cercando di farlo, il che sta per demotivare le spinte future ad adottare nuove metodologie / tecnologie. La cosa migliore da fare in una situazione come questa è selezionare una cosa (il logging è probabilmente un buon inizio, dato che probabilmente hai una strada difficile da trovare e trovare bug senza registrazione, e ci sarà sicuramente bug) e parlarne con il team. Non è necessario implementarlo da solo; Farai molto meglio discutere dei pro e contro con il team (e il tuo capo, che DEVE assolutamente essere coinvolto in qualcosa del genere) e trovare un piano per implementarlo. Dovrà essere il più indolore possibile (ricorda, stai dicendo alla gente che ora devono scrivere codice extra oltre a quello che già fanno).

E lascia che ti ripeta, assicurati che il tuo capo acquisti . Questo è cruciale; probabilmente scoprirai che la velocità delle correzioni / rilasci rallenta quando implementi nuove cose. Il punto è che stai pagando in anticipo per risparmiare sulla linea; DEVONO capirlo e stare dalla tua parte. Se non li porti a bordo, stai combattendo al meglio una battaglia persa e nel peggiore dei casi potrebbero considerarti come un sabotaggio attivo della squadra (chiedimi come faccio a saperlo).

Una volta che hai portato questi oggetti al tavolo, discuti con il team, pianifica come implementarli e segui, il secondo, il terzo, l'ottavo, ecc. sarà più facile. Non solo, c'è il potenziale per il team e il tuo capo di guadagnarti rispetto per te dato che i tuoi suggerimenti sono implementati e riconosciuti come valore aggiunto. Grande! Assicurati di rimanere flessibile: stai spingendo contro l'inerzia qui e il cambiamento non è facile. essere pronti a lentamente apportare piccole modifiche e assicurarti di poter monitorare i progressi e il valore ottenuto. Se implementi il logging in un nuovo processo e ti aiuta a risparmiare ore a trovare un bug in tre settimane, fai un grosso problema! Assicurati che tutti sappiano che l'azienda ha appena salvato $ XXX facendo la cosa giusta prima del tempo. D'altra parte, se ricevi il pushback o hai una scadenza molto stretta, non provare a forzare il problema. Lascia che la nuova modifica scorra per il momento, e torna indietro. Non vincerai mai cercando di costringere la squadra a fare qualcosa che non vogliono fare, e puoi essere sicuro che la prima cosa che ti suggeriranno di lasciar cadere è il nuovo lavoro "extra" (come scrivere la registrazione, o seguire uno styleguide invece di "farlo funzionare").

Spero che tu non abbia presentato i problemi ai tuoi colleghi come hai fatto a noi nel tuo post. Quello sarebbe un suicidio professionale.

Il primo problema è che stai cercando di insegnare tecnologie e metodi che anche tu non hai esperienza con un gruppo di programmatori che, forse sono un po 'sorpassati, ma che fanno "terminare" il lavoro. Le possibilità di questo backfiring sono infinite e probabilmente porteranno molta gioia ai tuoi colleghi. È interessante e ammirevole che tu voglia migliorare te stesso e il tuo dipartimento, ma eviti di usare termini come "punta di lancia". Cordiali saluti, non usare quella parola.

Come problema secondario a quanto sopra, controlla che stai facendo del lavoro . Ho lavorato come programmatore solitario e autoapprendimento per un sacco di tempo e so quanto sia facile mettere da parte il lavoro reale per esplorare strutture, tecnologie e simili promettenti. Assicurati che la tua performance rientri nei parametri previsti (no, a nessuno importa che passi 20 ore a cercare Spring se la segnalazione che ti hanno fatto non è stata completata).

Da tutto quanto sopra, evita di essere l'insegnante (a meno che non sia correlato a un campo / tecnologia in cui effettivamente hai abbastanza esperienza). Una presentazione più neutrale potrebbe indicare i vantaggi, ad esempio, dei test automatizzati e lasciare che la direzione abbia scelto chi desidera ricercare i pro e i contro di tali pratiche.

Ora, per presentare queste "migliori pratiche", ci sono due modi per spiegarle alla tua squadra:

• Perché dico che sono le migliori pratiche, e questo è sufficiente.
• Perché sono utili e aiutano a risolvere il problema.

Usando il primo argomento, a meno che tu non sia il capo o un membro molto anziano del team, è improbabile che ti prestino attenzione. E "Ho letto un libro di Knuth che dice così" o "i ragazzi del SE dicono che" non provocheranno alcuna impressione, neanche ("quei ragazzi non lavorano qui, quindi non sanno davvero cosa è buono per questo negozio IT "). Hanno i loro metodi, routine, procedure e cose "più o meno" funzionano, quindi perché prendere lo sforzo ei rischi di cambiare?

Per il secondo approccio al lavoro, ci deve essere la consapevolezza che esiste un problema . Quindi:

• non andare avanti giorno e notte per i test automatici. Attendi fino a quando un aggiornamento interrompe alcune funzionalità e il team deve eseguire gli straordinari per risolverlo e quindi proporre di creare un sistema di test automatizzato.
• non chiedere recensioni sul codice. Aspetta che Joe abbia un congedo prolungato e che ci sia la necessità di cambiare in quel modulo che solo Joe conosce, e indica al tuo capo quanto tempo è stato perso cercando solo di capire il codice di Joe.

Naturalmente, il cambiamento sarà lento e progressivo (più che altro in una grande azienda). Se riesci a introdurre la revisione del codice e i test automatici in cinque anni, dovresti congratularti con te stesso per un lavoro ben fatto. Ma, a meno che non ci sia una riscrittura completa a causa di cause esterne, dimentica qualsiasi fantasia che cambieranno il core IS per, ad esempio, Spring ( Joel ha spiegato in questo modo meglio di quanto avrei mai potuto, anche prima che tu nascessi ¹ ); in quel momento si poteva, al massimo, ottenere Spring nell'elenco di piattaforme supportate per scrivere sistemi non critici.

Benvenuti nel mondo dell'informatica aziendale, ragazzo! :-p

¹ : Ok, forse sto esagerando un po ', ma non troppo.

Devi iniziare con il libro Lavorare efficacemente con il codice legacy di Michael Feathers. Dall'introduzione del libro, "Si tratta di prendere un sistema aggrovigliato, opaco, contorto e lentamente, gradualmente, pezzo per pezzo, passo dopo passo, trasformandolo in un sistema semplice, ben strutturato e ben progettato". Inizia per lo più con test automatici, in modo che tu possa refactoring in modo sicuro (saprai se si rompe qualcosa) e include molte strategie per portare codice difficile sotto test automatizzati. Questo è utile per ogni progetto ancora in fase di sviluppo. Una volta ottenuto l'ordine di base, puoi vedere quali altre tecnologie moderne potrebbero trarre vantaggi dal tuo progetto, ma non dare per scontato che ti servano tutte.

Se vuoi imparare un nuovo framework (o qualcosa del genere) per ragioni professionali piuttosto che perché il tuo progetto attuale ne ha effettivamente bisogno, dovresti usarlo in qualche progetto personale (nel tuo tempo libero).

Controllo del codice sorgente.

Non l'hai menzionato, si spera perché è già sul posto, ma, nel caso in cui non lo fosse, inizia da lì.

Il controllo del codice sorgente ha il più grande successo, tranne che in rare circostanze patologicamente bisognose di qualcos'altro.

E puoi iniziare da solo se inizialmente non acquisti nessuno.

Risposta diretta

Altre risposte fanno buoni "meta-punti" sull'adozione di pratiche migliori ma, solo per darti alcuni consigli direttamente pertinenti, ecco un ordine approssimativo delle migliori pratiche che suggerirei alla tua squadra (o qualsiasi squadra) adottare (prima):

1. Controllo del codice sorgente
2. Rileva problemi (gestione di progetti e attività)
3. build automatizzati ¹
4. Distribuzioni automatizzate

^{1 _{Una pratica molto correlata è quella di automatizzare, o almeno document , configurare l'ambiente di sviluppo e di sviluppo di ogni app o progetto software che stai sviluppando o mantenendo. È molto meno utile perché tu (si spera) lo fai di rado o raramente.}}

Tutto il resto

Hai menzionato molte altre buone pratiche - "test di unità, registrazione, normalizzazione del database, ... refactoring, ... documentazione" - ma queste sono tutte pratiche che possono e dovrebbero essere adottate gradualmente e in modo incrementale. Nessuno di questi deve essere adottato tutto in una volta e probabilmente sarà meglio adottarli affatto adottandoli con attenzione e con attenzione.

Le quattro pratiche che ho elencato sopra faranno anche l'adozione e la sperimentazione di nuove pratiche nel modo più semplice possibile. Ad esempio, i test unitari possono essere incorporati nelle build automatiche e la documentazione può essere pubblicata come parte dei dispiegamenti automatici.

Alcune delle altre pratiche che menzioni - "sviluppo agile, ... guide di stile per la codifica, ... revisioni del codice, ... metodi di documentazione standardizzati" e framework (ad esempio Spring) - sono davvero facoltativi o di dubbia utilità. E questo è vero per molte (la maggior parte?) Possibili pratiche che scoprirai o incontrerai.

Lo sviluppo agile non è ovviamente superiore a qualsiasi altra metodologia utilizzata. E molte persone (me compreso) hanno avuto esperienze orribili con esso. Ma a molte persone piace molto (o piace anche a loro). Provalo!

Le guide di stile di codifica possono essere utili, in particolare per i progetti di grandi dimensioni o in team di grandi dimensioni, ma è anche molto lavoro per applicare tali linee guida e potrebbe non essere il miglior uso del tempo di chi sta facendo così.

Anche le recensioni dei codici possono essere molto utili: hai chiesto ai tuoi colleghi di rivedere il tuo codice? Tieni presente che non è necessario un processo formale per adottare buone pratiche!

La documentazione è ottima - ne hai? Se è così, buon per te! Stai affrontando un sacco di lavoro extra che potrebbe essere prevenuto avendo (più) documentazione "standardizzata"? Se lo sei, allora probabilmente è qualcosa che vale la pena fare. Tuttavia, se il tuo software viene utilizzato da un piccolo gruppo di persone, potresti non aver bisogno della documentazione . (Oppure potresti direttamente incorporare la documentazione nel tuo software. Questa è sempre la mia preferenza.)

I quadri sono ... un'arma a doppio taglio molto affilata. Una soluzione ben incapsulata e ben tenuta per una funzionalità non core del tuo software è fantastica ... finché non lo è. Non sono sicuro di cosa siano esattamente i "front controller" scritti a mano, ma non c'è alcuna spiegazione ovvia sul motivo per cui sono inferiori al codice che sfrutta Spring. Avete considerato di incapsulare la logica comune in tutti questi controllori nel vostro contesto interno? Adottare Spring e riscrivere tutto il codice esistente potrebbe essere un immenso refactoring (o, più probabilmente, riscrittura) del progetto e potrebbe non essere il miglior cambiamento che potresti apportare al tuo codice . Ovviamente non dovresti scrivere tutti del software che utilizzi - frameworks (e biblioteche) sono fantastici! Ma forse non devi usare Spring (o un'alternativa) per scrivere applicazioni web grandiose (o buone).

Guardati intorno alla squadra di cui fai parte. Riesci a vedere qualche prova del fatto che lo sviluppo guidato dai test o la normalizzazione del database miglioreranno la qualità del software che stai scrivendo o renderanno le persone più produttive?

Hai provato a parlare con uno dei supervisori dello sviluppo al riguardo o il responsabile dello sviluppo? Una chat davvero informale sarebbe un buon inizio. Cosa ti fa pensare che le persone sopra di te non abbiano avuto le stesse idee, ma non possono / non le implementeranno perché l'azienda non le permetterà?

Trovo che guidare l'esempio sia un buon modo per andare. Le persone sono molto meno resistenti se qualcun altro ha già fatto il lavoro e può mostrare loro come replicarlo. Presenta TDD in un progetto a cui stai lavorando. Chiedi di fare una presentazione al resto della squadra, o anche a un paio di altri e mostrare loro ciò che hai fatto. Quello che @DrewJordan ha detto su come ottenere il buy-in dal boss è più importante di quanto probabilmente ti rendi conto.

Trova un difetto. Correggere un difetto. Mostra la correzione.

Prima prendiamo la normalizzazione *. E in effetti, ti suggerisco di prenderlo prima, perché la mancanza di normalizzazione potrebbe portare a dati bacati che non potrebbero esistere altrimenti, mentre il resto sono casi in cui le migliori pratiche potrebbero probabilmente aiutare, ma è più difficile dire "Bug A è stato causato dal mancato rispetto della politica X ". Se hai un database che non è normalizzato, hai un posto dove i dati possono essere incoerenti.

È una buona scommessa che tu possa trovare un caso reale di dati incoerenti. Ora hai trovato due cose:

1. Un bug nei tuoi dati.

2. Un bug nei tuoi schemi di database.

In realtà, conoscevi il primo bug, ma il primo è più facilmente dimostrabile e anche qualcosa che sta causando un problema reale, non qualcosa che teoricamente potrebbe.

Sfortunatamente uno dei motivi per cui si è resistito alla normalizzazione del database denormalizzato è che la questione di cosa fare con tali dati buggy non è sempre facile, ma avrai trovato un bug reale.

(Sappi però che ci sono dei motivi per cui a volte qualcuno potrebbe denormalizzare alcuni dati apposta.) Non confondere la rottura consapevole della regola per l'ignoranza della regola, se normalizzi una tabella che è deliberatamente denormalizzata per la velocità della ricerca non vincerai nessuna gloria, anche se qui, denormalizzare essere carichi è qualcosa che dovrebbe essere fatto proceduralmente, quindi se la tabella denormalizzata non viene creata automaticamente in base al contenuto delle tabelle normalizzate, ci sono ancora dei progressi da fare).

Per il resto, introdurli quando aiutano a breve termine, per poi costruirli a lungo termine. Per esempio. se ti viene data una piccola porzione di codice da compilare, scrivi un unit test per questo. Meglio ancora, se ti viene dato un bug da correggere, scrivi un test unitario che fallisce a causa del bug e poi quando hai risolto il bug menziona il fatto che passa quando chiudi i bug (o manda una mail dicendo che è stato corretto o qualsiasi altra cosa.

* Per inciso, non molto moderno. La ragione per cui è chiamata normalizzazione e non normalizzazione o qualcos'altro, è che al momento era uno scherzo di attualità per attaccare -ization fine delle cose per prendere in giro il nome della politica Vietnamizzazione di Richard Nixon.

Ho intenzione di andare controcorrente e dire: trova un nuovo lavoro dopo aver passato un po 'di tempo in questo per costruire il tuo curriculum un po'. Mirare per un anno o giù di lì. Sebbene molte cose siano "parole d'ordine", problemi come una completa mancanza di test unitari sono intrattabili per un singolo sviluppatore, e le possibilità sono che se i programmatori che lavorano non desiderano testare, non otterrete mai l'acquisto e potrebbero persino mettere a repentaglio la vostra posizione in compagnia facendo in modo che le persone ti considerino uno sbruffone. Devi essere in un posto in cui puoi ottenere mentoring, non cercando di spingere la cultura verso la competenza di base.

Ci sono state molte proposte per migliorare il paradigma di programmazione . Le parole d'ordine più calde ora sembrano essere una programmazione agile e orientata agli oggetti. O sono loro? Entrambi sono sbiaditi sostanzialmente rispetto a quello che erano solo cinque anni fa.

Puoi essere abbastanza fiducioso sul fatto che qualsiasi metodologia messa in atto stia cercando di ottenere lo stesso risultato finale: aiuta gli ingegneri a produrre economicamente un prodotto finale che sia abbastanza buono.

Esiste un paradigma che è stato introdotto in modo controverso negli anni '60: programmazione strutturata : usa solo costrutti di "alto livello" come while , for , repeat , if / then / else , switch / case affermazioni invece dell'istruzione goto strongmente utilizzata che era stata accettata di default. Ci sono ancora dibattiti sul fatto che goto abbia un uso legittimo.

Accetto che ridurre al minimo l'uso di goto sia una buona cosa, ma come tutte le cose buone, è possibile andare troppo lontano.

Hai menzionato le metodologie agile come qualcosa di positivo. Sono stato in un team di sviluppo per circa sei mesi che ha intenzionalmente seguito un regime agile prescritto. Ho scoperto che si tratta di metodologie illuminate di gestione dei progetti di decenni fa, ad eccezione del fatto che tutto viene rinominato. Forse ri-raggruppando e rivendendo idee per comunicare qualcuno si guadagna da vivere e le aziende possono sentirsi bene nel "vedere" il nuovi vestiti dell'imperatore .

La lezione più preziosa di Agile, che è stata conosciuta molto tempo fa, è che la flessibilità nel trovare un percorso migliore per il prodotto finito è una buona cosa e la possibilità di trovare quel percorso può provenire da chiunque, non solo dalla gestione superiore.

Da uno scritto di anti-goto capobanda Edsger Dijkstra:

The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.

—Dijkstra, in: Dahl, Dijkstra & Hoare 1972, pg. 6. (see page 6 here.)