DEV Community: StefanoDucciConvenia

O Desenvolvimento do Desenvolvedor no Século 21

StefanoDucciConvenia — Thu, 08 Jul 2021 20:09:11 +0000

Olá, meu nome é Stefano e sou Líder em treinamento do time de SRE aqui na Convenia. Venho aqui hoje contar para vocês como está sendo o desafio de treinar novos Desenvolvedores nesse mundo cada vez mais complexo e avançado da programação e também sobre um case de sucesso de uma Desenvolvedora que se mostrou excepcional nesses seis meses que faz parte do meu time.

Antes de começar a falar sobre como está sendo hoje, convido vocês a uma viagem no tempo comigo, não muito longe, só três anos atrás quando entrei aqui na Convenia como um Desenvolvedor Backend Júnior, naquela época a Empresa estava terminando de passar por uma migração de tecnologia, indo de um modelo MVC usando Codeigniter e indo para um Monolito em Laravel. Ou seja, para conseguir desenvolver eu só precisava saber PHP e MYSQL, e no máximo, um pouco de HTML para ajustar alguma coisa no que se mostra ser sempre um pesadelo na vida de qualquer desenvolvedor novo em uma instituição, o famigerado “Sistema Legado”.

Nesses últimos anos, a Convenia passou por diversas mudanças e modernizações, agora, um Desenvolvedor Junior cai direto em um sistema distribuído com micro serviços, bancos não relacionais, SPA’s, BFF, Graphql e mensageria. Com tudo isso, fica fácil de ver como a curva de aprendizado de alguém novo vem se tornando cada vez mais íngreme ao longo do tempo.

Esse cenário atual nos leva à seguinte questão: o que podemos fazer para que essa curva de aprendizado seja suavizada o máximo possível para que todos consigam escalar até o topo? Para conseguir chegar a uma resposta para isso, trabalhei em uma metodologia de treinamento e acompanhamento junto a essa Desenvolvedora que iniciou no meu time, e para chegar nesse resultado, nada melhor do que trazer todos os exemplos que tive das minhas lideranças ao longo desses anos.

É um fato de que ao longo do seu desenvolvimento existem marcos e divisores de água que te mostram uma nova realidade na qual você se sente cada vez mais motivado a continuar evoluindo, comigo por exemplo, o primeiro contato que tive com esse sentimento foi quando eu já estava a quase três horas tentando corrigir um código de produção, mas ele estava complexo demais, foi quando meu primeiro líder aqui na Convenia chegou do meu lado e me perguntou: “Você sabe o que esse código deveria fazer?”, eu respondi: “Sim, deveria fazer isso, isso e isso”, o que fez ele simplesmente selecionar todo aquele código, apagar e dizer: “Então escreve o que ele deveria fazer ao invés de tentar entender o que ele fazia antes, já que estava errado”.
Esse pode até parecer um caso sem importância à primeira vista, mas isso para um cara inseguro como eu era, começando a programar e se imaginando incapaz de dar conta do que estava enfrentando, aquilo mudou meu mundo. Nos próximos 20 minutos aquele código já estava sendo usado pelo cliente impactado por aquele bug, foi quando percebi que “de repente” eu realmente comecei a entender o que estava fazendo.

O segundo ponto, e talvez o mais importante, anda muito próximo a esse: a confiança, essa palavra expande os horizontes de qualquer desenvolvedor júnior, então precisamos trabalhar tanto a confiança que ele deve ter no seu próprio código e no produto em que ele trabalha, bem como a confiança que passamos pra ele como líder. Se tem uma coisa que aprendi com isso, foi que codar é muito fácil, mas só se você sabe o que é esperado daquele código, uma vez que você entende a regra de negócio, coda-la é um mero detalhe, e esse ensinamento eu devo totalmente ao CTO da Convenia, o cara que discute e estressa a regra de negócio junto com você, sempre ouvindo seus pontos para trazer o máximo desse conforto tão importante na hora de desenvolver.

Foram essas lições que me ajudaram a pavimentar o caminho que essa Desenvolvedora iria trilhar ao meu lado, incluindo essa última que aprendi com meu líder atual, nenhum time deve seguir uma liderança, todos devem caminhar juntos para o objetivo em comum que pode ser uma entrega importante, a resolução de um problema grave ou até mesmo no aprendizado do dia a dia.

