A maioria das tretas no Twitter nascem da opinião pessoal de desenvolvedores sobre determinadas ferramentas em determinados projetos. Relatos de experiências traumáticas entram na equação. Fatores de métricas, favoritismos de cada uma das tecnologias também. Não é necessário apontar que a maioria desses argumentos são falhos e quase sempre resultantes de um problema em comum. O over-engineering.
O over-engineering são os problemas acarretados por Usar uma bazuca para matar uma barata. Ou seja, a má utilização de uma ferramenta que não encaixa com as especificações de um produto por serem complexas, ou por terem um custo de implementação ou de curva de aprendizado muito além do que o esperado.
Imagina que para um projeto você dispõe de 3 fatores principais a se ponderar na Sprint 0 do seu projeto. Você tem um nível de complexidade, custo e segurança para se preocupar. De todos os projetos, devemos ponderar individualmente entre casos e casos. Vou fazer um pequeno exercício com exemplos:
O primeiro tipo de projeto, vamos chamar de Projeto A é aquele projeto de risco máximo. Sistemas embarcados de máquinas perigosas, infraestrutura de usinas nucleares ou software de sustentação de vida. Tudo o que você conseguir pensar que se der merda vai ser um caos na face da terra para o time de desenvolvimento, para o cliente e para o usuário. Das três tecnologias, é óbvio que você vai escolher a de maior segurança, sem se importar no custo e na complexidade. O importante para esse tipo de projeto é a sua assertividade na execução. Não pode haver falhas e para isso, o time vai contar com todo o poder de fogo que você puder prover.
O segundo caso, o nosso Projeto B, vai ser o caso de projetos econômicos, normalmente patrocinados por uma empresa que cria seu produto, ou incrementa um produto já estabelecido no mercado, com um software. Os projetos B normalmente são aqueles que são passíveis de erro (acontece erro pra caramba e tá tudo bem...) e que deve está preparado para esses erros. Seja criando rotinas de teste de qualidade, seja apenas corrigindo na mão (não façam isso!), todos os erros deste segundo caso é passível de conserto. Sem o efeito de desligar uma máquina de suporte a vida ou fazer uma área inteira ser evacuada as pressas.
O Projeto C é o projetinho pessoal. Aquele projeto que nasce da necessidade de um portfolio, de uma falta do que fazer ou só para experimentar uma tecnologia nova. Aqui a sua criticidade vai pra porta que se partiu e você deve programar feito um doido. Dane-se a qualidade.
O over-engineering acontece quando por algum motivo (que é sempre um motivo burro) se é utilizado uma técnica, uma ferramenta ou algum produto que está além do esperado para algum desses projetos. Por exemplo, em um Projeto C, você decide que é de bom tom utilizar um server alocado em 5 máquinas AWS. Um projeto B de pequena escala e sem previsão de crescimento, utilizar uma arquitetura em microsserviços em Java (fora da casinha, mano).
Para o Projeto A, é muito difícil considerar algo como over-engineering. Normalmente projetos assim requer sempre ferramentas de alto desempenho para serem desenvolvidos. Porém, esses casos são raros e se o seu projeto não coloca a vida de milhares de pessoas em risco por uma falha, ele não se classifica como Projeto A.
Essa classificação de projetos existe e foi criada por um senhor pimposo chamado Bertrand Meyer. Ele deu a classificação de acute, businness e casuals para a sua classificação de projetinhos.
O problema do over-engineering nasce a partir do desbalanceamento para MAIS do que cada fator de ponderação no software possa sofrer dentro de um projeto. E o que me leva ao problema que mais irrita ao engenheiro de software, o preconceito por alguma tecnologia.
É claro que há um problema imenso com o custo e com a segurança dentro de um projeto que sofre over-engineering, mas o que marca de verdade a vida do desenvolvedor é a complexidade relacionada a uma tecnologia que jamais deveria estar naquele projeto. A má qualidade com uma complexidade alta afeta desempenho, a curva de aprendizado afeta o tempo de desenvolvimento e a falta de necessidade de se empregar tal ferramenta afeta a sua experiência.
É normal acontecer de que uma experiência com tal linguagem se torne o pior martírio para um desenvolvedor, um framework que resolve tudo seja aberto a falhas e faça da vida do pobre um inferno a parte. Tudo isso fica marcado e impede que o dev venha a optar de trabalhar com tal ferramenta novamente quando o problema em si não é a ferramenta e sim a experiência.
É necessário ter uma maturidade de reconhecer que a experiência é algo individual e que vai depender de diversos fatores, entre eles a aplicação correta da ferramenta, e evitar o problema reverso de acontecer, utilizar uma tecnologia apenas pela facilidade que você possui de desenvolver com ela (o famoso caso do javascript no backend... fica no ar a treta). Não deve ser agradável utilizar uma retroescavadeira para apanhar a poeira da sala de estar ou utilizar um aspirador para retirar os escombros de uma casa.
Faz parte da senioridade ver que toda ferramenta dentro do escopo do desenvolvimento tem a sua utilidade e sua contraindicação. Não devemos queimar em fogueiras alguma tecnologia ou cultuar outra só pela visão de mundo da sua aplicação.
Referências bibliográficas:
- 1.3 Classificação de Sistemas de Software; Engenharia de Software moderna, Marco Tulio Valente;
- Handbook of Requirements and Business Analysis, Bertrand Meyer;
- Google;
Top comments (0)