Compiti tipici di uno sviluppatore Java su un progetto

Quali sono le responsabilità tipiche di uno sviluppatore Java? Dopotutto, devi capire cosa stai cercando e cosa farai alla fine, giusto? Oggi vorrei parlare dei dieci compiti principali che svolge uno sviluppatore Java. Ma prima conosciamo uno strumento come Jira. Oppure rinfreschiamoci la memoria se ti è già familiare. Jira è uno strumento di interazione con l'utente, sebbene in alcuni casi venga utilizzato anche per la gestione dei progetti. In altre parole, lo sviluppo del progetto è suddiviso in piccole attività descritte in questo strumento. Questi compiti vengono assegnati (assegnati) agli sviluppatori, che saranno responsabili della loro implementazione. Per attività intendiamo, ad esempio, l'aggiunta di alcune funzionalità. Man mano che i progressi avanzano, gli sviluppatori e altri specialisti aggiungono commenti su chi ha fatto cosa e quanto tempo hanno impiegato: tengono traccia del tempo. Questo viene fatto per tenere traccia del tempo trascorso: quanto è stato speso e per cosa. Idealmente, questo viene fatto una volta al giorno: la sera prima di partire, monitori le tue 8 ore sui compiti su cui le hai spese. Le funzionalità di Jira sono molto più ampie di quelle sopra descritte, ma questo basterà per una prima comprensione. Quindi, quali sono le responsabilità di uno sviluppatore Java?

1. Sviluppo di nuove soluzioni

Prima di creare e implementare qualcosa, devi inventarlo, giusto? Come ho detto, potrebbe essere semplicemente un compito di Jira che ti verrà assegnato e lavorerai per sviluppare una nuova soluzione, annotando in Jira quanto tempo hai dedicato e su cosa. Potrebbe trattarsi anche di una discussione su una team call di gruppo: ognuno potrà esprimere la propria opinione e proporre l'approccio che ritiene migliore. E qui vorrei sottolineare alcuni punti. In primo luogo, la professione di sviluppatore è un campo molto creativo, poiché è necessario trovare modi unici per risolvere i problemi utilizzando strumenti standard. Spesso lo stesso problema può avere molte soluzioni diverse: di conseguenza, tutto dipende dallo “spirito creativo” dello sviluppatore, dalla conoscenza e dall'esperienza accumulate. Qui puoi mostrare tutta la tua creatività e genialità, ma l'importante è non esagerare: in questo caso il codice diventerà troppo complesso e illeggibile e di conseguenza, dopo che te ne sarai andato, nessuno capirà appieno di cosa si tratta e come funziona. E dovrai riscrivere tutto da zero. E potrebbero ricordarsi di te. E più di una volta. Ed è improbabile che queste siano parole calde e gentili. Ne hai bisogno? In secondo luogo, lo sviluppatore deve essere flessibile, nel senso che non bisogna rimanere bloccati in una soluzione e chiudersi alle altre. Ad esempio, devi fare solo in questo modo e nient'altro. Ciò può accadere per vari motivi: ad esempio, vuoi dimostrare il tuo punto di vista, oppure hai già sviluppato e implementato la tua soluzione, alla quale sei molto affezionato e, ovviamente, non vuoi ammettere che non sia quella giusta. migliore. Questo può praticamente accecarti. Devi infatti saper ammettere i tuoi errori ed essere sempre aperto alle novità (“open-minded”), anche a costo di dover rimuovere funzionalità che scrivi da molte settimane e di cui sei molto fiero. Ricordo che una volta l'atmosfera dell'intera giornata fu creata dalla traccia del tempo di qualcuno in Jira con il commento: "Ho cancellato la mia funzionalità nata morta. Ho pianto"

2. Scrivere nuove funzionalità

