A base para o sucesso da engenharia de software

Um dos professores mais influentes que tive foi meu professor universitário de música. Um pedaço de sabedoria ressoa particularmente em mim: ele perguntou: “Quão bom você seria se fizesse tudo o que seu professor lhe dissesse para fazer?” O que ele queria dizer não era que você devesse fazer inquestionavelmente o que lhe mandam. Em vez disso, ele quis dizer que depois de estarmos suficientemente familiarizados com uma disciplina, saberemos o que produz melhorias nela. Sabemos quais hábitos, procedimentos e mentalidades nos tornarão melhores no que fazemos.

É claro que ele não teria feito essa observação se fez fazer consistentemente o que sabíamos que deveríamos. Mas por que? Existem muitas razões possíveis, mas acredito que a mais comum é simplesmente a preguiça.

Abordar todos esses fundamentos é um trabalho árduo e não tão divertido quanto fazer coisas chamativas. Se você estivesse construindo um arranha-céu, preferiria cimentar a fundação ou construir o nível da cobertura? Não apreciamos essa base robusta, a menos que descubramos, muitas vezes de forma catastrófica, que ela está defeituosa.

Tempo de inspeção

Com esse espírito, eu queria ser um engenheiro responsável e examinar nossa base. As observações a seguir foram compiladas tendo em mente a engenharia de software, conforme as identifiquei enquanto trabalhava nessa disciplina. No entanto, essas práticas se aplicam universalmente. Para cada um, tenho um exemplo de quando se revelou o fator decisivo para o sucesso.

Verifique cada suposição. É alarmantemente fácil assumir uma “verdade” sobre a fé quando, na realidade, esta está aberta ao debate. A resolução eficaz de problemas começa examinando as suposições, porque as suposições que sobreviverem ao seu escrutínio ditarão quais abordagens permanecerão viáveis. Se você não sabia que o plano pretendido se baseava em uma suposição infundada ou inválida, imagine como seria desastroso prosseguir de qualquer maneira. Por que fazer essa aposta?

Recentemente, trabalhei em um projeto que envolvia o alinhamento da implantação de software com as melhores práticas do setor. Contudo, para satisfazer requisitos especializados, a liderança do projecto baseou-se em definições únicas de termos comuns, desviando-se ligeiramente das definições padrão da indústria. Se eu tivesse assumido as definições típicas do setor, teria perdido alguns requisitos.

Procure todos os termos que você não entende. Ao encontrar um termo desconhecido, é fácil esperar que possamos intuí-lo a partir do contexto ou que seja marginal o suficiente no contexto para que possamos entender a essência sem ele. Mesmo que isso seja verdade, como você sabe até verificar? Como você sabe que não entenderia o assunto em um nível muito mais profundo se dedicasse cinco minutos para pesquisá-lo?

Quando inicialmente embarquei em meu curso intensivo de ciência da computação, não lia muito profundamente sobre programação orientada a objetos. “Sim, sim”, pensei, “tudo é um objeto”. Mas depois que reservei um tempo para explorar os detalhes, aprendi quais características definem a programação orientada a objetos e como essas características, por sua vez, ditam como ela pode ser aplicada. A partir daí, tive experiência suficiente para começar a considerar quais problemas uma abordagem orientada a objetos é boa e ruim para resolver.

Verifique a credibilidade de todas as suas fontes. Não estou dizendo para você ler apenas a documentação (embora seja aconselhável começar por aí), mas você não deve atribuir credibilidade a uma fonte até que você a compare com informações que você já sabe que são confiáveis ​​— como a documentação. Escrevi mais de um artigo sobre a diferença entre a forma comumente aceita e a forma correta. Meu artigo recente sobre configuração de DNS do Linux é um bom exemplo.

Constantemente encontro grandes abismos entre o que a documentação aconselha e o que os desenvolvedores nos fóruns afirmam com segurança. Por exemplo, tive que gerar UUIDs compatíveis com RFC 4122. Na linguagem específica que eu estava usando, muitos desenvolvedores recomendaram o uso de uma biblioteca de terceiros. No entanto, após uma pesquisa cuidadosa, determinei que a biblioteca criptográfica integrada da linguagem já poderia gerar UUIDs. Ao omitir o pacote de terceiros, reduzi o número de dependências e também a superfície de ataque do aplicativo que estava criando.

