Tarefas típicas de um desenvolvedor Java em um projeto

Quais são as responsabilidades típicas de um desenvolvedor Java? Afinal, você precisa entender no que está se metendo e o que vai acabar fazendo, certo? Hoje eu gostaria de falar sobre dez tarefas vitais que um desenvolvedor Java executa. Mas primeiro, vamos nos familiarizar com uma ferramenta chamada Jira. Ou refresque sua memória, se você já estiver familiarizado com ele. Jiraé uma ferramenta para organizar as interações humanas, embora em alguns casos também seja usado para gerenciamento de projetos. Ou seja, um projeto é dividido em pequenas tarefas que são descritas nesta ferramenta. Essas tarefas são atribuídas aos desenvolvedores, que são responsáveis ​​por sua implementação. Uma tarefa pode ser, por exemplo, adicionar alguma funcionalidade. À medida que uma tarefa é executada, os desenvolvedores e outros especialistas adicionam comentários sobre quem fez o quê e quanto tempo gastaram. Isso é feito para fins de controle de tempo – para saber quanto tempo foi gasto em quais tarefas. Idealmente, isso é feito uma vez por dia: antes de sair de sua mesa à noite, você indica quanto de suas 8 horas de trabalho você gastou em várias tarefas. Há muito mais na funcionalidade do Jira do que o descrito acima, mas isso será suficiente para um entendimento inicial.

1. Projetando novas soluções

Antes de criar e implementar algo, você precisa conceituá-lo, certo? Como eu disse antes, isso pode ser simplesmente uma tarefa no Jira atribuída a você, então você trabalha para projetar uma nova solução, registrando no Jira quanto tempo você gastou e em quê. Esse trabalho também pode acontecer durante uma discussão em uma teleconferência da equipe: todos podem expressar sua opinião e propor a abordagem que considerarem melhor. E aqui eu gostaria de observar alguns pontos. Em primeiro lugar, o desenvolvimento de software é uma profissão muito criativa, pois você precisa usar ferramentas padrão para criar novas formas de resolver problemas. Uma tarefa geralmente pode ter muitas soluções diferentes. Assim, tudo depende da criatividade do desenvolvedor, que é fortemente influenciada pelo conhecimento e experiência acumulados. Você pode mostrar toda a sua criatividade e genialidade aqui, mas o importante é não exagerar. Se fizer isso, o código ficará muito complexo e ilegível. Como resultado, depois que você sair, ninguém entenderá totalmente o que você codificou e como funciona. E eles terão que reescrever tudo do zero. E eles podem se lembrar de você. Mais de uma vez. E é improvável que palavras calorosas e gentis sejam ditas. Você precisa disso? Em segundo lugar, um desenvolvedor deve manter a flexibilidade psicológica no sentido de que você não deve se apegar a uma única solução e fechar a mente para os outros. Como se você tivesse que fazer algo de apenas uma maneira e não houvesse outras opções. Você pode cair nessa armadilha por vários motivos. Por exemplo, suponha que você queira provar que seu ponto de vista está correto. Ou talvez você já tenha projetado e implementado sua própria solução familiar - é claro, você não gostaria de admitir que não é o melhor. Essas situações podem deixá-lo bastante cego. Na verdade, você precisa ser capaz de admitir seus erros e estar sempre com a mente aberta, mesmo que tenha que remover uma funcionalidade da qual se orgulha e que está codificando há mais de uma semana. Lembro-me de como um colega de trabalho iluminou o dia de todos deixando este comentário de controle de tempo no Jira: "Eu removi minha característica de natimorto. E lamentei."

2. Escrever novas funcionalidades

