Pode o perfil do desenvolvedor impactar no design de código?
Para responder a pergunta acima precisamos primeiro nos perguntar: existem perfis de desenvolvedor?
A resposta é sim! Em seu livro o John Ousterhout define dois tipos de desenvolvedor o Tático e o Estratégico.
O Tático
Tático é aquele que deseja entregar funcionalidades em tempo recorde. Parece bom, certo? E para times de produto/negócios realmente é! Muitas gerências valorizam esse tipo de profissional. Ele olha para o cronograma e olha para o backlog e começa a trabalhar.
Qual é o problema com o Tático?
Esse comportamento pode ser o esperado para algumas situações ou contextos. Estamos em uma Startup que precisa mostrar que uma solução é plausível? Estamos com uma necessidade de mercado onde precisamos entregar uma funcionalidade rapidamente? Se sim, ok! Assuma essa postura.
Mas em caso contrário. Vamos com calma. Esse comportamento pode adicionar complexidades desnecessárias ao código. Essa complexidades, mesmo sendo pequenas vão se acumulando e no fim vamos perdendo velocidade de desempenho. O ganho de velocidade que esse perfil pode trazer, será perdido em pouco tempo.
O Estratégico
Estratégico é aquele que investe um tempo em analisar o Design atual do código antes de implementar uma nova funcionalidade. Ele fará ponderações, documentará decisões e se possível proporá alterações de design/arquitetura para adequar o estado atual a evolução do projeto.
Que vantagens o Estratégico trás?
A princípio o Estratégico tem uma performance inferior do Tático. Vamos supor que ele gaste 10% a mais com suas análises, como isso se compensaria?
Ponderando sobre como as novas funcionalidades podem impactar na evolução do design/arquitetura, o desenvolvedor Estratégico evitar com que haja uma degradação da qualidade do projeto, assim a velocidade de implementação continua a mesma durante todo o desenvolvimento. A logo prazo não veremos uma “recompensa”, mas por seu comportamento, ele está evitando com que seja aplicada uma “penalidade” à qualidade de código do projeto.
Não viva com Janelas Quebradas
Não viva com Janelas Quebradas
Essa é uma citação do livro The Pragmatic Programmer que pode nos ajudar a não penalizarmos a velocidade de desenvolvimento.
Erros de Design vão se acumulando em um projeto. Isso é normal, vai acontecer. Mas qual deve ser o nosso comportamento diante deles? Temos eles catalogados e já discutimos sugestão de melhoria? Conseguimos convencer o Gerente de Projetos a priorizar eles no backlog?
Um erro bastante comum é deixar os erros lá. O pessoal de produto não vê problema, pois não são bugs, mas erros de design. O Gerente de Projetos não vê espaço no cronograma. E vai todo mundo lidando com eles.
Mas já existem estudos que a presença de problemas de design em projetos de software impacta negativamente a qualidade de software desenvolvido. Quando mais problemas de design existente, maior será a taxa de outros problemas inseridos.
Por isso tome uma atitude! Faça o levantamento de todos os pontos de melhoria, coloque como backlog e comece a agendar essas refatorações para os próximos Sprints. Lembre-se uma coisa não agendada provavelmente não vai acontecer. Encontre uma métrica e você poderá acompanhar isso com o time.
Uma ferramenta que pode ajudar bastante é o Sonarqube, tem a versão open source e a versão cloud. Instale no seu projeto e acompanhe a qualidade do seu código.
Conclusão
A qualidade de código de um projeto não é um atributo estático. Irá variar com o tempo, e isso pode impactar sua velocidade de desenvolvimento. Quanto mais veloz for o desenvolvedor, mas problemas irá inserir no código e penalizará o desenvolvimento mais a frente. Quando mais cuidadoso for o desenvolvedor, menos problemas de design irá inserir, não penalizando o desenvolvimento.