Questo è un passo logico successivo al precedente: l'implementazione di nuove funzionalità. Tutto il lavoro sul progetto è suddiviso in attività in una jira, che gli sviluppatori ricevono mentre lavorano. Esistono diversi approcci a questo problema: "metodologie", di cui puoi leggere di più in questo articolo su JavaRush . Di norma, le attività hanno una "Stima" : il tempo previsto impiegato per il completamento. Viene impostato da te stesso quando assumi l'incarico, oppure dal responsabile del team, oppure durante la pianificazione lo valutano insieme gli sviluppatori. Questa volta è molto raramente indovinata con precisione, poiché molti fattori diversi influenzano lo sviluppo. Ad esempio, il programmatore ha familiarità o meno con questa tecnologia, qual è la sua esperienza generale, le varie insidie ​​che possono diventare visibili già durante lo sviluppo, ecc. Pertanto, se non rispetti questa scadenza durante lo sviluppo della funzionalità, non accadrà nulla di male. Queste sono solo stime generali. Ma ancora una volta, non tutti i progetti hanno stime di attività e, per quanto mi riguarda, è molto più facile farne a meno, soprattutto quando il Primo Ministro non ti prende di mira un paio di volte al giorno con la domanda “Dove sono le stime? " Di conseguenza, prendi un'attività, sviluppi la funzionalità necessaria, la carichi in un ramo comune in GIT e nella jira cambi lo stato dell'attività in "Pronto per la revisione" , cioè pronto per la visualizzazione (controllo) e preghi che non ti viene restituito con commenti sulla revisione.

3. Scrivere test di funzionalità

La persona che controlla il tuo codice, il revisore, ha apprezzato la funzionalità che hai sviluppato, ma ha una domanda: dove sono i test? E ti restituisce il compito per la revisione. I test sono una parte importante di qualsiasi applicazione Java. Eseguendoli, puoi immediatamente scoprire dove l'applicazione funziona in modo errato. Ad esempio, uno sviluppatore ha apportato alcune modifiche in una parte del sistema, che hanno portato a cambiamenti nel comportamento in un'altra, e non se ne è accorto durante lo sviluppo. Eseguendo i test potrà vedere i test falliti (quelli che non hanno funzionato correttamente). Questo gli dirà che qualcosa non funziona in un'altra parte del sistema. Pertanto, non caricherà modifiche importanti sul server, ma continuerà a perfezionare la sua soluzione. Sì, certo, pochi sviluppatori amano i test, ma non si può negare i vantaggi che apportano all'applicazione. Spesso i clienti stessi specificano quale livello di copertura del test dovrebbe essere rispettato (ad esempio, 80%). Pertanto, è necessario conoscere diversi tipi di test ed essere in grado di scriverli. Gli sviluppatori Java scrivono principalmente unit test e test di integrazione, mentre gli AQA (tester di automazione) si occupano di test più estesi (end-to-end). Puoi leggere di più su di loro e su altri rappresentanti delle professioni IT nella mia recensione .

4. Individuazione e correzione del bug

Anche questo è un compito molto comune e frequente per uno sviluppatore Java. Il compito principale del QA e dell'AQA è individuare i bug. Cioè, cercano i luoghi in cui il programma si comporta in modo errato, creano problemi in Jira e danno la colpa a qualcuno. Ad esempio, un team leader, che a sua volta decide a quale sviluppatore assegnarlo, a seconda del carico e della familiarità con questa parte del sistema. Successivamente, lo sviluppatore cerca il bug, trascorrendo ore nel debugger , utilizzando la descrizione del problema da parte degli specialisti del QA per ripetere la situazione in cui si è verificato il bug. Successivamente, lo sviluppatore trova un bug, lo corregge e lo invia per la revisione. Bene, è possibile che lo sviluppatore non sia riuscito a riprodurre il bug e restituisca l'attività allo specialista del QA con un commento al riguardo. Sembra che non ci vorrà molto tempo per trovare e correggere il bug, ma ci sono alcune sfumature. Tutto dipende principalmente dalla familiarità dello sviluppatore con questa sezione di codice, dall'esperienza e dalla conoscenza delle questioni teoriche. A volte un bug può essere trovato e risolto in 20 minuti, a volte possono essere necessari tre giorni. Di conseguenza, questo tipo di attività è particolarmente difficile da valutare in anticipo, a meno che lo sviluppatore, dopo aver letto la descrizione, non capisca immediatamente cosa, dove e con cosa è andato storto. In questo caso, sarà in grado di indovinare l'ora più o meno accuratamente.

