Sono uno sviluppatore relativamente nuovo, appena uscito dal college. Mentre ero al college e durante le successive ricerche di lavoro, mi sono reso conto che mancavano molte metodologie di sviluppo software "moderne" che mancavano alla mia istruzione: test unitari, registrazione, normalizzazione del database, sviluppo agile (rispetto a concetti agili generici), stile di programmazione guide, refactoring, revisioni del codice, metodi di documentazione standardizzati (o persino requisiti), ecc.

Nel complesso, non ho visto che questo è un problema. Mi aspettavo che il mio primo lavoro abbracciasse tutte queste idee e me le insegnasse sul posto di lavoro. Poi ho ottenuto il mio primo lavoro (sviluppo web full stack) in una grande azienda e mi sono reso conto che non facciamo nessuna di queste cose. In effetti io, il meno esperto della squadra, sono io a guidare i tentativi di portare il mio team al passo con le tecniche di programmazione "moderne", poiché temo che non farlo sia un suicidio professionale lungo la strada.

Per prima cosa ho iniziato con il software di registrazione (log4J), ma poi sono passato rapidamente alla styleguide personale, per poi abbandonarla per la styleguide di Google - e poi ho capito che il nostro sviluppo web Java utilizzava front controller scritti a mano, quindi ho spinto per la nostra adozione di Spring - ma poi mi sono reso conto che non avevamo nemmeno test unitari, ma stavo già imparando Spring ... e come puoi vedere, diventa travolgente troppo rapidamente, specialmente se abbinato al normale lavoro di sviluppo. Inoltre, è difficile per me diventare "esperto" abbastanza in queste metodologie per insegnare a chiunque altro in esse senza dedicare troppo tempo a una sola di esse, figuriamoci tutte.

Di tutte queste tecniche, che vedo come "attese" nel mondo di sviluppo software di oggi, come posso integrarle in una squadra come un nuovo giocatore senza schiacciare sia me che la squadra?

Come posso influenzare la mia squadra a diventare più agile? è legato, ma io sono non uno sviluppatore Agile come il richiedente ha qui, e sto guardando un insieme molto più ampio di metodologie di Agile.

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

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

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

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

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

Oppure, potresti accettare che nessuna quantità di tecnologie o metodologie o framework di parole d'ordine 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 correttamente l'output giusto. Naturalmente, se non lo sei, allora potresti voler cambiare le cose, ma è probabile che nessuna pratica particolare risolva i problemi. Rimarranno problemi umani che possono essere risolti in qualsiasi numero di modi diversi.

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

Troppi bambini vengono bloccati da tutti i nuovi strumenti che potrebbero usare, dimenticando che questi strumenti sono inutili nelle mani di un principiante. Per prima cosa impara la pratica, una volta che sei uno sviluppatore esperto puoi iniziare a "correggere" le pratiche di sviluppo con "nuove cose interessanti", ma spero che ti sarai reso conto che non sono così importanti come pensi attualmente, e da usare solo quando sono realmente 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 svolgere semplicemente il lavoro. Sfortunatamente questo può anche significare che, sebbene siano eccellenti nella programmazione, potrebbero non essere consapevoli dei benefici di queste pratiche. Il fatto è che si tratta di buone pratiche, non di pratiche comuni . I migliori li usano, ma non sono affatto requisiti per avere successo, sono semplicemente strumenti per rendere più facile il successo.