Agora sem mais delongas, vamos ao passo a passo que desenvolvi, começando pelo passo mais importante: ‘Acompanhamento diário do aprendizado’, que consiste em diariamente tirar entre cinco e dez minutos para ouvir tudo o que o desenvolvedor aprendeu nas últimas vinte e quatro horas, estendendo para até vinte minutos no fim da semana para repassarem um resumão de quais foram os maiores desafios, aprendizados e dúvidas que surgiram nesse período. Isso vai te ajudar a entender a melhor forma de se comunicar com essa pessoa, a quantidade de detalhes que você deverá dar na próxima vez que passar uma tarefa ou dar uma explicação, além de te aproximar muito do seu liderado e permitir que você meça diariamente seu nível. Mas o mais importante nesse passo é garantir a concretização do conhecimento, garantindo que nenhuma dúvida ficou em aberto e nenhuma lição passou em branco.

O segundo passo: ‘Uma hora de estudos por dia’, foi algo que roubei de um ex-funcionário e líder do time considerado de maior desempenho, o BPO, que nem é de desenvolvimento, mas acredito que bons exemplos podem muito bem ser buscados de fora de nossas bolhas também. Nessa uma hora, o ideal é que os estudos sejam focados nas tecnologias da empresa, aqui no nosso caso, disponibilizamos uma lista de cursos sobre protocolo AMQP, MongoDB, PHP e Laravel para que na hora de desenvolver, eles tenham um estranhamento menor ao trabalhar nessas tecnologias.

Como aqui estamos falando do exemplo de um time que também faz a sustentação do produto, o terceiro passo: ‘Integrar às resoluções de bugs’, e o quarto passo: ‘Tratativa de bugs já resolvidos em ambiente local desatualizado’, se fizeram bem necessários, e em suma, se resumem a trazer essa nova pessoa junto à tratativa de um problema, mostrando sua forma de pensar, explicando o background que você tem sobre essa parte do sistema antes de começar a investigar e explicar por onde você começa e porque. Já o quarto passo existe por que com a correria do dia a dia, as vezes você acaba resolvendo um problema em produção durante uma outra reunião ou durante o tempo de estudo do seu liderado, e esses são os casos perfeitos para você deixar ele explorar o problema dentro do seu ambiente local, sem se preocupar com a pressão envolvida em querer resolver um problema o mais rápido possível, já que sempre existe um ou mais clientes impactados em um problema, e nesse setor, trabalhar o psicológico é tão importante quanto trabalhar a confiança.

O que nos leva diretamente ao passo cinco: ‘Entrega de pequenas features’, muitas vezes vocês verão desenvolvedores com medo de começar a codar, aquele receio de querer sempre fazer tudo da melhor forma desde o começo, mesmo a gente sabendo que é impossível. Dar entregas pequenas para um junior ajuda a melhorar a sua confiança, além de ajudá-lo a organizar melhor suas ideias, entender seu próprio processo criativo, limitações e medos.

O sexto e último passo: ‘Passar a autoria de um serviço’ - trata do sentimento de dono que todo desenvolvedor tem pelo seu código - nesse caso, como a Convenia trabalha nesse modelo distribuído, eu ajudei minha Desenvolvedora desde o começo na criação de um serviço que viria a ser mantido, melhorado e cuidado por ela. Esse sentimento é transformador, durante o desenvolvimento desse serviço ela veio mostrando sinais claros de amadurecimento, evolução e senioridade que não é comum em um profissional no começo da sua carreira.

Agora, uma constante entre esses passos é o passo oculto: ‘Introduzir o máximo de regras de negócio possível’. Como falei anteriormente, às vezes ensinar a regra de negócio é mais importante do que ensinar a forma de se fazer uma tarefa, então sempre que possível aproveite para ensinar, ensine durante uma call com um cliente, ensine durante a reunião diária com o time, ensine durante o code review, ensine durante um deploy, ensine durante a explicação da tarefa, ensine durante a resolução de um problema e quando você perceber, será você que estará aprendendo com seus liderados.

Não existem fórmulas mágicas quando falamos de pessoas, cada um terá seu próprio tempo de desenvolvimento, sua própria maneira de absorver as coisas, uma hora no dia que consegue aprender melhor e aquela que já não consegue tanto, vai de cada líder saber enxergar isso em cada liderado e ter tato para tratar cada um de acordo com suas peculiaridades. Essa foi a fórmula que encontrei para ajudar essa Desenvolvedora em particular, mas é com muito orgulho que digo que os resultados foram incríveis, em apenas seis meses, uma desenvolvedora júnior que chegou com três meses de experiência já é considerada de nível pleno por profissionais com mais tempo de carreira no PHP do que ela tem de vida.