Esta etapa — implementação da nova funcionalidade — segue logicamente a anterior. Todo o trabalho envolvido em um projeto é dividido em tarefas no Jira, que são distribuídas aos desenvolvedores com base em sua carga de trabalho. Existem diferentes abordagens para esse processo, conhecidas como "metodologias", sobre as quais você pode ler mais detalhadamente neste artigo no CodeGym . Em regra, as tarefas têm uma estimativa, que é o tempo previsto necessário para completá-los. Ele é definido por você, o desenvolvedor quando recebe a tarefa, ou pelo líder da equipe, ou durante o planejamento, coletivamente pela equipe de desenvolvimento. Essa estimativa de tempo raramente é precisa, já que muitos fatores diferentes afetam o desenvolvimento de software. Por exemplo, se um programador está familiarizado ou não com a tecnologia relevante, sua experiência geral, várias armadilhas imprevisíveis, etc. Portanto, se você não atingir todas as suas estimativas de tempo ao codificar, não é o fim do mundo. Estas são apenas estimativas gerais. Dito isso, nem todos os projetos exigem estimativa de tempo. Pessoalmente, acho muito mais fácil viver sem ele, especialmente quando o PM não está me importunando algumas vezes ao dia com a pergunta "onde estão suas estimativas de tempo?" Então, você recebe uma tarefa,Pronto para revisão " no Jira e reze para que suas alterações de código não sejam devolvidas para revisão junto com os comentários.

3. Testes de redação

O revisor, ou seja, a pessoa que verifica seu código, gosta da funcionalidade que você implementou, mas tem uma pergunta para você: onde estão os testes associados? Então ela envia a tarefa de volta para você para revisão. Os testes são uma parte essencial de qualquer aplicativo Java. Ao executar testes, você pode identificar imediatamente locais onde o aplicativo não funciona corretamente. Por exemplo, um desenvolvedor faz algumas alterações em uma parte do sistema, o que resulta em mudanças de comportamento em outra parte, mas ele não percebeu isso durante a codificação. Ao executar os testes, ele poderá ver que determinados testes falharam, ou seja, não produziram os resultados esperados. Isso diz a ele que algo está quebrado em algum outro lugar do sistema. Sabendo disso, ele não confirmará as alterações importantes no servidor e, em vez disso, continuará trabalhando na depuração de seu código. Sim, poucos desenvolvedores adoram escrever testes, mas não há como negar os benefícios que eles trazem para o desenvolvimento de software. Os próprios clientes geralmente indicam o nível de cobertura do teste que desejam manter (por exemplo, 80%). Isso significa que você precisa saberos vários tipos de testes e ser capaz de escrevê-los. Os desenvolvedores Java escrevem principalmente testes de unidade e testes de integração, enquanto os testes mais extensos (de ponta a ponta) são tratados por especialistas em controle de qualidade e automação de teste.

4. Encontrar e corrigir bugs

Essa também é uma tarefa muito comum e frequente para desenvolvedores Java. O principal trabalho dos especialistas em controle de qualidade e automação de teste é detectar bugs. Em outras palavras, eles procuram lugares onde o programa se comporta incorretamente, então criam tarefas no Jira e as atribuem a alguém. Por exemplo, para um líder de equipe, que, por sua vez, decide a quais desenvolvedores atribuí-los, dependendo de sua carga de trabalho e familiaridade com as partes relevantes do sistema. Depois disso, o desenvolvedor designado procura a causa raiz do bug, passando horas em um depurador, usando a descrição do bug fornecida pelos especialistas em controle de qualidade para reproduzir as condições em que o bug ocorre. Depois que o desenvolvedor encontra o bug e o corrige, ele envia a correção para revisão. Às vezes, o desenvolvedor não consegue reproduzir o bug, então ele envia a tarefa de volta ao especialista em controle de qualidade junto com um comentário explicativo. Parece que não deve demorar muito para encontrar e corrigir um bug, mas existem algumas nuances. Tudo depende principalmente de quão bem o desenvolvedor está familiarizado com esta seção do código e de sua experiência e conhecimento teórico. Às vezes, um bug pode ser encontrado e corrigido em 20 minutos e, às vezes, pode levar três dias. Isso significa que esse tipo de tarefa é especialmente difícil de estimar com antecedência, a menos que o desenvolvedor, ao ler a descrição, entenda imediatamente o quê, onde e como do bug. Nesse caso,

5. Revisão do código

