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

A verdade proibida sobre VibeCoding, Clean Code e dev que só entrega a primeira versão

Hoje eu publiquei um vídeo falando de uma coisa que muita gente vive, mas quase ninguém assume em público: O mercado ama quem entrega a primeira versão de um produto. Sempre foi assim e sempre vai ser

O mercado se impressiona com MVP funcionando e não com código que vai sobreviver depois do hype. Teve gente que virou CTO só porque conseguiu entregar o MVP e não porque sabia nem manter um sistema vivo direito.

Enquanto isso, outra parte da comunidade caiu no extremo oposto, meio que matando várias startups com overengenieering. Clean Code virou vaidade e Clean Architecture virou desculpa pra travar a equipe. Muita gente começou a usar “boas práticas” pra fazer bloqueio intelectual, barrar PR por detalhe inútil e criar uma verbosidade que ninguém precisa. E aí o que acontecia era que ninguém entregava nada.

Agora o VibeCoding repete o mesmo ciclo. Entrega rápida que impressiona, hype instantâneo, todo mundo falando que “é o futuro”, "isso aqui é game changer" e essas merdas aí. E na hora da manutenção? A dor é a mesma. Sempre foi criar feature em cima de código cagado feito pra lançar. Construir a primeira versão nunca foi o desafio real da maioria dos softwares. O problema aparece quando o produto cresce e você precisa mexer de novo.

Deixa sua opinião nos comentários do vídeo, vamos trocar uma ideia

Carregando publicação patrocinada...
6

Trabalhei numa antiga fintech (Geru), em meados de 2021, lá tudo foi feito com Python 2. 🐍

Questionei o porquê, afinal a empresa era jovem e na época o Python 3 já estava consolidado (e a versão 2 já estava depreciada).

A resposta: "O fundador só abriu o terminal, começou a codar, e entregou o MVP. O Python padrão do S.O. dele era a versão 2" 🤷

Por causa disso a empresa teve um débito técnico tão grande que foi mais fácil mergear com outra fintech, e usar o sistema deles (Java). 🤡

3

Eu lembro da Geru, não sabia que tinha essa treta interna hahaha Cara, tem coisas que valem a pena fazer rápido com dívida técnica mesmo, mas dá pra ter o mínimo de preparação antes de sair codando igual maluco hahaha

Imagina, maluco puxa pra desenvolver e na máquina tá o React 15, um Java 7. Ele num consegue parar 15 minutos pra atualizar? kkkk Precisa lançar um legado de 2015 que foi feito em 2025? Sem condições. Mas, caso aconteça, o cara ainda sai com moral e quem se fode dando manutenção sai queimado kkkkkkk "O cara fez tudo sozinho e tu num consegue só fazer um ajustezinho?"

2
1
2

Eu não sei os outros Devs, mas quando eu começo um projeto eu vou apenas codificando pensando em fazer funcionar. Uma vez que funciona, faço um commit, depois refatoro tudo para boas práticas (não demora tanto, pois com um tempo as boas práticas e seu consciente se tornam uma, mas erros são inevitáveis), faço os respectivos commits, e por fim implemento os testes. Se passar em tudo, ai sim é a versão 1.0 do meu projeto.

2

Meu fluxo é mais ou menos parecido. Inclusive se é uma tecnologia que não domino, eu faço e vou ajustando com a leitura de artigos. Então sai rápido e mais ou menos decente

2

Poha mano!
Você disse tudo. Boa parte dessa firula é tudo masturbação de ego. Só isso.

Não adianta cacete nenhum um "clean Code" que só deixa mais complexo.
Fazer o simples, hoje já não é tão simples mais...

Parabéns pelo conteúdo!

1
1

Nem tudo é uma merda. Sou desenvolvedor.net desde 2001. Minha especialidade vem antes dessa separação de backend e frontend. Sou old school. Nos últimos anos, tenho gasto mais tempo gerenciando equipes do que codificando, principalmente quando se trata de frontend.
Como exemplo, a história é a seguinte: estive em um projeto, onde tínhamos um prazo curto para entrega e equipe pequena. Por falta de tempo, a parte do front, deixei a cargo de um programador que entregou o que precisava ser feito. Mas eu não revisei. Passou um bom tempo, o programador não estava mais conosco e precisei dar manutenção. Resultado: um monte de coisa para refazer.

Recentemente comecei um projeto particular. Nessa onda do Vibecoding, decidi experimentar usando o aistudio.google.com. A experiência tem sido surreal. Na primeira versão do código ele gerou alguns arquivos .tsx e todo o código nele.
Pedi para refatorar e quebrar em componentes, views, módulos, colocar em pastas separadas de acordo com o recurso que estava sendo gerado, etc.
Resultado foi um código limpo e fácil de entender. Bem mais fácil de entender do que o código do programador. Fiz apenas ajustes pontuais.

Longe de ser perfeito, mas em 5 noites, me economizou o trabalho de uns dois meses de codificação.

Conclusão: a gente precisa saber usar a ferramenta que temos em mãos, senão, sai uma merda mesmo.

Não saber usar a ferramenta seria como ter uma ferrari e andar como se estivesse dirigindo um fusca.

1

Achei sensacional o debate e me identifiquei bastante! No fim das contas, o mercado valoriza mesmo quem põe o produto pra rodar, mas quando a bomba da manutenção explode, ninguém quer assumir. Já vi projeto virar orgulho de CTO só porque foi feito no modo “correria”, mas depois fica aquele Frankenstein que ninguém entende.

O segredo está no equilíbrio: não dá pra ser refém de “boas práticas” só pra aprovar PR e travar entrega, mas também não dá pra meter o louco e transformar débito técnico em regra. MVP rápido é show, mas se não pensar um mínimo além, depois todo mundo que mexer no código vai sofrer (e ninguém lembra do cara que começou o caos, rs).

No fim, entregar é importante, mas entregar com consciência salva a vida de quem vai manter depois!

0