Attività tipiche di uno sviluppatore Java su un progetto

Quali sono le responsabilità tipiche di uno sviluppatore Java? Dopotutto, devi capire in cosa ti stai cacciando e cosa finirai per fare, giusto? Oggi vorrei parlare di dieci compiti vitali che esegue uno sviluppatore Java. Ma prima, facciamo conoscenza con uno strumento chiamato Jira. Oppure rinfrescatene la memoria, se già lo conoscete. Jiraè uno strumento per organizzare le interazioni umane, anche se in alcuni casi viene utilizzato anche per la gestione dei progetti. In altre parole, un progetto è suddiviso in piccole attività descritte in questo strumento. Questi compiti sono assegnati agli sviluppatori, che sono responsabili della loro implementazione. Un'attività potrebbe essere, ad esempio, l'aggiunta di alcune funzionalità. Man mano che un'attività viene eseguita, gli sviluppatori e altri specialisti aggiungono commenti su chi ha fatto cosa e quanto tempo ha trascorso. Questo viene fatto per scopi di monitoraggio del tempo, per sapere quanto tempo è stato speso per quali attività. Idealmente, questo viene fatto una volta al giorno: prima di lasciare la scrivania la sera, indichi quante delle tue 8 ore lavorative hai dedicato a vari compiti. C'è molto di più nella funzionalità di Jira rispetto a quanto descritto sopra, ma questo sarà sufficiente per una comprensione iniziale.

1. Progettare nuove soluzioni

Prima di creare e implementare qualcosa, devi concettualizzarlo, giusto? Come ho detto prima, questo potrebbe essere semplicemente un compito in Jira che ti viene assegnato, quindi lavori per progettare una nuova soluzione, registrando in Jira quanto tempo hai speso e su cosa. Questo lavoro potrebbe avvenire anche durante una discussione in una teleconferenza di gruppo: ognuno può esprimere la propria opinione e proporre l'approccio che ritiene migliore. E qui vorrei notare alcuni punti. Innanzitutto, lo sviluppo di software è una professione molto creativa, poiché è necessario utilizzare strumenti standard per trovare nuovi modi di risolvere i problemi. Un'attività può spesso avere molte soluzioni diverse. Di conseguenza, tutto dipende dalla creatività dello sviluppatore, che è fortemente influenzata dalla conoscenza e dall'esperienza accumulate. Puoi mostrare tutta la tua creatività e il tuo genio qui, ma l'importante è non esagerare. Se lo fai, il codice diventerà troppo complesso e illeggibile. Di conseguenza, dopo che te ne sei andato, nessuno capirà appieno cosa hai codificato e come funziona. E dovranno riscrivere tutto da zero. E potrebbero ricordarti di te. Più di una volta. Ed è improbabile che vengano pronunciate parole calde e gentili. Ne hai bisogno? In secondo luogo, uno sviluppatore deve mantenere la flessibilità psicologica, nel senso che non dovresti aggrapparti a un'unica soluzione e diventare chiuso nei confronti degli altri. Come se dovessi fare qualcosa in un solo modo e non ci fossero altre opzioni. Potresti cadere in questa trappola per vari motivi. Ad esempio, supponi di voler dimostrare che il tuo punto di vista è corretto. O forse hai già progettato e implementato la tua soluzione familiare - ovviamente, non vorrai ammettere che non è il massimo. Queste situazioni possono renderti abbastanza cieco. In effetti, devi essere in grado di ammettere i tuoi errori ed essere sempre di mentalità aperta, anche se devi rimuovere funzionalità di cui sei orgoglioso e che stai programmando da più di una settimana. Ricordo come un collega ha illuminato la giornata di tutti una volta lasciando questo commento di tracciamento del tempo in Jira: "Ho rimosso la mia caratteristica nata morta. E ho pianto."

2. Scrittura di nuove funzionalità