5. Revisione del codice

Come accennato in precedenza, non appena si completa un'attività, questa deve essere inviata per la revisione e, se la supera, va nel thread generale, in caso contrario verrà restituita allo sviluppatore con commenti su ciò che deve essere corretto. È chiaro che tutto ciò non viene controllato da poteri superiori, ma da altri sviluppatori. Ma non tutti gli sviluppatori possono diventare revisori, ma solo quelli più esperti, che hanno esperienza alle spalle e sanno distinguere il codice cattivo da quello buono. La revisione del codice viene solitamente eseguita utilizzando uno strumento ausiliario, ad esempio Crucible . I revisori esaminano il codice e, se necessario, lasciano commenti sotto alcune righe. Anche i commenti possono essere di vario tipo. Ad esempio, quelli critici, senza la cui correzione il revisore non passerà il codice, e altri sono più probabilmente solo commenti sull'approccio scelto, che lo sviluppatore può ascoltare, prendere nota o ignorare. Il team può creare la propria procedura e regole per condurre le revisioni, concordare cosa vale la pena prestare attenzione e cosa no, entro quale arco di tempo deve essere effettuata la revisione del codice, ecc. Per condurre una revisione, l'esperienza da sola non è sufficiente: è necessario sviluppare ancora molto in direzione tecnica, leggere vari libri (ad esempio "Clean Code" ). Se sei interessato alle sfumature della conduzione di una revisione del codice secondo Google, ti consiglio di leggere questo articolo .

6. Analisi del codice

Poiché il progetto è scritto simultaneamente da più persone che la pensano diversamente, il loro codice e i loro approcci saranno diversi. E col tempo, tutto si trasformerà gradualmente in poltiglia. Per migliorare il codice, a volte si creano attività da analizzare, magari un particolare modulo o l'intera applicazione, per trovare difetti e segnalarli, e successivamente creare un'attività di refactoring basata su questi commenti. L'analisi aiuta anche in situazioni in cui alcune scorciatoie più semplici non erano visibili dall'inizio dello sviluppo, ma possono essere viste ora. Ad esempio, la stessa logica viene spesso ripetuta in alcuni metodi e, di conseguenza, può essere spostata in un metodo separato e riutilizzata più volte. Bene, o qualche classe è diventata dolorosamente gonfia, o qualche codice è diventato difficile da mantenere o è obsoleto, oppure... Le attività di analisi aiutano a migliorare la qualità del codice e dell'applicazione. Anche se, secondo me, analizzare una grande quantità di codice può essere un compito noioso.

7. Refactoring del codice

La parte successiva dell'analisi è il refactoring del codice. Potrebbe essere obsoleto, non più necessario, scritto male, difficile da leggere e così via. Dovresti sempre tendere alla perfezione (anche se non esiste) e al codice aggiornato, rimuovendo tutto ciò che non è necessario, perché questo confonde e ti impedisce solo di vedere l'essenza della funzionalità. Inutile dire che difficilmente vedrai questi compiti all'inizio del progetto: si verificano solo nelle fasi successive dello sviluppo, quando l'applicazione è rifinita e portata alla perfezione. In questo caso, potrebbe essere opportuno consultare i colleghi su come lo farebbero e quali insidie ​​vedono. L'essenza di tali compiti è simile allo sviluppo di nuove funzionalità. Ad esempio, ricevi un'attività per modificare alcune funzionalità senza modificarne il comportamento. Per fare ciò, elimini quello vecchio, scrivi il tuo e controlla i test. Se avete fatto tutto correttamente, senza apportare modifiche ai test, dovrebbero funzionare come prima. Dopo che tutto è stato sistemato nel codice, lo inviamo per la revisione e andiamo a prendere un caffè))

8. Scrivere documentazione

