Conhece aqueles desenhos que os músicos de uma orquestra leem enquanto tocam a música? A partitura, cheia de linhas e símbolos. Na música ela é utilizada de forma universal, para qualquer músico, de qualquer lugar do mundo, que fale qualquer idioma, conseguir tocar qualquer música escrita ali. Isso só é possível porque a partitura foi padronizada como uma forma de escrever uma música, uma linguagem universal.
Mas o que partitura tem a ver com desenvolvimento de software?
Numa conversa aleatória, na base da cerveja é claro, foi comentado sobre o tempo em que um desenvolvedor demora para se entender com o código. Nisso, foi relacionado a partitura com os padrões de desenvolvimento, assim como qualquer músico que saiba ler uma partitura consegue tocar qualquer música feita por outro músico sem sequer o conhecer, qualquer desenvolvedor que saiba os padrões da *stack *do projeto, consegue se entender rapidamente a ponto de em pouco tempo conseguir adicionar uma feature nova ou corrigir um bug.
Os grandes projetos de software livre definem padrões
Muito provável que o repositório daquele seu framework favorito tenha um arquivo chamado *CONTRUIBUTING.md *com todas as instruções e padrões para aquela sua PR **linda **ser aceita e ir pra *branch *principal. Vou deixar o exemplo do *flutter *para dar uma olhadinha. Procure pelo repositório de seus frameworks favoritos, eles provavelmente devem seguir padrões.
Ser escalável não é hospedar na Amazon
Sabe aquele tio ou primo, um gênio incompreendido, que viu alguma palestra sobre *startups *e brotou com uma ideia estranha? E que quer alguém que saiba mexer com *AWS *pro produto genial dele ser escalável? Então, eu ainda não entendi o que faz pensar que é só tacar lá que vira um *puta software escalável. *Ser escalável não se limita ao custo de servidores, abrange também o custo humano, nisso existem duas frentes, a galera que cria as novidades e a galera que corrige o que já está rodando. Nessa segunda frente, um software mal feito, pode acabar pesando no custo, e com isso nessa tal de escalabilidade.
Querendo ou não, é impossível pegar todos os bugs e erros de um sistema grande antes de enviar pra produção. Pode ter 100% de cobertura de testes automatizados e mais os testes manuais que sempre terá alguma coisa que não foi prevista. E para conseguir diminuir ao máximo os erros e bugs em produção, o processo de desenvolvimento deve ser muito cuidadoso e rigoroso, obrigando os desenvolvedores a testarem e escreverem testes, seguir o design do código e os padrões de desenvolvimento estabelecidos. Tudo isso colabora para evitar problemas em produção e não criar a bola de neve que código ruim causa e evitando custos adicionais como horas extras da galera que trampa no feriado pra corrigir um erro 500 naquele módulo indispensável pros clientes.
O ciclo de vida não pode terminar em um “software novo”
Não são poucos casos que escutei de software que precisaram serem reescritos pra poderem receber novas features. E todos esses casos foram por ir criando a base de “duas coxadas e uma barrigada”, cuspindo código adoidado pra entregar logo porque tem que ter tal coisa pro próximo pitch *com investidores ou com uma apresentação pra um possível grande cliente. Esse famoso atrito do pessoal de vendas/gestão com o pessoal técnico pode custar muito ao longo do tempo. Mas ainda existe a outra ponta, a ponta dos software que nunca termina as correções de erros e bugs, que cada vez mais se contrata desenvolvedor para ir corrigindo, e a cada correção se cria um novo bug ou erro. Repita comigo: “*Encher a empresa de devs não faz as coisas serem mais rápidas”. Um código fonte ruim gera desanimo, e desanimo pode gerar alta rotatividade, e trocar de funcionário custa muito mais que manter. Até esse novo chegar ao nível de desempenho do anterior demora. É claro que é impossível ter um código totalmente limpo, simples e fácil de entender em um sistema grande, mas é aquele ditado: faça o seu melhor nas condições que você tem, até ter melhores condições para fazer melhor ainda.
Aquele velho blá blá blá de sempre
Sim, vou terminar esse texto repetindo o que provavelmente o sênior do teu trampo já repetiu várias vezes, padrões de desenvolvimento não são frescuras e se vocês acha que é frescura, releia esse texto.
tl;dr:
Esse texto foi escrito baseado em experiência própria e em conversas com outros devs e galera da área. Não leve nada ao pé da letra, ou leve, particularmente eu to nem ai :)
Top comments (0)