Hai assolutamente ragione, sarà travolgente provare a implementare tutto in una volta. Probabilmente ti brucerai (e forse il tuo team) cercando di farlo, il che demotiverà le spinte future per adottare nuove metodologie / tecnologie. La cosa migliore da fare in una situazione come questa è sceglierne unacosa (la registrazione è probabilmente un buon inizio, poiché probabilmente hai una strada difficile da percorrere per trovare bug senza registrazione e ci saranno sicuramente dei bug) e parlarne con il team. Non devi implementarlo da solo; farai molto meglio a discutere i pro ei contro con il team (e il tuo capo, che DEVE assolutamente essere d'accordo con qualcosa del genere) e elaborare un piano per implementarlo. Dovrà essere il più indolore possibile (ricorda, stai dicendo alle persone che ora devono scrivere un codice aggiuntivo oltre a quello che già fanno).

E lasciami dire ancora, assicurati che il tuo capo acquisti . Questo è cruciale; probabilmente scoprirai che la velocità delle correzioni / rilasci rallenta man mano che implementi nuove cose. Il punto è che stai pagando in anticipo per salvare la linea; DEVONO capirlo ed essere dalla tua parte. Se non li ottieni a bordo, stai combattendo una battaglia persa nella migliore delle ipotesi, e nella peggiore delle ipotesi potrebbero considerarti come sabotare attivamente la squadra (chiedimi come lo so).

Dopo aver portato questi elementi al tavolo, discuterli con il team, pianificare come implementarli e seguire, il secondo, il terzo, l'ottavo, ecc. Sarà più facile. Non solo, c'è un potenziale per il team e il tuo capo di ottenere rispetto per te poiché i tuoi suggerimenti vengono implementati e riconosciuti come valore aggiunto. Grande! Assicurati solo di rimanere flessibile: stai spingendo contro l'inerzia qui e il cambiamento non è facile. preparatevi a fare lentamente piccolimodifiche e assicurati di poter tenere traccia dei progressi e del valore guadagnato. Se implementi la registrazione in un nuovo processo e ti aiuta a risparmiare ore a trovare un bug in tre settimane, fai molto! Assicurati che tutti sappiano che l'azienda ha appena risparmiato $ XXX facendo la cosa giusta in anticipo. D'altra parte, se ricevi un 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 forzare il team a fare qualcosa che non vogliono fare, e puoi essere sicuro che la prima cosa che suggeriranno di abbandonare è il nuovo lavoro "extra" (come scrivere il log o seguire una styleguide invece di "farla funzionare").

Spero che tu non abbia presentato i problemi ai tuoi colleghi come ci hai fatto nel tuo post. Sarebbe un suicidio professionale.

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

Come problema secondario di quanto sopra, controlla che stai facendo un po 'di lavoro . Ho lavorato come programmatore solitario e autoapprendimento per molto tempo e so quanto sia facile mettere da parte il lavoro effettivo al fine di esplorare quadri, 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 quel rapporto che ti hanno chiesto non è stato fatto).

Da tutto quanto sopra, evitare di essere l'insegnante (a meno che non sia correlato a un campo / tecnologia in cui in realtà hai abbastanza esperienza). Una presentazione più neutra indicherebbe i vantaggi, per esempio, dei test automatizzati e lascerà che il management scelga chi desidera ricercare i pro ei contro di tali pratiche.

Ora, per presentare queste "migliori pratiche", ci sono due modi per spiegarle al tuo team:

• Perché dico che sono le migliori pratiche e questo è abbastanza.
• 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 della squadra, è improbabile che ti prestino attenzione. E "Ho letto un libro di Knuth che lo dice" o "i ragazzi della SE dicono che" non causerà alcuna impressione, né ("quei ragazzi non lavorano qui, quindi non sanno davvero cosa è buono per questo negozio IT "). Hanno i loro metodi, routine, procedure e le cose "più o meno" funzionano, quindi perché prendere lo sforzo e i rischi di cambiare?

Affinché il secondo approccio funzioni, ci deve essere la consapevolezza che esiste un problema . Così:

• non andare a spingere giorno e notte per i test automatici. Attendere fino a quando un aggiornamento non interrompe alcune funzionalità e il team deve fare gli straordinari per risolverlo, quindi proporre di creare un sistema di test automatizzato.
• non chiedere recensioni di codice. Attendi fino a quando Joe non è in congedo prolungato e c'è bisogno di cambiare in quel modulo che solo Joe conosce, e indica al tuo capo quanto tempo è stato perso solo cercando di capire il codice di Joe.

Certo, il cambiamento sarà lento e progressivo (tanto più in una grande società). Se arriverai a presentare la revisione del codice e i test automatizzati tra cinque anni, dovresti congratularti con te stesso per il lavoro ben fatto. Ma, a meno che non ci sia una riscrittura completa a causa di cause esterne, dimentica qualsiasi fantasia a cui cambierà il nucleo IS, diciamo, Spring ( Joel ha spiegato in questo modo meglio di quanto potessi mai, anche prima che tu nascessi ¹ ); in quel momento, al massimo, potresti portare Spring nell'elenco delle piattaforme supportate per scrivere sistemi non critici.

Benvenuto nel mondo dell'IT aziendale, ragazzo! :-p

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

Dovresti iniziare con il libro Working Effectively with Legacy Code 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". Comincia principalmente con i test automatici, in modo che tu possa refactoring in modo sicuro (saprai se rompi qualcosa), e include molte strategie per portare il codice difficile sotto test automatici. Questo è utile per ogni progetto che è ancora in fase di sviluppo. Una volta che hai messo in atto un ordine di base, puoi vedere quali altre moderne tecnologie potrebbero davvero trarre vantaggio dal tuo progetto, ma non dare per scontato che tu abbia bisogno di tutte.

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

Controllo della fonte.

Non lo hai menzionato, si spera perché è già in atto, ma, nel caso non lo sia, inizia da lì.

Il controllo del codice sorgente ha il massimo vantaggio, tranne in rare circostanze patologicamente bisognose di qualcos'altro.

E puoi iniziare da solo se nessuno inizialmente acquista.

Una risposta diretta

Altre risposte forniscono buoni "meta-punti" sull'adozione di migliori pratiche ma, solo per darvi una guida direttamente pertinente, ecco un ordinamento approssimativo delle migliori pratiche che suggerirei che la vostra squadra (o qualsiasi squadra) adotti (prima):

1. Controllo della fonte
2. Monitoraggio dei problemi (gestione di progetti e attività)
3. Build automatici ¹
4. Distribuzioni automatizzate

^{1 _{Una pratica molto correlata è quella di automatizzare, o almeno documentare , l'impostazione dell'ambiente di compilazione e sviluppo di ogni app o progetto software che si sta sviluppando o gestendo. È molto meno utile anche perché (si spera) lo fai raramente o raramente.}}

Tutto il resto

Lei menziona diverse altre buone pratiche - "unit testing, logging, normalizzazione del database, ... refactoring, ... documentazione" - ma queste sono tutte pratiche che possono e devono essere adottate gradualmente e in modo incrementale. Nessuno di loro ha bisogno di essere adottati tutti in una volta e probabilmente meglio adottare li a tutti , adottando con attenzione e consapevolmente.

Le quattro pratiche che ho elencato sopra renderanno anche più semplice l'adozione e la sperimentazione di nuove pratiche. Ad esempio, i test unitari possono essere incorporati nelle build automatizzate e la documentazione può essere pubblicata come parte delle distribuzioni automatizzate.

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

Lo sviluppo agile non è ovviamente superiore a qualsiasi altra metodologia utilizzata. E molte persone (incluso me stesso) hanno avuto esperienze orribili con esso. Ma a molte persone piace davvero (o lo adora). Provalo!

Le guide di stile di codifica possono essere utili, specialmente per 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 lo sta facendo.

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

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

Le strutture sono ... una spada (molto affilata) a doppio taglio. Una soluzione ben incapsulata e ben mantenuta per una funzionalità non core del tuo software è eccezionale ... fino a quando non lo è. Non sono sicuro di cosa siano esattamente i "front controller scritti a mano", ma non c'è una spiegazione ovvia sul perché siano inferiori al codice che sfrutta Spring. Hai considerato l'incapsulamento della logica comune in tutti questi controller nel tuo framework interno? Adottare Spring e riscrivere tutto il codice esistente potrebbe essere un immenso progetto di refactoring (o, più probabilmente, riscrivere) e potrebbe non essere la migliore modifica che potresti apportare al tuo codice . Ovviamente non dovresti scrivere tutto il software che usi - i framework (e le librerie) sono fantastici!Ma forse non devi usare Spring (o un'alternativa) per scrivere app Web fantastiche (o buone).

Guardati intorno alla squadra di cui fai parte. Riesci a vedere qualche prova 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 parlarne con uno dei supervisori dello sviluppo o con 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 lo permetterà?

Trovo che l'esempio sia un buon modo di procedere. Le persone sono molto meno resistenti se qualcun altro ha già svolto il lavoro e può mostrare loro come replicarlo. Introduci 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 mostra loro quello che hai fatto. Quello che ha detto @DrewJordan sull'acquistare dal capo è più importante di quanto tu possa immaginare.

Trova un difetto. Risolvi un difetto. Mostra la correzione.

Diamo prima la normalizzazione *. E in effetti, ti suggerirei di prenderlo per primo, perché la mancanza di normalizzazione potrebbe comportare dati errati reali che altrimenti non potrebbero esistere, 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, allora hai un posto dove i dati possono essere incoerenti.

È una buona scommessa che sarai in grado di trovare un caso reale di dati incoerenti. Ora hai trovato due cose:

1. Un bug nei tuoi dati.

2. Un bug negli schemi del database.

In realtà hai saputo prima del secondo 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 reali per resistere alla normalizzazione del database denormalizzato è che la questione di cosa fare con tali dati errati non è sempre facile, ma avrai trovato un vero bug.

(Tuttavia, tieni presente che ci sono ragioni per cui a volte potresti denormalizzare alcuni dati di proposito. Non confondere la violazione consapevole della regola per ignoranza della regola; se normalizzi una tabella deliberatamente denormalizzata per la velocità di ricerca, hai vinto non vincerà nessun complimento. Anche qui, però, denormalizzare l'essere irto è qualcosa che dovrebbe essere fatto in modo procedurale, quindi se la tabella denormalizzata non viene creata automaticamente in base al contenuto delle tabelle normalizzate, ci sono ancora progressi da fare).

Per il resto, presentali quando aiutano a breve termine, per costruirli successivamente a lungo termine. Ad esempio, se ti viene dato un piccolo pezzo di codice da compilare, scrivi un test unitario per esso. Meglio ancora, se ti viene dato un bug da correggere, scrivi un test unit che fallisce a causa del bug e poi quando hai risolto il bug menziona il fatto che passa quando chiudi i bug (o invia un'email dicendo che è stato corretto o qualunque altra cosa).

* Per inciso, non molto moderno. Il motivo è chiamato normalizzazione e non normalizzante o qualcos'altro, è che nel momento in cui era uno scherzo d'attualità per attaccare -ization sulla fine delle cose da prendere in giro il nome di Richard Nixon Vietnamizzazione politica.

Ho intenzione di andare controcorrente e dire: trova un nuovo lavoro dopo aver trascorso un po 'di tempo in questo per costruire un po' il tuo curriculum. Obiettivo per circa un anno. Sebbene molte cose siano "parole d'ordine", problemi come la completa mancanza di unit test sono intrattabili per un singolo sviluppatore, e le probabilità sono che se i programmatori che lavorano lì non hanno alcun desiderio di test, non otterrai mai l'acquisto e potresti persino compromettere la tua posizione in azienda facendo pensare a te come un duro. Devi essere in un posto dove puoi ottenere tutoraggio, non cercare 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ù alla moda ora sembrano essere una programmazione agile e orientata agli oggetti. O lo sono? Entrambi sono sbiaditi sostanzialmente rispetto a quello che erano solo cinque anni fa.

Puoi essere abbastanza sicuro che qualunque metodologia messa in atto stia cercando di ottenere lo stesso risultato finale: aiutare gli ingegneri a produrre economicamente un prodotto finale che sia abbastanza buono.

V'è un paradigma che è stato polemicamente introdotto nel 1960: programmazione strutturata : utilizzare solo "alto livello" costruisce come while, for, repeat, if/ then/ else, switch/ casedichiarazioni al posto del molto utilizzato gotodichiarazione che era stata accettata per impostazione predefinita. Ci sono ancora dibattiti sul fatto che gotonon ha alcun uso legittimo a tutti.

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

Citi le agilemetodologie come qualcosa di positivo. Sono stato in un team di sviluppo per circa sei mesi che ha seguito intenzionalmente un regime agile prescritto. L'ho trovato esattamente come metodologie di gestione del progetto illuminate di decenni fa, tranne per il fatto che tutto è stato rinominato. Forse riunendo e rivendendo idee per comunicare a qualcuno si guadagna da vivere e le aziende possono sentirsi bene nel "vedere" i nuovi vestiti dell'imperatore .

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

Da una scrittura del capobanda anti-goto Edsger Dijkstra:

L'arte della programmazione è l'arte di organizzare la complessità, padroneggiare la moltitudine ed evitare il suo caos bastardo nel modo più efficace possibile.

—Dijkstra, in: Dahl, Dijkstra e Hoare 1972, pag. 6. (vedi pagina 6 qui .)