Executando verificação de segurança...
8

Além das frases, acho interessante também explicar um pouco o motivo de eu não gostar delas. Afinal, apesar de parecer um post mais zueira, dá pra usar como ponto de partida para uma discussão um pouco mais aprofundada :-)


"Mas a boa prática é fazer assim"

Tenho visto que muitas vezes o termo "boa prática" é usado como "lei inquestionável", ou algo que a pessoa só quer impor sem precisar explicar os motivos.

Sendo que na verdade o que deveríamos fazer é sempre analisar o contexto, conhecer e avaliar os prós e contras de cada alternativa, a viabilidade (se é muito caro e/ou demorado e/ou o time tem capacidade/conhecimento ou pode compensar essas deficiências em um prazo aceitável), etc etc etc. E só depois tomar uma decisão.

Claro que tem coisas que ao longo do tempo se mostraram melhores em determinados cenários (ou na maioria deles), que as pessoas acabam escolhendo no automático, sem pensar muito. Mas ainda sim, sempre cabe uma análise só pra ter certeza que vc está escolhendo a melhor opção técnica com base no seu caso específico, e não só porque alguém disse que "é boa prática".


"Ah, mas o Google/Netflix/Amazon/Facebook/qualquer-outra-empresa-grande-famosa-hypada faz assim"

E a resposta pra isso é a clássica "Você não é o Google!" (e nem a Amazon, Netflix, Facebook, etc).

Cada empresa tem seu contexto específico, que não necessariamente se aplica ao seu caso. Só porque uma empresa grande e/ou famosa e/ou hypada fez de um jeito, não quer dizer que todo mundo deveria fazer igual, e muito menos que isso garantirá algum sucesso. Contexto é tudo.

O que eu acho razoável é, no máximo, usar algumas técnicas como inspiração: ideias que podem ser adaptadas para o meu cenário, fazendo os devidos ajustes de escala, proporção e contexto.

Mais uma vez, cai na história de avaliar caso a caso, ver os prós e contras, o que faz sentido na situação específica, e só então escolher a solução mais adequada. É muito legal ver o que outras empresas estão fazendo, principalmente as grandes, mas nem tudo que elas fazem vai servir pra você (e muitas coisas só servem para elas, aliás, pois só fazem sentido para o caso específico delas).


"Precisamos reescrever em [linguagem]"

Tem um artigo antigo do Joel Spolsky (um dos fundadores do Stack Overflow e um dos responsáveis pelas primeiras versões do Excel) que é justamente sobre reescrever software. Tem alguns trechos que acho bem interessante.

Ele cita uma função do Windows que servia somente para "mostrar uma janela na tela", mas a equipe reclamava que era muito longa, "tem duas páginas!", e estava cheia de coisas estranhas que ninguém entendia para que serviam. Seguem alguns trechos (em tradução livre):

Essa ideia que código novo é melhor que código velho é um grande absurdo. Código velho foi testado. Vários bugs foram encontrados e corrigidos.

Sobre a função de duas páginas. Sim, é uma função simples para mostrar uma janela, mas está cheia de coisas estranhas que ninguém entende. Bom, eu explico: essas coisas são correções de bugs. Uma delas corrige o erro que deu quando a Nancy tentou instalar em um computador que não tinha Internet Explorer. Outra corrige um erro que ocorria em condições de pouca memória. Outra corrige um erro que aconteceu quando o arquivo está em um disquete que o usuário removeu no meio do processo. Aquela chamada a LoadLibrary é feia mas faz o código funcionar em versões antigas do Windows 95. (obs: eu disse que o artigo era antigo, né?)

Para serem encontrados, cada um desses bugs precisou que o programa fosse usado por semanas em condições reais. Algum programador deve ter gasto dias reproduzindo o erro e consertando-o. Não importa se são muitos bugs, se a correção só tem uma linha ou vários caracteres, pois muito trabalho foi feito para adicioná-los.

Quando vc joga código fora e recomeça do zero, está jogando fora todo esse conhecimento. Todas essas correções. Anos de trabalho de programação.

Vc está jogando fora sua liderança de mercado. Está dando 2 ou 3 anos de presente aos seus concorrentes, e acredite, isso é muito tempo no nossa área.

Vc está se colocando em uma posição bem perigosa, na qual está lançando uma versão antiga do código por vários anos, completamente incapaz de fazer mudanças estratégicas ou reagir a demandas do mercado, porque não tem um código entregável. Talvez tenha até que fechar neste período.

Vc está gastando um monte de dinheiro para escrever código que já existe.

Não estou dizendo que nunca devemos usar tecnologias mais novas e modernas. Mas também não dá pra achar que reescrever tudo é algo factível.

Imagine um sistema com milhares, ou até milhões de linhas de código. Reescrever do zero é loucura. Mesmo que se use alguma ferramenta para automatizar, sabemos que há muitas diferenças conceituais entre as linguagens e nem sempre é possível fazer algo totalmente automático. É algo que vai demandar muito tempo, e em paralelo vc ainda vai precisar dar manutenção no sistema atual: novas funcionalidades e correções de bugs, que também precisarão ser migradas para a nova linguagem.

Talvez por isso na maioria dos casos costuma-se ter um meio termo: coisas novas são feitas na tecnologia nova, e talvez correções também. E alguns trechos mais estratégicos podem ser candidatos à reescrita (depois que avaliou-se que pode ser feito em um prazo razoável). Assim, migra-se aos poucos, até que um dia - idealmente - a maioria (ou pelo menos as partes mais estratégicas) estejam tecnologia nova. Bem mais realista do que reescrever tudo do zero.

Carregando publicação patrocinada...
2

É ainda mais desgastante quando qualquer uma dessas frases vêm com: "by the book"... Aí a gastura vai longe.

"É porque, by the book, no SCRUM ..." 👋++
"Conforme os princípios ágeis, by the book..."👋++
etc

0