Faça anotações e, em seguida, faça mais algumas anotações. No último ano, fiz questão de capturar as ideias perdidas, sejam elas internalizadas ou sintetizadas, em vez de deixá-las se dissipar. Desde então, tenho observado que sou mais produtivo e absorvo mais informações mesmo sem reler minhas anotações. O valor das notas copiosas é intuitivo: leva muito menos tempo para anotar demais e escanear tudo do que anotar pouco e retornar às fontes para realocar o que foi omitido. Com as notas digitais, faz ainda mais sentido registrar tudo o que você lê. Uma pesquisa Ctrl-F até mesmo no arquivo de notas mais volumoso é muito mais rápida do que refazer sua investigação.

Ao pesquisar como configurar e testar alguns aplicativos, tomei notas sobre os critérios que usei para selecionar as configurações. Anotei tudo em uma página de documentação privada, criando até um fluxograma para ilustrar todas as minhas considerações. Na época, a página servia apenas para verificar e reforçar meu entendimento. Mas assim que percebi que outros desenvolvedores se beneficiariam se seguissem meus passos, já tinha uma página pronta.

Teste tudo o que você projeta ou constrói. É surpreendente a frequência com que os testes são ignorados. Um estudo recente mostrou que pouco menos da metade do tempo, os profissionais de segurança da informação não auditam atualizações importantes em seus aplicativos. É tentador olhar sua inscrição no papel e concluir que ela deve estar correta. Mas se tudo funcionasse como no papel, os testes nunca encontrariam problemas – mas isso acontece com frequência. O objetivo do teste é descobrir o que você não previu. Como ninguém pode prever tudo, a única maneira de descobrir o que não foi feito é testando.

Certa vez, eu estava escrevendo um programa para verificar uma carga útil de resposta que continha arbitrariamente estruturas de dados aninhadas de vários tipos. Embora exista uma estrutura de dados extremamente comum para o nível superior dessas cargas úteis, ou seja, a raiz da carga útil, escrevi o programa para lidar com uma variedade de estruturas de dados de nível superior. No entanto, só adicionei essa flexibilidade depois de testar uma ampla variedade de cargas durante o desenvolvimento. Se eu não tivesse testado com entradas incomuns ou inesperadas, o programa poderia ter encontrado casos extremos que induziram uma falha.

O básico não é tudo, apenas tudo de que tudo depende

Por que me fixo em princípios básicos como este? Posso pensar em duas razões.

Primeiro, eu vi os resultados por mim mesmo. Colocar cada um dos itens acima em prática consistente melhorou a qualidade do meu trabalho, permitindo-me enfrentar problemas mais complexos. O trabalho que estou fazendo agora seria impossível sem solidez nesses princípios básicos.

Em segundo lugar, as empresas continuam a extrair mais produtividade da sua força de trabalho através da adopção da tecnologia de ponta da época, sendo a IA generativa apenas a mais recente iteração desta tendência. Não confunda os meios com os fins: as empresas não desejam intrinsecamente IA generativa ou qualquer ferramenta específica; eles querem maior produtividade.

É muito cedo para dizer se a IA generativa produzirá o salto quântico que tantos parecem pensar que produzirá. Antes de abraçar um novo paradigma, porque não aproveitar totalmente um já existente? É muito mais eficiente melhorar o básico do que adicionar um fator novo e especializado que pode não permanecer relevante para a equação.

Independentemente da sua disciplina, o que você faz regularmente baseia-se mais em habilidades básicas do que em habilidades altamente avançadas. Este é o Princípio de Pareto (mais conhecido como “Regra 80/20”) em ação: 20% do seu kit de ferramentas de habilidades realiza 80% do seu trabalho.

Meu professor atual gosta de dizer que “o domínio é apenas um básico realmente refinado”. Não negligencie o caminho para a maestria por causa de quão despretensioso ele parece.