Se você já trabalhou com aprendizado de máquina ou ciência de dados, sabe que os códigos podem acabar se tornando complexos. Conforme vamos nos aprofundando no projeto e criando novas análises e novas visões, vamos adicionando novas partes no código. E cada nova parte de código, aumenta a complexidade do código inteiro.
Embora não possamos - e não devamos tentar - escapar da complexidade essencial de um problema, muitas vezes adicionamos complexidade acidental desnecessária e carga cognitiva desnecessária por meio de hábitos de programação inadequados, como:
Não criar segmentações. Quando escrevemos todo o código em um único notebook sem quebrar em funções ou classes, forçamos o leitor a ler muitas linhas de código para descobrir o que o código está fazendo.
Funções longas que têm várias funcionalidades. Isso nos força a manter todas as transformações de dados intermediários em nossa cabeça, enquanto trabalhamos em uma parte da função.
Não criar testes unitários. Quando refatoramos, a única maneira de garantir que não quebramos nada é reiniciar o kernel e executar o(s) notebook(s) inteiro(s). Acabamos tendo que a assumir a complexidade de toda a base de código, mesmo querendo trabalhar apenas em uma pequena parte dela.
Neste artigo, compartilhamos quatro hábitos e uma técnica de refatoração do mundo do desenvolvimento de software que nos ajudaram a gerenciar a complexidade em nossos projetos de ciência de dados. De acordo com nossa experiência, isso pode levar a ótimos resultados de entrega, conforme ilustrado aqui:
Figura 1: Esses hábitos de codificação são um meio para atingir o objetivo final de tornar o trabalho gratificante, habilitando cientistas de dados a trabalhar com eficiência e entregar valor a clientes de forma mais confiável.
Se você tiver interesse em saber como essas práticas podem ser aplicadas em seus projetos de aprendizado de máquina ou ciência de dados, entre em contato e teremos prazer em conversar com você.
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.