Notícias

Jul 11, 2023

Se você quer entregar rápido, seus testes têm a última palavra

Artigos da página inicial do InfoQ, se você quiser

Artigos da página inicial do InfoQ Se você deseja entregar rápido, seus testes têm a última palavra

06 de junho de 2023 23 min de leitura

por

Jorge Fernández Rodrigues

revisados ​​pela

Matt Campbell

Acho que você concorda que a engenharia de software é especial em comparação com outras profissões. As coisas mudam drasticamente e rapidamente. Requer muito poder cerebral apenas para se manter atualizado.

Talvez como consequência disso, nos apegamos a algumas práticas ou ideias gerais bem estabelecidas (mesmo que elas nos causem problemas ou não se encaixem em alguns casos). Essas práticas tentam cobrir a maioria dos casos, mas não podem cobrir todos eles. No entanto, essas práticas nos dão conforto. Precisamos ter algo que não mude, que pareça seguro e que liberte nossa mente do fardo de pensar se realmente se encaixa ou não. Entramos no modo piloto automático.

O problema com isso é que queremos que o desenvolvimento de software se comporte como uma linha de montagem: uma vez construída a linha de montagem, nunca mais tocamos nela. Operamos da mesma forma o tempo todo. Isso pode funcionar com nossas pistas de CI/CD por um tempo, mas, infelizmente, nem sempre funciona bem com nosso código.

Migre facilmente para a nuvem e inove incrivelmente rápido com Kalix! Crie microsserviços e APIs de alto desempenho, NoOps necessários. Saber mais.

Pior ainda porque às vezes a mensagem é transmitida tantas vezes que perde a essência e, em algum momento, tomamos essa prática como parte da nossa identidade, a defendemos e não deixamos pontos de vista diferentes entrarem. se aparentemente exigirem mais esforço. Outras vezes, queremos apenas nos encaixar e não queremos sugerir novas ideias.

Quando codificamos, precisamos lutar contra isso e refletir em cada caso se a prática se encaixa no cenário atual. Pense nas "melhores práticas" como "melhores práticas genéricas".

Um exemplo disso são as muitas maneiras pelas quais o ágil pode ser mal interpretado. A essência foi perdida em alguns casos.

Nesse artigo, defendo que a essência do ágil é frequentemente perdida porque muitas vezes a implementação do ágil se concentra nas coisas erradas. Por definição, algo ágil pode facilmente mudar de direção e responder rapidamente às mudanças.

Procuramos alcançar essa responsividade com práticas de diferentes naturezas: técnicas, como CI/CD (Continuous Integration/Continuous Deployment), e estratégicas, como desenvolvimento em iterações. No entanto, muitas vezes esquecemos da agilidade quando lidamos com o núcleo do Desenvolvimento de Software: a codificação. Imagine preparar sua refeição ou sobremesa favorita sem o ingrediente principal da receita. É isso que estamos fazendo quando buscamos agilidade sem considerar o código.

Isso pode acontecer porque melhorar o código parece assustador e complicado ou pode ser fácil entrar em buracos de coelho (tudo isso pode ser evitado). Talvez seja apenas porque não é fácil ver o efeito negativo que algumas soluções têm em nossa manobrabilidade; convertendo os desenvolvimentos futuros em um pesadelo: o oposto da agilidade. Ao invés de focar no código, muita atenção é colocada em atingir a perfeição em nossos processos (de metodologias como Scrum), que são menos importantes e tentam resolver o problema sem atacar o problema principal.

Por fim, sugiro que precisamos dar mais visibilidade ao efeito que o código tem nos desenvolvimentos futuros (e, consequentemente, no futuro do negócio). Esperançosamente, a IA pode nos ajudar a quantificar isso com algo como um coeficiente que, não apenas nos diga a qualidade, mas também preveja o quanto o desenvolvimento mais lento será baseado em nossas escolhas potenciais. Acho que algo assim poderia ajudar as empresas a perceberem que precisam investir no desenvolvimento sustentável. As discussões sobre quando lidar com a dívida técnica se tornariam história.