Conforme mencionado acima, assim que você concluir uma tarefa, ela deve ser enviada para revisão. Se passar na revisão, vai para o ramo principal. Caso contrário, ele é devolvido ao desenvolvedor com comentários que precisam ser abordados. Claro, você entende que seu código é todo verificado por outros desenvolvedores, não por algum poder superior. Dito isso, nem todo mundo tem permissão para realizar revisões de código - apenas os desenvolvedores mais experientes, endurecidos pela prática do mundo real, que podem dizer a diferença entre um código bom e um código ruim. As revisões de código geralmente são realizadas usando uma ferramenta auxiliar, como o Crucible. Os revisores analisam o código e, se necessário, deixam comentários sobre determinadas linhas. Pode haver vários tipos de comentários. Por exemplo, alguns são críticos. Se eles não forem endereçados, o revisor não permitirá que o código seja confirmado. Outros comentários são, digamos, simplesmente comentários sobre a abordagem escolhida. Estes, o desenvolvedor pode ouvir, anotar ou ignorar. Uma equipe pode criar suas próprias regras e procedimentos para revisões de código, concordando sobre o que vale a pena prestar atenção e quais não, qual prazo deve ser alocado para concluir uma revisão de código, etc. A experiência sozinha não é suficiente para realizar uma revisão: você ainda precisa crescer muito em suas habilidades técnicas e ler vários livros (por exemplo, "Código Limpo").

6. Análise de código

Como várias pessoas que pensam de forma diferente escrevem código para o projeto simultaneamente, seus códigos e abordagens serão diferentes. E com o tempo, tudo gradualmente se transforma em uma bagunça. Para melhorar o código, às vezes são criadas tarefas para, digamos, analisar um determinado módulo ou o aplicativo inteiro, encontrar e anotar deficiências e, posteriormente, criar uma tarefa de refatoração com base nessa análise. Essa análise também ajuda em situações em que, quando o desenvolvimento começou, a equipe não conseguia ver algumas soluções mais simples e concisas, mas as vê agora. Por exemplo, a lógica é frequentemente duplicada em alguns métodos. Conseqüentemente, ele pode ser extraído em um método separado, que pode ser reutilizado várias vezes. Ou talvez uma classe tenha ficado muito inchada, ou algum código tenha se tornado difícil de manter ou desatualizado, ou... Tarefas de análise ajudam a melhorar a qualidade do código e do aplicativo. Dito isso, para mim, analisar uma grande quantidade de código pode ser chato.

7. Refatoração de código

A próxima parte da análise de código é a refatoração. O código pode estar desatualizado, obsoleto, mal escrito, difícil de ler e assim por diante. Você deve sempre buscar a perfeição (embora ela não exista) e o código atualizado, removendo tudo o que for supérfluo, porque o supérfluo só leva à confusão e interfere na capacidade de ver o que o código está fazendo. Nem é preciso dizer que é improvável que você veja essas tarefas no início de um projeto: você as encontra em estágios posteriores de desenvolvimento, quando o aplicativo está sendo polido e levado à perfeição. Aqui, pode ser apropriado consultar colegas de trabalho sobre o que eles fariam e quais armadilhas eles veem. No fundo, essas tarefas são semelhantes ao desenvolvimento de novas funcionalidades. Por exemplo, suponha que você receba uma tarefa para editar alguma funcionalidade sem alterar seu comportamento. Para fazer isso, você exclui o código antigo, escreve o seu próprio e verifica os testes. Se você fez tudo certo, sem fazer nenhuma alteração nos testes, todos devem passar como antes. Depois que tudo no código estiver como deveria estar, enviamos para uma revisão e vamos tomar um café :)

8. Documentação escrita

Imagine que você é um novo desenvolvedor em algum projeto de desenvolvimento de software de longo prazo. Você precisa se familiarizar com a base de código ou executar alguma tarefa específica, por exemplo, diagnosticar um bug. Como você vai navegar no projeto? Perseguir seus companheiros de equipe a cada cinco minutos? E se eles estiverem ocupados ou for fim de semana? É exatamente por isso que temos documentação — para que uma pessoa que não esteja familiarizada com o código possa entrar, encontrar a página relevante e descobrir rapidamente o que está acontecendo na parte do aplicativo que lhe interessa. Mas alguém tem que criar a documentação, haha. Se um projeto tiver documentação que os desenvolvedores devem suportar, então, quando eles implementam uma nova funcionalidade, eles a descrevem e atualizam a documentação junto com qualquer alteração ou refatoração de código. Você também pode ter situações em que um funcionário separado — um redator técnico — é contratado para redigir, manter e supervisionar a documentação. Se tal especialista estiver disponível, a vida dos desenvolvedores comuns é um pouco mais fácil.

