O código limpo e a produtividade

Como desenvolvedor, nos deparamos com situações no dia a dia que nos fazem pensar se realmente levar alguns minutos renomeando o nome de uma variável pode ajudar a vida do próximo. Fazemos o nosso trabalho com prazer e nos sentimos desafiados conforme a complexidade do problema aumenta, entendemos o valor e a diferença prática do “clean code”, porém não vamos ser pretensiosos a ponto de assumir que um código bem escrito, pura e simplesmente, agrega valor a um cliente em potencial. O nosso código perfeito, que encaramos como obra de arte, não faz diferença se o seu produto final não for o sorriso do cliente, não se trata de fazer brinquedo, não é encaixar o frameworks “hypes” para contar aos seus amigos que você conhece uma biblioteca x,y ou z e que tal linguagem é tão boa ou ruim quanto dizem no mundo a fora, software deve ser construido com um próposito.

Todo mês são criadas dezenas de consultorias de software agarradas aos termos Agil e Craft, não me entendam mal isso não é uma crítica, pelo contrário, fico muito satisfeito em saber que o Agil e toda a sua essência está sendo difundida e o mais importante, o cliente já o encara como um diferencial, porém tudo de uma certa forma está ligado ao dinheiro e pra quem está do outro lado pagando a conta, quanto menos, melhor, mas nem sempre o mais barato é bom, então vamos pensar juntos: 3 empresas de software do mesmo porte e com a mesma cultura de desenvolvimento Agil/Lean, pregando os mesmos valores de entrega participam de um concorrência natural no mundo de software corporativo, 1 possui um portifolio de projetos mais abrangentes que é o diferencial e as outras 2 não possuem atributos que as diferenciam na prática, entendem que o diferencial aqui e para o consumidor do software é o velho cálculo custo/tempo? O tempo para se escrever um código limpo (você sabe do que estou falando) não pode ser comparado a um código mal escrito e sem cobertura de testes. O código limpo não agrega valor, porém software não é só código, já me deparei algumas vezes onde precisei alterar o comportamento de uma tela devido há uma restrição no código legado e que de tão fixo estava ao esquema de dados se tornou algo intocável, esse é um típico caso onde um código ruim começa a influenciar na qualidade do produto final. Essa é a pergunta que fazemos sempre que isso ocorre: devo refazer do zero ou dar qualquer jeito (gambiarra) para não alterar o código legado? Existem inúmeras maneiras de se lidar com código legado, existe até um livro especializado nisso(Working efectively with legacy code), mas essas questões são pertinentes apenas ao código e devem ser tratadas como tal, o que acontece 60% das vezes, concluimos que não vale a pena refazer e não mexemos no que já funciona. Isso vale para contextos maiores e softwares maiores, esse tipo de dúvida não deve ocorrer, ao menos não deveria, quando se reduz o contexto do software entregando pequenas releases sempre.

Quando estamos desenvolvendo um produto novo aqui na Ornitorrinko, consideramos sempre a tecnologia e o tempo de desenvolvimento, mas consideramos também com o mesmo peso, a entrega funcionando bem. O software fazendo o que ele precisa fazer para nós é tão bom quanto um código bem escrito. Faz algum tempo o Uncle Bob publicou um post, falando de desenvolvimento de software em Startups, falando que a galera tava esquecendo um pouco do XP e que isso algum dia atrasaria ainda mais atingir o roadmap e ele foi bastante criticado pela comunidade e principalmente pelos desenvolvedores que trabalham/possuem uma, pois sabemos que o tempo é tudo, precisamos entregar rápido para falharmos rápido. Se o pensamento for esse então não vale a pena investirmos nosso tempo escrevendo código bom com alto nível de reuso coberto com testes para que tenhamos a habilidade de mudarmos um funcionamento sem medo de afetar um outro. Eu digo investir o tempo, pois o desenvolvimento de um produto oriundo de uma Startup é diferente da criação de um produto de software dentro de uma empresa já constituida, pois nessa, possuimos os “luxos” de contarmos com uma equipe de arquitetura,devops, um dba se for o caso, logo a existência de ferramentas que auxiliam o desenvolvimento é muito mais efetiva do que utilizar frameworks open-source que procuram resolver problemas de uma maneira mais genérica. Para esse tipo de situações eu gosto de citar uma frase do livro Maverick do Ricardo Semler: “Use o senso comum”.
O senso comum vai te ajudar a distinguir o que pode ou não ser reaproveitado (não confunda com BDUF), o seu MVP não precisa ser impecável, ele pode ser só 50% bom, pois o resto você deve estar pronto para jogar fora.
O fato de se agarrar a produtividade como desculpa para um código ruim não é novidade. “Quero colocar rápido a maior quantidade de features no ar, não posso perder muito tempo resolvendo essas questões técnicas” essa é a maneira mais efetiva de se pensar quanto a concepção de um produto, até que os problemas de performance começam a demandar mais tempo que o disponivel e para resolver cada problema é necessário reescrever várias linhas de código, e o pior, sem cobertura, conforme o time adiciona novas features, uma nova espécie de bugs se inicia dentro do software. Temos que encarar essa situação de frente e resolver o problema de uma forma recorrente e que não afete a produtividade do time e a vida do seu produto, crie “equipes” dentro do time que focarão em eliminar o código ruim de uma maneira objetiva, provendo formas de se reutilizar a solução proposta para que combinadas com outras ferramentas disponiveis evitem que o código retorne para o software novamente e eliminando o código inutil ao máximo.

Deal with it

O código limpo é excelente, para quem entende de código, para quem entende de arte, um quadro com uma pintura abstrata pode ser muito valioso, mas pra quem não entende é um monte de rabiscos e não serve para eu pendurar na parede da sala. O nosso código “fantástico” é criado para que nós mesmos e nossos colegas de trabalho o admirem e o modifiquem de maneira fácil e que, em um certo período de tempo fará a total diferença de um produto, porém para a satisfação do cliente tenha como objetivo fazer a coisa certa sempre, e com alta produtividade.

Source: Ornito

Recent Posts

Leave a Comment