Amazon CTO compartilha o segredo para escrever ótimos códigos

O melhor código será executado por décadas, diz o CTO da Amazon, Werner Vogels. Como você pode ter certeza de que seu código vai durar?

Se você tiver a sorte de encontrar Werner Vogels, CTO da Amazon, em uma preguiçosa tarde de domingo em Amsterdã, você pode fazer o que essa pessoa fez e perguntar: “Como devemos pensar diferente sobre desenvolvimento de software?”

Ao que Vogels respondeu: “Seu software precisa ser operado por décadas a mais [than it takes for] vocês [to] escreva.”

Embora isso signifique que o software se qualificaria como legado, isso é apenas uma indicação de que você escreveu algo que as pessoas ainda querem usar, anos ou décadas depois. No entanto, nem sempre é fácil entregar o tipo de longevidade que Vogels sugere que os desenvolvedores devem aspirar a entregar.

As coisas estão prestes a ficar chatas

Já escrevi antes sobre por que chato é bom quando se trata de escolher tecnologia corporativa como bancos de dados. A primeira consideração de uma empresa é permanecer no negócio, manter os aplicativos em execução etc. Assim, é importante escolher soluções com recursos e modos de falha bem compreendidos.

VEJA: Como construir uma carreira de desenvolvedor de sucesso (PDF grátis) (TechRepublic)

Mas há outro aspecto de “chato” e aplicativos, e isso envolve a abordagem mais básica para resolver um problema de negócios específico. Como o desenvolvedor Manuel Odendahl observou, ele consegue “criar consistentemente produtos de grande valor” com código que é “muito burro” sem “matemática maluca” ou IA maluca. Em vez disso, seu segredo é “fazer muitas perguntas” para “entender quais informações a empresa precisa, em contraste com os dados que ela realmente processa”.

Ao fazer perguntas para saber exatamente quais informações o aplicativo precisa consumir e distribuir para atender a uma necessidade comercial, ele consegue manter o aplicativo simples.

“Quanto mais simples o caminho que a informação percorre para ir de A a B, melhor o sistema se torna. Como fizemos as perguntas certas, o software está mirando direto no alvo, resolvendo os problemas reais de negócios.”

Esse é um princípio extremamente valioso e muitas vezes esquecido que é fundamental para a capacidade de e de software a longo prazo. Isso se torna ainda mais importante porque, como o executivo de engenharia da AWS Matt Wilson corretamente chamou a Vogels, “software executado em um sistema operacional raramente termina de ser escrito”.

Ao manter o código o mais limpo ou elegante possível, os desenvolvedores facilitam a melhoria meses, anos ou décadas depois. É também aí que entra uma boa documentação.

Se você não documentou, não aconteceu

A boa documentação começa, salientou o defensor do desenvolvedor Mason Egger (conforme capturado por David Cassel na PyCon 2022), com o mesmo princípio básico destacado por Odendahl – manter as coisas simples. No caso da documentação, Egger observou que os desenvolvedores devem articular um objetivo claro que a documentação ajudará seus leitores a alcançar. Não há necessidade de sobrecarregar o leitor com excesso de palavreado; o desenvolvedor está nos documentos para fazer algo, então dê a eles tudo o que é necessário para realizar esse trabalho e não perca seu tempo com mais.

VEJA: Kit de contratação: desenvolvedor Python (TechRepublic )

De acordo com Egger, na maioria das vezes, um desenvolvedor pula direto para o código de amostra em vez da explicação, e é por isso que ele defendeu o uso de exemplos do mundo real. Egger também destacou a necessidade de tornar os documentos facilmente pesquisáveis, para que o leitor possa encontrar rapidamente as informações de que precisa. Também é importante escrever da forma mais simples possível, sem usar jargões ou palavras desnecessariamente complicadas. O objetivo é sempre a simplicidade e a brevidade.

Com exemplos de código e texto explicativo, também é importante verificar novamente se você não deixou erros inadvertidamente nos documentos.

“A única coisa pior do que nenhuma documentação é a documentação incorreta”, disse Egger. “Porque nenhuma documentação significa que eu vou em outro lugar para procurá-la. Documentação incorreta desperdiça meu tempo.”

Essas (e outras) dicas de documentação ajudam a garantir que alguém que encontre o código de amostra dias, semanas ou anos depois possa entendê-lo mais facilmente, o que, por sua vez, significa que é mais provável que ele o use. Assim, o próprio software, bem como a documentação para ele, precisa ser o mais simples possível hoje para torná-lo legível e utilizável por muitos amanhãs.

Aumente seu conjunto de habilidades de TI e codificação com estes recursos da TechRepublic Academy: