Nas últimas décadas nós (devs) ganhamos muitos papéis nos times de desenvolvimento, dentre eles temos o programador(a), analista de sistemas, arquiteto(a) de software, dev backend, frontend, fullstack e um que atualmente está em evidência, o engenheiro(a) de software. Esses papéis vieram para organizar as várias atividades que exercemos, mas a de engenheiro(a) de software é a que pretendo aprofundar.

A figura do engenheiro(a) está presente em muitas áreas como a construção civil, mecânica, elétrica, dentre outras, em todas elas é necessário uma formação mínima para exercer a profissão requerendo geralmente até registro em órgãos regulamentadores da área. Um(a) engenheiro(a) nessas áreas precisa seguir padrões, se adequar a metodologias e principalmente se tornar responsável pelos projetos realizados vinculando seu nome e registro.

Comparando a área de software com as demais áreas temos algumas facilidades para o engenheiro(a), pois não há necessariamente uma formação mínima, não há necessidade de se registrar e vincular o nome a um projeto se torna mero capricho. Mas não é o foco aqui dizer que isto é bom ou não, o que desejo trazer aqui é uma reflexão sobre quais pontos os engenheiros(as) de outras áreas fazem bem e que o engenheiro(a) de software também pode fazer.

Antes de apresentar tais pontos, quero ainda deixar um questionamento para você. Quantas vezes você já “xingou” um(a) engenheiro(a), mesmo sem conhecê-lo(a), afirmando:

  • Quem foi que projetou isso aqui? Essa pessoa merecia uma “surra”.
  • Quem projetou isso aqui nunca utilizou!
  • Quem projetou isso aqui, comprou o diploma!

Essas frases também são ditas aos engenheiros(as) de software, e infelizmente muitas vezes elas tem um fundo de verdade. Para mudar esta visão e evitar essas frases segue alguns pontos aos quais podem ajudar no amadurecimento do engenheiro(a) de software:

  • Padrões: Esse é um dos pontos mais importantes. Todo(a) engenheiro(a) em qualquer área segue padrões e evita criar formas mirabolantes de resolver um problema. Temos então algumas perguntas ao engenheiro(a) de software: você procura usar padrões? quantos livros relacionados a padrões de software você já leu? Se já leu, quantos destes padrões você aplica de fato no dia a dia? Os padrões ajudam a resolver problemas de forma com que todos entendam o como esse problema foi resolvido!

  • Formação: A área de software permite métodos alternativos para se ter uma formação profissional e muitas vezes sequer isso é necessário para se tornar um(a) engenheiro(a) de software. Essa facilidade não deveria afastá-lo dos meios formais de ensino. É importante ler artigos, tutoriais, livros, porém mais ainda é trocar conhecimento com outros engenheiros, inclusive os que estão no universo acadêmico. É importante que se compreenda o conceito das coisas antes de sair aplicando. Um(a) engenheiro(a) de software deve ter esse papel muito mais pelo conhecimento e aplicação do mesmo do que por “tempo de profissão como dev”.

  • Planejamento: Uma prática esperada dos engenheiros(as) é a de planejar antes de executar o projeto. Isso se faz através de análise do problema, estudos de casos, desenhos técnicos, simulações, etc. Na área de software muitas destas etapas são ignoradas e com isso muitos problemas surgem durante a execução do projeto ou pior ainda, depois que ele é dado como pronto. Então planejar bem o desenvolvimento de um software é essencial para o sucesso da execução do projeto e principalmente para evitar as frases citadas no início do artigo.

  • Documentação: Engenheiro(a) em outras áreas geralmente documenta muito bem o projeto. Essa documentação tem várias finalidades, dentre elas registrar o que se pretende fazer, quais critérios usados na tomada de decisão, resultados esperados. Além disso possibilitar que as pessoas tenham visão completa do projeto e que outros profissionais posteriormente não precisem recorrer ao engenheiro(a) para compreender o que foi feito. Enfim, nas demais áreas ter um projeto devidamente documentado é quase sempre pré-requisito para a sequência do projeto. Na área de software isso é considerado burocracia ou perda de tempo. Mas é possível fazer isso de forma adequada na área de software, não abra mão da documentação, busque alternativas para que ela tenha validade e prove seu valor.

  • Assinar um projeto: Nas demais áreas um(a) engenheiro(a) geralmente precisa “assinar” o projeto. Isso o(a) torna responsável pelas decisões que foram tomadas e faz com que ele(a) pense bem antes de decidir por opções de baixa qualidade ou fora dos padrões. Na área de software geralmente essa questão é ignorada e com o tempo ninguém mais sabe “quem foi responsável por essa decisão”, e embora tenhamos o nome de quem fez o commit do código, muitas vezes esse não é o nome do(a) engenheiro(a). Isso abre espaço para decisões sem qualquer responsabilidade, o que a médio e longo prazo se torna um dos grandes fatores da baixa qualidade dos softwares que são produzidos.

Enfim, há vários outros pontos, mas esse artigo certamente ficaria extenso demais. O fato é que na área de software muitos paradigmas foram quebrados com relação a burocracia e formação de um(a) profissional na área, o que estimulou a inovação e escala da área como um todo. Porém isso não deve ser um pretexto para ignorar boas práticas que engenheiros(as) de outras áreas tem para construção e execução de projetos com qualidade.

Aplicar todos esses itens não é fácil, ainda mais porque geralmente não há um processo formal que obrigue isso e assim deixamos alguns de lado ou pecamos na aplicação por falta de conhecimento ou maturidade.

A engenharia de software é uma área muito nova se comparada a outras engenharias. Além disso as mudanças e evoluções na área de software são muito mais rápidas e disruptivas. Então é natural que a área e engenheiros(as) de software precisem ainda amadurecer e consolidar vários destes pontos, a mensagem final é que certamente esse amadurecimento pode ser conquistado e acelerado se buscarmos aprender com engenheiros(as) de outras áreas!