Quais são as responsabilidades típicas de um desenvolvedor Java? Afinal, você precisa entender o que você quer e o que, no final, você vai fazer, certo? Hoje gostaria de falar sobre as dez principais tarefas que um desenvolvedor Java realiza. Mas primeiro, vamos conhecer uma ferramenta como o Jira. Ou vamos refrescar a memória se já for familiar para você. Jira é uma ferramenta de interação com o usuário, embora em alguns casos também seja utilizado para gerenciamento de projetos. Ou seja, o desenvolvimento do projeto é dividido em pequenas tarefas que são descritas nesta ferramenta. Estas tarefas são atribuídas (atribuídas) aos desenvolvedores, que serão responsáveis pela sua implementação. Por tarefas queremos dizer, por exemplo, adicionar alguma funcionalidade. À medida que o progresso avança, os desenvolvedores e outros especialistas adicionam comentários sobre quem fez o quê e quanto tempo gastaram – eles controlam o tempo. Isso é feito para monitorar o tempo gasto: quanto foi gasto e em quê. O ideal é que isso seja feito uma vez por dia: à noite, antes de sair, você monitora suas 8 horas de acordo com as tarefas nas quais as gastou. A funcionalidade do Jira é muito mais ampla do que a descrita acima, mas isso será suficiente para um entendimento inicial. Então, quais são as responsabilidades de um desenvolvedor Java?
1. Desenvolvimento de novas soluções
Antes de criar e implementar algo, você precisa pensar nisso, certo? Como eu disse, isso pode ser tão simples quanto uma tarefa do Jira que será atribuída a você, e você trabalhará para desenvolver uma nova solução, anotando no Jira quanto tempo gastou e em quê. Esta também pode ser uma discussão numa chamada de grupo: todos poderão expressar a sua opinião e propor a abordagem que considerem melhor. E aqui eu gostaria de observar alguns pontos. Em primeiro lugar, a profissão de desenvolvedor é um campo muito criativo, pois você precisa encontrar formas únicas de resolver problemas usando ferramentas padrão. Muitas vezes, um problema pode ter muitas soluções diferentes: portanto, tudo depende do “espírito criativo” do desenvolvedor, da base de conhecimento acumulada e da experiência. Aqui você pode mostrar toda a sua criatividade e genialidade, mas o principal é não exagerar: neste caso, o código ficará muito complexo e ilegível e por isso, depois que você sair, ninguém entenderá completamente o que é e como funciona. E você precisará reescrever tudo do zero. E eles podem se lembrar de você. E mais de uma vez. E é improvável que sejam palavras calorosas e gentis. Você precisa disso? Em segundo lugar, o desenvolvedor deve ser flexível no sentido de que não deve ficar preso a uma solução e fechar-se a outras. Tipo, você precisa fazer apenas assim e nada mais. Isso pode acontecer por vários motivos: por exemplo, você quer provar o seu ponto de vista, ou já desenvolveu e implementou a sua solução, à qual está bastante apegado e, claro, não quer admitir que não é o melhor. Isso pode cegar você. Na verdade, você precisa ser capaz de admitir seus erros e estar sempre aberto a coisas novas (“mente aberta”), mesmo que tenha que remover funcionalidades que você vem escrevendo há muitas semanas e das quais você tem muito orgulho. Lembro-me de como uma vez o clima do dia inteiro foi criado pelo controle do tempo de alguém no Jira com o comentário: “Excluí minha funcionalidade de natimorto. Chorei"
2. Escrevendo novas funcionalidades
Este é um passo lógico que segue o anterior - a implementação de novas funcionalidades. Todo o trabalho do projeto é dividido em tarefas em um jira, que os desenvolvedores recebem à medida que trabalham. Existem diferentes abordagens para esta questão - “metodologias”, mais sobre as quais você pode ler neste artigo no JavaRush . Via de regra, as tarefas possuem uma “Estimativa” - o tempo previsto gasto na conclusão. Ele é definido por você mesmo quando você assume a tarefa, ou pelo líder da equipe, ou durante o planejamento, os desenvolvedores estimam-no juntos. Este tempo raramente é adivinhado com precisão, uma vez que muitos fatores diferentes influenciam o desenvolvimento. Por exemplo, o programador está familiarizado ou não com esta tecnologia, qual é a sua experiência geral, várias armadilhas que podem tornar-se visíveis já durante o desenvolvimento, etc. Portanto, se você não cumprir esse prazo no desenvolvimento de funcionalidades, nada de ruim acontecerá. Estas são apenas estimativas gerais. Mas, novamente, nem todos os projetos têm estimativas de tarefas e, para mim, é muito mais fácil viver sem elas, especialmente quando o PM não cutuca você algumas vezes por dia com a pergunta “Onde estão as estimativas? ” Assim, você pega uma tarefa, desenvolve a funcionalidade necessária, carrega-a em um branch comum no GIT e no jira altera o status da tarefa para “Pronto para revisão” , ou seja, pronto para visualização (verificação) e reza para que ele não é devolvido a você com comentários sobre a revisão.
3. Escrevendo testes de funcionalidade
A pessoa que verifica seu código - o revisor - gostou da funcionalidade que você desenvolveu, mas tem uma dúvida: onde estão os testes para isso? E ele devolve a tarefa para você revisar. Os testes são uma parte importante de qualquer aplicativo Java. Ao executá-los, você pode detectar imediatamente onde o aplicativo está funcionando incorretamente. Por exemplo, um desenvolvedor fez algumas alterações em uma parte do sistema, o que levou a mudanças no comportamento de outra, e não percebeu isso durante o desenvolvimento. Ao executar os testes, ele poderá ver os testes que falharam (aqueles que não funcionaram corretamente). Isso lhe dirá que algo está quebrado em outra parte do sistema. Portanto, ele não carregará alterações significativas no servidor, mas continuará refinando sua solução. Sim, claro, poucos desenvolvedores adoram testes, mas não há como negar os benefícios que eles trazem para a aplicação. Freqüentemente, os próprios clientes especificam qual nível de cobertura de teste aderir (por exemplo, 80%). Portanto, você precisa conhecer diferentes tipos de testes e ser capaz de escrevê-los. Os desenvolvedores Java escrevem principalmente testes de unidade e testes de integração, enquanto AQA (testadores de automação) lidam com testes mais extensos (ponta a ponta). Você pode ler mais sobre eles e outros representantes das profissões de TI em minha análise .
4. Encontrando e corrigindo o bug
Esta também é uma tarefa muito comum e frequente para um desenvolvedor Java. A principal tarefa do QA e AQA é detectar bugs. Ou seja, procuram locais onde o programa se comporta de maneira incorreta, criam problemas no Jira e culpam alguém. Por exemplo, um líder de equipe, que por sua vez decide a qual desenvolvedor atribuir isso, dependendo de sua carga e familiaridade com esta parte do sistema. Depois disso, o desenvolvedor procura o bug, passando horas no depurador , utilizando a descrição do problema por especialistas de QA para repetir a situação em que o bug ocorreu. Em seguida, o desenvolvedor encontra um bug, corrige-o e envia-o para revisão. Bem, é possível que o desenvolvedor não tenha conseguido reproduzir o bug e devolva a tarefa ao especialista de controle de qualidade com um comentário sobre o assunto. Parece que não demorará muito para encontrar e corrigir o bug, mas existem algumas nuances. Tudo depende principalmente da familiaridade do desenvolvedor com esta seção de código, experiência e conhecimento de questões teóricas. Às vezes, um bug pode ser encontrado e corrigido em 20 minutos, e às vezes pode levar três dias. Conseqüentemente, esse tipo de tarefa é especialmente difícil de avaliar antecipadamente, a menos que o desenvolvedor, após ler a descrição, entenda imediatamente o que, onde e com o que deu errado. Nesse caso, ele poderá adivinhar a hora com mais ou menos precisão.
5. Revisão de código
Conforme mencionado acima, assim que você conclui uma tarefa, ela precisa ser enviada para revisão, e se passar, vai para o tópico geral, caso contrário, será devolvida ao desenvolvedor com comentários sobre o que precisa ser corrigido. É claro que tudo isso é verificado não por alguns poderes superiores, mas por outros desenvolvedores. Mas nem todos os desenvolvedores podem se tornar revisores, apenas os mais experientes, que têm prática e conseguem distinguir códigos ruins de bons. A revisão de código geralmente é feita utilizando uma ferramenta auxiliar, por exemplo, o Crisol . Os revisores revisam o código e, se necessário, deixam comentários em algumas linhas. Os comentários também podem ser de vários tipos. Por exemplo, os críticos, sem correção dos quais o revisor não passará o código, e outros são mais provavelmente apenas comentários sobre a abordagem escolhida, que o desenvolvedor pode ouvir, anotar ou ignorar. A equipe pode criar seu próprio procedimento e regras para a realização de revisões, concordar sobre o que vale a pena prestar atenção e o que não vale, em que prazo a revisão do código deve ser realizada, etc. Para fazer uma revisão, só a experiência não é suficiente: você ainda precisa se desenvolver muito na direção técnica, ler vários livros (por exemplo, “Código Limpo” ). Se você estiver interessado nas nuances de realizar uma revisão de código de acordo com o Google, aconselho você a ler este artigo .
6. Análise de código
Como o projeto é escrito simultaneamente por diversas pessoas que pensam de forma diferente, seu código e abordagens serão diferentes. E com o tempo, tudo gradualmente se transformará em mingau. Para melhorar o código, as pessoas às vezes criam tarefas para analisar, talvez um módulo ou um aplicativo inteiro, para encontrar falhas e sinalizá-las, e posteriormente criam uma tarefa de refatoração com base nesses comentários. A análise também ajuda em situações onde alguns atalhos mais simples não eram visíveis desde o início do desenvolvimento, mas podem ser vistos agora. Por exemplo, a mesma lógica é frequentemente repetida em alguns métodos e, consequentemente, pode ser movida para um método separado e reutilizada muitas vezes. Bem, ou alguma classe ficou dolorosamente inchada, ou algum código ficou difícil de manter ou desatualizado, ou... As tarefas de análise ajudam a melhorar a qualidade do código e do aplicativo. Embora, na minha opinião, analisar uma grande quantidade de código possa ser uma tarefa chata.
7. Refatoração de código
A próxima parte da análise é a refatoração do código. Pode estar desatualizado, não ser mais necessário, 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, retirando tudo o que for desnecessário, pois isso só confunde e impede que você veja a essência da funcionalidade. Escusado será dizer que é improvável que você veja essas tarefas no início do projeto: elas ocorrem apenas em estágios posteriores de desenvolvimento, quando o aplicativo é polido e levado à perfeição. Aqui, pode ser apropriado consultar os colegas sobre como o fariam e quais as armadilhas que consideram. A essência de tais tarefas é semelhante ao desenvolvimento de novas funcionalidades. Por exemplo, você recebe uma tarefa para editar alguma funcionalidade sem alterar seu comportamento. Para fazer isso, você exclui o antigo, escreve o seu próprio e verifica os testes. Se você fez tudo corretamente, sem fazer alterações nos testes eles deverão funcionar como antes. Depois que tudo estiver acertado no código, mandamos para revisão e vamos tomar um café))
8. Escrevendo documentação
Imagine que você é um novo desenvolvedor em algum projeto que está em desenvolvimento há muito tempo. Você precisa se familiarizar com ele ou realizar alguma tarefa específica, por exemplo, detectar um bug. Como você navegará no projeto? Retirar os membros da sua equipe a cada cinco minutos? E se estiverem ocupados ou no fim de semana, o que acontece? É por isso que existe documentação, para que quem não conhece a funcionalidade possa entrar, encontrar a página certa e descobrir rapidamente o que faz a parte da aplicação que lhe interessa. Mas alguém também deve preencher a documentação ^^ Se o projeto possui documentação que os desenvolvedores devem suportar, ao implementar uma nova funcionalidade eles a descrevem, e com diversas alterações e refatorações eles atualizam a documentação. Situações também são possíveis quando um especialista separado, um redator técnico, é contratado para redigir, dar suporte e controlar a documentação. Se tal especialista existir, isso tornará a vida dos desenvolvedores comuns um pouco mais fácil.
9. Participação em vários comícios
Os desenvolvedores gastam muito tempo em várias reuniões, negociações e planejamento. O exemplo mais simples são as “reuniões diárias” (reuniões diárias), onde você precisa contar o que fez ontem e o que vai fazer hoje. Além disso, você precisa ter uma ligação individual, por exemplo, com um especialista em QA, para que ele possa mostrar/explicar as nuances da reprodução do bug, ou discutir as nuances e requisitos com um analista de negócios, ou organizacional. problemas com um PM. Portanto, mesmo que um desenvolvedor seja introvertido e prefira a solidão, ele ainda deve ser capaz de encontrar uma linguagem comum com outras pessoas (bem, pelo menos um pouco). Quanto mais alta a classificação de um desenvolvedor, mais tempo ele precisa passar se comunicando e menos tempo escrevendo código. Um líder de equipe de desenvolvedores pode até gastar metade ou até mais de seu tempo de trabalho em conversas e reuniões e escrever código com menos frequência (isso pode fazer com que você perca um pouco o controle). Mas se você também gosta de conversar, pode facilmente evoluir da posição de líder de equipe para o lado gerencial e esquecer completamente o código, comunicando-se o dia todo com diversas equipes, clientes e outros gestores.
10. Conduzindo/passando em uma entrevista
Se você trabalha para uma empresa de terceirização ou terceirização, precisará passar por entrevistas externas frequentes, quando precisar ser “vendido” ao cliente (então poderá ser entrevistado por uma pessoa do lado do cliente), e entrevistas internas, para aumentar sua classificação dentro da empresa. Eu chamaria isso de um bom fator de desenvolvimento, pois devido às entrevistas frequentes, seu conhecimento deve estar sempre em forma: você não vai se enferrujar e relaxar, pois se você relaxar em TI pode sair completamente do campo. Ao se tornar um desenvolvedor mais experiente, você poderá visitar o outro lado: não passando, mas realizando entrevistas. Acredite, você ficará muito surpreso se olhar dessa perspectiva, porque conduzir entrevistas pode ser mais assustador do que passar. 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 pelo feedback, pois contando com ele, uma pessoa pode ou não receber uma oferta ou promoção tão esperada. Pois bem, e vice-versa: você pode perder um candidato francamente fraco para uma posição para a qual ele não corresponde, e então você pode se perguntar: como você sentiu falta dele com tanto nível de conhecimento? Portanto, ao passar por uma entrevista, lembre-se de que a pessoa à sua frente também está passando por momentos difíceis e também pode estar passando por estresse. Qualquer entrevista é estressante tanto para o candidato quanto para o entrevistador. Talvez terminemos aqui. Obrigado a todos que terminaram de ler: curtam e aprendam Java ^^
Em segundo lugar, o desenvolvedor deve ser flexível no sentido de que não deve ficar preso a uma solução e fechar-se a outras. Tipo, você precisa fazer apenas assim e nada mais. Isso pode acontecer por vários motivos: por exemplo, você quer provar o seu ponto de vista, ou já desenvolveu e implementou a sua solução, à qual está bastante apegado e, claro, não quer admitir que não é o melhor. Isso pode cegar você. Na verdade, você precisa ser capaz de admitir seus erros e estar sempre aberto a coisas novas (“mente aberta”), mesmo que tenha que remover funcionalidades que você vem escrevendo há muitas semanas e das quais você tem muito orgulho. Lembro-me de como uma vez o clima do dia inteiro foi criado pelo controle do tempo de alguém no Jira com o comentário: “Excluí minha funcionalidade de natimorto. Chorei"
Portanto, você precisa conhecer diferentes tipos de testes e ser capaz de escrevê-los. Os desenvolvedores Java escrevem principalmente testes de unidade e testes de integração, enquanto AQA (testadores de automação) lidam com testes mais extensos (ponta a ponta). Você pode ler mais sobre eles e outros representantes das profissões de TI em minha análise .
A revisão de código geralmente é feita utilizando uma ferramenta auxiliar, por exemplo, o Crisol . Os revisores revisam o código e, se necessário, deixam comentários em algumas linhas. Os comentários também podem ser de vários tipos. Por exemplo, os críticos, sem correção dos quais o revisor não passará o código, e outros são mais provavelmente apenas comentários sobre a abordagem escolhida, que o desenvolvedor pode ouvir, anotar ou ignorar. A equipe pode criar seu próprio procedimento e regras para a realização de revisões, concordar sobre o que vale a pena prestar atenção e o que não vale, em que prazo a revisão do código deve ser realizada, etc. Para fazer uma revisão, só a experiência não é suficiente: você ainda precisa se desenvolver muito na direção técnica, ler vários livros (por exemplo, “Código Limpo” ). Se você estiver interessado nas nuances de realizar uma revisão de código de acordo com o Google, aconselho você a ler este artigo .
Aqui, pode ser apropriado consultar os colegas sobre como o fariam e quais as armadilhas que consideram. A essência de tais tarefas é semelhante ao desenvolvimento de novas funcionalidades. Por exemplo, você recebe uma tarefa para editar alguma funcionalidade sem alterar seu comportamento. Para fazer isso, você exclui o antigo, escreve o seu próprio e verifica os testes. Se você fez tudo corretamente, sem fazer alterações nos testes eles deverão funcionar como antes. Depois que tudo estiver acertado no código, mandamos para revisão e vamos tomar um café))
Quanto mais alta a classificação de um desenvolvedor, mais tempo ele precisa passar se comunicando e menos tempo escrevendo código. Um líder de equipe de desenvolvedores pode até gastar metade ou até mais de seu tempo de trabalho em conversas e reuniões e escrever código com menos frequência (isso pode fazer com que você perca um pouco o controle). Mas se você também gosta de conversar, pode facilmente evoluir da posição de líder de equipe para o lado gerencial e esquecer completamente o código, comunicando-se o dia todo com diversas equipes, clientes e outros gestores.
Talvez terminemos aqui. Obrigado a todos que terminaram de ler: curtam e aprendam Java ^^
GO TO FULL VERSION