Immagina di essere un nuovo sviluppatore di un progetto in sviluppo da molto tempo. È necessario familiarizzare con esso o eseguire alcune attività specifiche, ad esempio individuare un bug. Come navigherai nel progetto? Ritira i membri della tua squadra ogni cinque minuti? E se sono occupati o nel fine settimana, cosa succede allora? Per questo motivo esiste la documentazione, in modo che una persona che non ha familiarità con la funzionalità possa entrare, trovare la pagina giusta e capire rapidamente cosa fa la parte dell'applicazione che gli interessa. Ma qualcuno deve anche compilare la documentazione ^^ Se il progetto ha documentazione che gli sviluppatori devono supportare, quando implementano nuove funzionalità la descrivono e con varie modifiche e refactoring aggiornano la documentazione. Sono possibili anche situazioni in cui uno specialista separato, un redattore tecnico, viene assunto per scrivere, supportare e controllare la documentazione. Se uno specialista del genere esiste, renderebbe la vita degli sviluppatori ordinari un po’ più semplice.

9. Partecipazione a varie manifestazioni

Gli sviluppatori dedicano molto tempo a varie riunioni, trattative e pianificazione. L'esempio più semplice sono le "riunioni giornaliere" (riunioni giornaliere), in cui devi dire cosa hai fatto ieri e cosa farai oggi. Inoltre, è necessario avere una chiamata individuale, ad esempio, con uno specialista del QA, in modo che possa mostrare/spiegare le sfumature della riproduzione del bug o discutere le sfumature e i requisiti con un analista aziendale o un'organizzazione problemi con un PM. Pertanto, anche se uno sviluppatore può essere un introverso che preferisce la solitudine, deve comunque essere in grado di trovare un linguaggio comune con altre persone (beh, almeno un po'). Più alto è il grado di uno sviluppatore, più tempo dovrà dedicare alla comunicazione e meno tempo alla scrittura del codice. Il leader di un team di sviluppatori può anche dedicare metà, o anche più, del suo tempo di lavoro a conversazioni e riunioni e a scrivere codice meno spesso (questo può portare a perdere un po' di presa). Ma se sei anche qualcuno a cui piace parlare, puoi facilmente passare dalla posizione di team leader a quella manageriale e dimenticarti completamente del codice, comunicando tutto il giorno con vari team, clienti e altri manager.

10. Condurre/superare un colloquio

Se lavori per un'azienda di outsourcing o di outstaffing, dovrai sottoporsi a frequenti colloqui esterni, quando hai bisogno di essere “venduto” al cliente (poi potrai essere intervistato da una persona dalla parte del cliente), e colloqui interni, per aumentare il tuo rango all'interno dell'azienda. Lo definirei un buon fattore di sviluppo, poiché a causa dei frequenti colloqui, le tue conoscenze dovrebbero essere sempre in forma: non ti arrugginirai e ti rilasserai, perché se ti rilassi nell'IT, puoi volare completamente fuori dal campo. Quando diventerai uno sviluppatore più esperto, sarai in grado di visitare l'altro lato: non passare, ma condurre interviste. Credimi, rimarrai molto sorpreso se lo guardi da questa prospettiva, perché condurre un colloquio può essere più spaventoso che passare. Devi avere la tua strategia per il colloquio, un elenco di domande e avere il tempo di porre domande su tutti gli argomenti necessari in un'ora. E dopodiché, sei responsabile del feedback, perché, basandosi su di esso, una persona può o meno ricevere un'offerta o una promozione così tanto attesa. Ebbene, e viceversa: puoi perdere un candidato francamente debole per una posizione per la quale non corrisponde, e poi ti potrebbe essere chiesto: come hai fatto a mancarlo con un tale livello di conoscenza? Pertanto, quando affronti un colloquio, tieni presente che anche la persona di fronte a te sta attraversando un momento difficile e potrebbe anche provare stress. Qualsiasi colloquio è stressante sia per il candidato che per l'intervistatore. Forse finiremo qui. Grazie a tutti coloro che hanno finito di leggere: mettono mi piace e imparano Java ^^