Questo passaggio, l'implementazione di nuove funzionalità, segue logicamente il precedente. Tutto il lavoro coinvolto in un progetto è suddiviso in attività in Jira, che vengono poi assegnate agli sviluppatori in base al loro carico di lavoro. Esistono diversi approcci a questo processo, noti come "metodologie", di cui puoi leggere in dettaglio in questo articolo su CodeGym . Di norma, le attività hanno una stima, che è il tempo previsto necessario per completarli. Viene impostato da te, lo sviluppatore quando ricevi l'attività, o dal responsabile del team, o durante la pianificazione, collettivamente dal team di sviluppo. Questa ipotesi temporale è molto raramente accurata, poiché così tanti fattori diversi influenzano lo sviluppo del software. Ad esempio, se un programmatore ha familiarità o meno con la tecnologia pertinente, la sua esperienza complessiva, varie insidie ​​imprevedibili, ecc. Quindi, se non raggiungi tutte le tue stime di tempo durante la codifica, non è la fine del mondo. Queste sono solo stime generali. Detto questo, non tutti i progetti richiedono una stima del tempo. Personalmente, trovo molto più facile vivere senza di essa, specialmente quando il Primo Ministro non mi assilla un paio di volte al giorno con la domanda "dove sono le tue stime di tempo?" Quindi, ottieni un compito,Pronto per la revisione " in Jira e prega che le modifiche al codice non vengano restituite per la revisione insieme ai commenti.

3. Test di scrittura

Il revisore, cioè la persona che controlla il tuo codice, apprezza la funzionalità che hai implementato, ma ha una domanda per te: dove sono i test associati? Quindi ti rimanda l'attività per la revisione. I test sono una parte essenziale di qualsiasi applicazione Java. Eseguendo i test, puoi identificare immediatamente i punti in cui l'applicazione non funziona correttamente. Ad esempio, uno sviluppatore apporta alcune modifiche in una parte del sistema, il che si traduce in cambiamenti nel comportamento in un'altra parte, ma non se ne è accorto durante la codifica. Eseguendo i test, sarà in grado di vedere che alcuni test sono falliti, nel senso che non hanno prodotto i risultati attesi. Questo gli dice che qualcosa è rotto da qualche altra parte nel sistema. Sapendo questo, non eseguirà il commit delle modifiche sostanziali al server e continuerà invece a lavorare sul debug del suo codice. SÌ, piuttosto pochi sviluppatori amano scrivere test, ma non si possono negare i vantaggi che apportano allo sviluppo del software. I clienti stessi spesso indicano il livello di copertura del test che desiderano mantenere (ad esempio, 80%). Ciò significa che devi saperei vari tipi di test ed essere in grado di scriverli. Gli sviluppatori Java scrivono principalmente unit test e test di integrazione, mentre i test più estesi (end-to-end) sono gestiti da esperti di controllo qualità e automazione dei test.

4. Trovare e correggere bug

Questa è anche un'attività molto comune e frequente per gli sviluppatori Java. Il compito principale degli esperti di controllo qualità e automazione dei test è rilevare i bug. In altre parole, cercano luoghi in cui il programma si comporta in modo errato, quindi creano attività in Jira e le assegnano a qualcuno. Ad esempio, a un responsabile del team, che, a sua volta, decide a quali sviluppatori assegnarli, in base al loro carico di lavoro e alla familiarità con le parti rilevanti del sistema. Successivamente, lo sviluppatore assegnato scova la causa principale del bug, trascorrendo ore in un debugger, utilizzando la descrizione del bug fornita dagli esperti QA per riprodurre le condizioni in cui si verifica il bug. Una volta che lo sviluppatore trova il bug e lo corregge, invia la correzione per la revisione. A volte lo sviluppatore non è in grado di riprodurre il bug, quindi rimanda l'attività all'esperto QA insieme a un commento esplicativo. Sembra che non dovrebbe volerci molto tempo per trovare e correggere un bug, ma ci sono alcune sfumature. Tutto dipende principalmente da quanto lo sviluppatore conosce bene questa sezione del codice e dalla sua esperienza e conoscenza teorica. A volte un bug può essere trovato e risolto in 20 minuti, a volte possono essere necessari tre giorni. Ciò significa che questo tipo di attività è particolarmente difficile da stimare in anticipo, a meno che lo sviluppatore, dopo aver letto la descrizione, capisca immediatamente cosa, dove e come del bug. In questo caso,

5. Revisione del codice