Vou concluir esse artigo deixando a seguinte lição: trabalhe a confiança de seus liderados, dê a eles um motivo para melhorar todos os dias, os desafie e mostre como eles são capazes de evoluir, ensine, nunca perca essa oportunidade e sempre mostre para eles como essas lições fizeram diferença ao longo de um code review ou de um feedback. E nunca se esqueça do mais importante: eles são pessoas como você, irão cometer erros, mas esses erros jamais deverão ser passivos de punição ou vergonha e sim ser a melhor oportunidade de evoluir, aprender e repetir tudo de novo, afinal, esse é o ciclo de desenvolvimento de um desenvolvedor.

Explorando os arquivos de Stubs do Framework Laravel

StefanoDucciConvenia — Thu, 24 Dec 2020 18:28:19 +0000

Olá, meu nome é Stefano Ducci e eu sou desenvolvedor Sênior na Convenia, hoje vou falar um pouco sobre os arquivos Stubs do framework Laravel que utilizamos aqui para o desenvolvimento do nosso software.

O que me levou a escrever esse artigo foi a pouca informação a respeito disso disponível hoje, incluindo a própria documentação do Laravel que carece de exemplos de customização de arquivos.

O que são?

Os arquivos Stubs nada mais são do ‘arquivos de configuração’ para criação automatizada de classes através dos comandos artisan make do próprio framework. Utilizando um projeto Laravel na versão 8, segue abaixo um exemplo de um arquivo gerado automaticamente pelo comando php artisan make:model com o Stub paradão do framework.

Nele podemos ver algumas configurações padrões da versão 8 do framework como o uso da Trait HasFactory, que veio junto com essa release para facilitar no desenvolvimento de testes automatizados. Além disso, é possível ver a extensão e a importação da classe Model nativa do próprio Laravel. Mas então, como customizamos esses padrões para se adequarem aos nossos projetos?

Customização

Para que seja possível customizar esses arquivos Stubs, é necessário rodar o comando php artisan stub:publish que irá importar para o seu projeto todos os arquivos Stubs que o Laravel possui por padrão para dentro de uma pasta chamada stubs em sua raiz, é importante que a localização desse diretório não seja alterada pois na hora de executar os comandos make, ele irá procurar pelos arquivos de customização nesse caminho e caso não os encontre, usará seu arquivo padrão, ou seja, uma vez importados, não é necessário que você mantenha todos os arquivos stubs no seu projeto, somente aqueles que possuem alguma customização. Abaixo segue um exemplo de alguns arquivos importados pelo comando mencionado acima:

É possível notar que alguns arquivos como os Controller, possuem mais de um arquivo passivo de customização, isso se dá pois dependendo de como você executar o comando make, um determinado Stub será usado para criação do novo arquivo. Por exemplo, o comando: “php artisan make:controller TestController --model Test --resource”, o stub que será usado será o controller.model.stub, já quando usamos o comando php artisan make:controller TestController sem nenhuma opção, o arquivo que será utilizado será o controller.stub.
Mas e então, como utilizar esses arquivos de forma efetiva?

Utilização

Aqui na Convenia, em um dos nossos projetos, nós optamos por usar um banco de dados não relacional e para esse desafio escolhemos utilizar o banco MongoDB, que nos permite certas liberdades que esse projeto necessita, para que o Laravel conseguisse conversar bem com essa arquitetura, nós adicionamos ao projeto a biblioteca jenssegers/laravel-mongodb que traz uma abordagem bem simples para interagir com os dados do banco, além de trazer uma linguagem muito próxima da classe Model do próprio Laravel.
E junto com a descoberta dos Stubs, veio a possibilidade de padronizar a criação de nossas Models alterando a classe mãe de todas elas já no momento de criação, segue abaixo o arquivo Stub customizado:

E esse foi o resultado do arquivo gerado com o mesmo comando php artisan make:model Test:

Outras customizações que podemos trazer para esse arquivo de Stub são por exemplo, o uso de chave primária do tipo texto e o autoincrement como falso, uma vez que adotamos o uso de chaves primárias no modelo UUID em vez do uso de id’s inteiros incrementais, deixando nosso arquivo assim:

Ou até mesmo adicionando ao nosso template as variáveis usadas pela biblioteca do Jenssegers para conexão com o banco de dados:

Conclusão

Esses foram somente alguns exemplos de como os arquivos de Stub do Laravel podem facilitar o seu desenvolvimento do dia a dia, diminuindo o número de vezes que você reescreve código em classes com a mesma estrutura e trazendo um pouco de padronização entre as classes do seu sistema.
Aqui na Convenia nós percebemos que esse tipo de abordagem traz muito mais facilidade para acoplar um novo desenvolvedor a um projeto, fazendo com que os Stubs acabem se tornando um tipo de documentação de como as coisas são feitas naquela projeto, principalmente na estrutura distribuída de microsserviços que temos hoje onde cada projeto pode ter suas próprias características.