Há muito tempo queria entrar no desenvolvimento, mas, como costuma acontecer, não acreditava muito em mim. Eu acreditava que meu trem havia acabado e os cérebros não eram mais os únicos a dominar essa difícil profissão. Felizmente, fui persuadido, aliás, eles me deram a chance de provar meu valor e fizeram um estágio no departamento de desenvolvimento. Aconteceu de forma tão casual e simples que a princípio não pude acreditar. O tempo todo, parecia-me que agora todos iriam finalmente entender que eu era um ignorante e acenar com a pena de despedida. Mas isso não aconteceu, eles continuaram a me apoiar e eu fiz o possível para não decepcionar ninguém.
Sou estagiário em nosso departamento de backend, que trata de rastreamento de produtos, e ao mesmo tempo trabalho em meu próprio departamento de integração técnica (há 6 meses). A linguagem principal da equipe é Python . Ensinei-o sozinho a conseguir um estágio. Basicamente, é claro, em manuais e vídeos na Internet.
Eu tinha uma base pequena - escrevi vários projetos de treinamento em C, mas no geral não posso dizer que era pelo menos um programador um tanto experiente quando fui aceito para um estágio. No auge dessa humilde experiência, gostaria de falar sobre algumas coisas que eu não sabia ou mal sabia no início.
Trabalho em equipe com Git
Quando uma pessoa vem para seu primeiro estágio, ela imagina o que é o Git (caso contrário, é improvável que ele seja levado), mas tem pouca ideia de como eles trabalham com ela em uma equipe. Todos nós criamos uma conta no GitHub ao mesmo tempo e, felizmente, comprometemos a primeira linha de código para o branch master, nos sentindo como verdadeiros profissionais. Portanto: esta não é a melhor abordagem para grandes projetos.
No desenvolvimento da equipe, o trabalho com o Git é realizado de acordo com o git-flow aprovado . Por exemplo, temos dois ramos: desenvolver e master. Ninguém, exceto o líder da equipe, pode fazer upload do código para o branch master, porque a equipe deve garantir que haja código funcionando lá que não destruirá a produção quando implantado. A responsabilidade por isso recairá sobre os ombros do líder da equipe, e ninguém quer irritar o líder da equipe.
Para prevenir tais situações, há uma revisão da equipe. Cada desenvolvedor trabalha em uma tarefa em seu próprio branch e, no final do trabalho, coloca uma solicitação de mesclagem no branch de desenvolvimento. E o líder da equipe já colocou a solicitação de mesclagem no branch master e é responsável pela qualidade do código perante seu proprietário. Assim, a pureza do código que acaba na produção é garantida, e os riscos de derramar algo que vá atrapalhar o trabalho do projeto são minimizados.
Conclusão: se você quiser se preparar melhor para o trabalho em equipe, leia o git-flow e comece a adicionar novos commits ao seu projeto favorito por meio de branches.
A arquitetura do código é importante
Quando cheguei ao estágio, esperava que eles me dissessem o que fazer, dessem alguns pequenos testes de função ou unidade, e eu os trabalharia sob a supervisão da equipe.
No entanto, tudo acabou de forma diferente. Não, ninguém me instruiu a fazer algo ultra-complicado, mas fui designado um miniprojeto (marco) para monitoramento (Python + Prometheus + Grafana ), que eu tinha que fazer durante meu estágio. Além disso, eu mesmo tive que pensar sobre a arquitetura, decompor o projeto em tarefas e movê-lo através dos estágios Kanban. Foi emocionante, mas muito correto. Essa abordagem permitiu que meu curador e eu entendêssemos claramente quais são meus problemas e começássemos a corrigi-los.
Para ser honesto, minha primeira decisão não teve sucesso. E o segundo também. Realizei tarefas muito grandes, devolvi-as ao backlog várias vezes, construí uma arquitetura malsucedida e não pude levar em consideração as nuances.
No entanto, no momento, a maior parte do projeto já foi implementada e estou ficando cada vez mais ciente de como meu código afeta o resto do projeto. É emocionante. Eu li vários artigos sobre arquitetura limpa, estudei classes abstratas, aprendi como planejar uma interface primeiro e só então comecei a implementar. Não posso dizer que descobri tudo, mas definitivamente entendi a frase "Qualquer problema pode ser resolvido introduzindo um nível adicional de abstração, exceto o problema de um número excessivo de níveis de abstração." E também aprendi como avaliar corretamente minha força (mas isso não é preciso).
: . , , . , Netflix, . , .
Em nossa empresa, todos os serviços são lançados em containers. Da mesma forma, cada desenvolvedor deve entender como o mesmo Docker funciona , como escrever um Dockerfile simples ou aumentar seus serviços por meio do Docker Compose .
Para uma pessoa que escreve apenas para si mesma e em seu computador, é difícil entender por que a conteinerização é necessária. No entanto, em grandes projetos, é necessário garantir que o código funcione independentemente do ambiente. Um pouco mais tarde, quando você descobrir o básico, ficará óbvio como isso é conveniente. Você não precisa instalar dependências em seu ambiente, não há necessidade de um lançamento de projeto longo e difícil. Você pode executar testes ou separar o pro e o dev escrevendo apenas algumas configurações uma vez.
O mesmo conselho pode incluir trabalhar com o IDE. Antes de iniciar o estágio, escrevi todos os meus programas exclusivamente no Emacs, mas quando comecei a trabalhar, decidi mudar para uma ferramenta mais avançada, e no final não me arrependo. Em alguns lugares, ainda prefiro usar o console (por exemplo, é mais conveniente omitir todos os contêineres
docker stop $(docker ps -qa)), mas, por outro lado, sou grato à GUI do Git e às dicas do PyCharm.
Conclusão: Leia sobre o Docker. Tente executar seu código em um contêiner. Experimente uma IDE para sua linguagem e veja o que ela pode fazer por você.
Documentação e testes são tão importantes quanto o código
Meu curador disse uma vez que os testes são a documentação do segundo desenvolvedor. E isso é bem verdade, porque se a documentação real estiver faltando, você sempre pode entrar em testes e ver qual comportamento é esperado.
Antes do meu estágio, usei o UnitTest e o PyTest, mas apenas como parte do meu treinamento. E o Mock , por exemplo, não usava de jeito nenhum, porque meus projetos não eram tão complexos a ponto de precisar substituir dados (bom, ou meus testes eram tão ruins).
Eu recomendaria a todos os desenvolvedores novatos que escrevessem testes para toda a lógica que ocorre no projeto. Mesmo se você achar que o comportamento é óbvio, é melhor jogar pelo seguro. Afinal, quando outra pessoa escreve uma função que usa seu código, há uma chance de que ela não entre em detalhes e é a sua falha no teste que salvará o projeto de problemas.
E para minimizar ainda mais os riscos, escreva uma documentação clara. No Admitad, um método ou função sem documentação levantará questões para revisão. Duas semanas depois, ninguém quer perder tempo tentando descobrir o código de outra pessoa novamente. É apenas uma questão de respeito pelos colegas.
Além disso, direi que também anotamos tipos em Python em detalhes, mas se você escrever em uma linguagem fortemente tipada, este comentário não é para você. (Usar um linter como o Flake8 ajuda muito nesse sentido ).
Conclusão: Preste atenção aos testes e documentação. Comece com um leia-me regular do Git - descreva como executar o projeto, o que ele faz e o que você espera. Tente escrever testes para os principais métodos e funções ou, melhor ainda, crie o Docker Compose que execute todos os testes.
Que experiência você teve?
Para desenvolvedores estabelecidos, meu conselho pode parecer trivial e óbvio. Eu entendo você perfeitamente, mas no começo eu estava muito carente de conhecimento do sistema. Tenho certeza de que muitos dos que dominaram a profissão por conta própria enfrentaram esse problema.
Portanto, encorajo você a compartilhar as experiências e observações que você aprendeu após os primeiros meses (ou anos) na indústria. Que conselho você daria a si mesmo no início de sua carreira? Que habilidades você recomendaria desenvolver? Tanto eu quanto outros autodidatas podemos precisar de suas dicas, então fique à vontade para deixar comentários.