Come accennato in precedenza, non appena completi un'attività, dovrebbe essere inviata per la revisione. Se supera la revisione, passa al ramo principale. In caso contrario, viene restituito allo sviluppatore con i commenti che devono essere affrontati. Ovviamente, capisci che il tuo codice è tutto controllato da altri sviluppatori, non da un potere elevato. Detto questo, non tutti sono autorizzati a eseguire revisioni del codice: solo gli sviluppatori più esperti, temprati dalla pratica del mondo reale, che possono distinguere tra codice buono e codice cattivo. Le revisioni del codice vengono solitamente eseguite utilizzando uno strumento di supporto come Crucible. I revisori esaminano il codice e, se necessario, lasciano commenti su determinate righe. Ci possono essere vari tipi di commenti. Ad esempio, alcuni sono critici. Se non vengono affrontati, il revisore non consentirà il commit del codice. Altri commenti sono, ad esempio, semplici commenti sull'approccio scelto. Questi lo sviluppatore può ascoltare, prendere nota o ignorare. Un team può creare le proprie regole e procedure per le revisioni del codice, concordando su cosa vale la pena prestare attenzione e cosa no, quale periodo di tempo dovrebbe essere assegnato per completare una revisione del codice, ecc. L'esperienza da sola non è sufficiente per condurre una revisione: devi ancora bisogno di crescere molto nelle tue capacità tecniche e di leggere vari libri (ad esempio, "Clean Code").

6. Analisi del codice

Poiché diverse persone che la pensano in modo diverso scrivono simultaneamente il codice per il progetto, il loro codice e i loro approcci saranno diversi. E nel tempo, tutto si trasforma gradualmente in un disastro. Per migliorare il codice, a volte vengono create attività per, ad esempio, analizzare un determinato modulo o l'intera applicazione, trovare e prendere nota delle carenze e successivamente creare un'attività di refactoring basata su questa analisi. Tale analisi aiuta anche in situazioni in cui, all'inizio dello sviluppo, il team non riusciva a vedere alcune soluzioni più semplici e concise, ma le vede ora. Ad esempio, la logica è spesso duplicata in alcuni metodi. Di conseguenza, può essere estratto in un metodo separato, che può quindi essere riutilizzato più volte. O forse una classe è diventata troppo gonfia, o qualche codice è diventato difficile da mantenere o obsoleto, o... Le attività di analisi aiutano a migliorare la qualità del codice e dell'applicazione. Detto questo, per me analizzare una grande quantità di codice può essere noioso.

7. Codice di refactoring

La parte successiva dell'analisi del codice è il refactoring. Il codice può essere obsoleto, obsoleto, 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 è superfluo, perché il superfluo porta solo confusione e interferisce con la capacità di vedere cosa sta facendo il codice. Inutile dire che è improbabile che tu veda queste attività all'inizio di un progetto: le incontri nelle fasi successive dello sviluppo, quando l'applicazione viene rifinita e portata alla perfezione. Qui, potrebbe essere opportuno consultare i colleghi su cosa farebbero e quali insidie ​​vedono. Fondamentalmente, tali compiti sono simili allo sviluppo di nuove funzionalità. Ad esempio, supponi di ricevere un'attività per modificare alcune funzionalità senza modificarne il comportamento. Per fare ciò, elimini il vecchio codice, scrivi il tuo e controlli i test. Se hai fatto tutto bene, senza apportare modifiche ai test, dovrebbero passare tutti come prima. Dopo che tutto nel codice è come dovrebbe essere, lo inviamo per una revisione e andiamo a sorseggiare un caffè :)

8. Stesura della documentazione

Immagina di essere un nuovo sviluppatore in un progetto di sviluppo software a lungo termine. Devi familiarizzare con la base di codice o eseguire alcune attività specifiche, ad esempio diagnosticare un bug. Come navigherai nel progetto? Infastidire i tuoi compagni di squadra ogni cinque minuti? E se sono occupati o è il fine settimana, cosa succede allora? Questo è esattamente il motivo per cui abbiamo la documentazione, in modo che una persona che non ha familiarità con il codice possa entrare, trovare la pagina pertinente e capire rapidamente cosa sta succedendo nella parte dell'applicazione che le interessa. Ma qualcuno deve creare la documentazione, haha. Se un progetto ha una documentazione che gli sviluppatori devono supportare, quando implementano una nuova funzionalità, la descrivono e aggiornano la documentazione insieme a eventuali modifiche al codice o refactoring. Puoi anche avere situazioni in cui un dipendente separato, un redattore tecnico, viene assunto per scrivere, mantenere e supervisionare la documentazione. Se è disponibile un tale specialista, la vita degli sviluppatori ordinari è un po' più semplice.