9. Várias reuniões

Muito tempo dos desenvolvedores é gasto em várias reuniões, negociações e planejamento. O exemplo mais simples é o stand-up meeting diário, onde você precisa relatar o que fez ontem e o que vai fazer hoje. Além disso, você precisará fazer ligações telefônicas individuais, por exemplo, com testadores, para que eles possam demonstrar/explicar as nuances da reprodução de um bug, ou discutir as sutilezas e requisitos com um analista de negócios ou falar sobre questões organizacionais com PM. Isso significa que, embora um desenvolvedor possa ser um introvertido que prefere a solidão, ele ainda precisa ser capaz de encontrar um terreno comum com outras pessoas (bem, pelo menos um pouco). Quanto maior a classificação de um desenvolvedor, mais tempo ele precisa gastar em comunicação e menos tempo escrevendo código. Um líder de desenvolvimento pode gastar metade, ou até mais, de seu dia de trabalho apenas em conversas e reuniões e pode escrever código com menos frequência (possivelmente fazendo com que ele perca um pouco de sua capacidade de codificação). Mas se você simplesmente adora conversar, como líder de equipe, pode fazer a transição para o gerenciamento e esquecer completamente de escrever código; em vez disso, passaria o dia todo se comunicando com várias equipes, clientes e outros gerentes.

10. Condução/passagem em entrevistas

Se você trabalha para uma empresa terceirizada ou terceirizada, muitas vezes precisará passar por entrevistas externas, nas quais precisará se "vender" ao cliente (você pode ser entrevistado por alguém que trabalha para o cliente), bem como entrevistas internas para subir na hierarquia dentro da empresa. Eu chamaria isso de uma boa oportunidade de crescimento porque as entrevistas freqüentes irão forçá-lo a manter seu conhecimento afiado: você não ficará enferrujado e mole. Afinal, se você ficar mole em TI, pode cair completamente fora de campo. À medida que você se torna um desenvolvedor mais experiente, poderá se encontrar do outro lado da mesa, conduzindo entrevistas em vez de passá-las. Acredite em mim, você ficará muito surpreso ao olhar para ele desta posição, porque fazer as perguntas da entrevista pode ser mais assustador do que respondê-las. Você precisa ter sua própria estratégia de entrevista, uma lista de perguntas e tempo para fazer perguntas sobre todos os tópicos necessários em uma hora. E depois disso, você é responsável por fornecer feedback que influenciará a decisão de contratação e se o candidato receberá uma oferta ou promoção há muito esperada. Ou, você pode permitir que um candidato obviamente fraco obtenha uma posição para a qual não se qualifica e, então, pode ser perguntado: "como você pode permitir que ela seja contratada com esse nível de conhecimento"? Então, quando você estiver na berlinda durante uma entrevista, tenha em mente que a pessoa à sua frente também está enfrentando um desafio e pode estar estressada. você é responsável por fornecer feedback que influenciará a decisão de contratação e se o candidato receberá uma oferta ou promoção há muito esperada. Ou, você pode permitir que um candidato obviamente fraco obtenha uma posição para a qual não se qualifica e, então, pode ser perguntado: "como você pode permitir que ela seja contratada com esse nível de conhecimento"? Então, quando você estiver na berlinda durante uma entrevista, tenha em mente que a pessoa à sua frente também está enfrentando um desafio e pode estar estressada. você é responsável por fornecer feedback que influenciará a decisão de contratação e se o candidato receberá uma oferta ou promoção há muito esperada. Ou, você pode permitir que um candidato obviamente fraco obtenha uma posição para a qual não se qualifica e, então, pode ser perguntado: "como você pode permitir que ela seja contratada com esse nível de conhecimento"? Então, quando você estiver na berlinda durante uma entrevista, tenha em mente que a pessoa à sua frente também está enfrentando um desafio e pode estar estressada. Qualquer entrevista é estressante tanto para o candidato quanto para o entrevistador. Provavelmente terminaremos aqui. Obrigado a todos que leram este artigo. Deixe seu like e continue aprendendo Java :)