9. Incontri vari

Gran parte del tempo degli sviluppatori viene speso in varie riunioni, negoziazioni e pianificazione. L'esempio più semplice è la riunione quotidiana in piedi, in cui devi riferire cosa hai fatto ieri e cosa farai oggi. Inoltre, dovrai avere telefonate individuali, ad esempio, con i tester, in modo che possano dimostrare/spiegare le sfumature della riproduzione di un bug, o discutere le sottigliezze e i requisiti con un analista aziendale o parlare di problemi organizzativi con un PM. Ciò significa che sebbene uno sviluppatore possa essere un introverso che preferisce la solitudine, deve comunque essere in grado di trovare un terreno comune con altre persone (beh, almeno un po'). Più alto è il grado di uno sviluppatore, più tempo deve dedicare alla comunicazione e meno tempo a scrivere codice. Un responsabile dello sviluppo può trascorrere metà, o anche di più, della sua giornata lavorativa in conversazioni e riunioni da solo e può scrivere codice meno spesso (probabilmente facendogli perdere un po' della sua abilità di codifica). Ma se ami semplicemente parlare, potresti, come team leader, passare alla gestione e dimenticarti completamente di scrivere codice, invece, passeresti tutto il giorno a comunicare con vari team, clienti e altri manager.

10. Condurre/passare interviste

Se lavori per un'azienda di outsourcing o outstaffing, dovrai spesso sostenere colloqui esterni, in cui dovrai "venderti" al cliente (potresti essere intervistato da qualcuno che lavora per il cliente), così come interni quelli di scalare i ranghi all'interno dell'azienda. La definirei una buona opportunità di crescita perché i frequenti colloqui ti costringeranno a mantenere affilate le tue conoscenze: non diventerai arrugginito e molle. Dopotutto, se diventi debole nell'IT, puoi cadere completamente fuori dal campo. Man mano che diventi uno sviluppatore più esperto, sarai in grado di trovarti dall'altra parte del tavolo, conducendo interviste piuttosto che superarle. Credimi, rimarrai molto sorpreso quando lo guardi da questa posizione, perché fare domande durante l'intervista può essere più spaventoso che rispondere. Devi avere la tua strategia di colloquio, un elenco di domande e il tempo per porre domande su tutti gli argomenti necessari in un'ora. Successivamente, sei responsabile di fornire un feedback che influenzerà la decisione di assunzione e se il candidato riceve un'offerta o una promozione tanto attesa. Oppure, potresti consentire a un candidato ovviamente debole di ottenere una posizione per la quale non si qualifica, e poi ti potrebbe essere chiesto: "come hai potuto permetterle di essere assunta con quel livello di conoscenza"? Quindi, quando sei in una posizione privilegiata durante un colloquio, tieni presente che anche la persona di fronte a te sta affrontando una sfida e potrebbe essere stressata. sei responsabile di fornire un feedback che influenzerà la decisione di assunzione e se il candidato riceve un'offerta o una promozione tanto attesa. Oppure, potresti consentire a un candidato ovviamente debole di ottenere una posizione per la quale non si qualifica, e poi ti potrebbe essere chiesto: "come hai potuto permetterle di essere assunta con quel livello di conoscenza"? Quindi, quando sei in una posizione privilegiata durante un colloquio, tieni presente che anche la persona di fronte a te sta affrontando una sfida e potrebbe essere stressata. sei responsabile di fornire un feedback che influenzerà la decisione di assunzione e se il candidato riceve un'offerta o una promozione tanto attesa. Oppure, potresti consentire a un candidato ovviamente debole di ottenere una posizione per la quale non si qualifica, e poi ti potrebbe essere chiesto: "come hai potuto permetterle di essere assunta con quel livello di conoscenza"? Quindi, quando sei in una posizione privilegiata durante un colloquio, tieni presente che anche la persona di fronte a te sta affrontando una sfida e potrebbe essere stressata. Qualsiasi colloquio è stressante sia per il candidato che per l'intervistatore. Probabilmente finiremo proprio qui. Grazie a tutti coloro che hanno letto questo articolo. Lascia un like e continua ad imparare Java :)