Estou lendo este livro sensacional chamado "The Pragmatic Programmer" (aka O programador pragmático). So far, so good. Esta é uma tentativa de sumarizar alguns aprendizados do livro conforme eu vou lendo e aplicando no meu contexto real.
Sobre vidros quebrados
Sabe aquele prédio que até um mês atrás havia apenas um vidro quebrado e conforme o tempo passou, ele veio se deteriorando dia após dia? Acredite ou não, poderia ser o seu código.
O que quero dizer é que um erro besta de arquitetura, design pattern e decisões de negócio podem afetar o seu código no futuro se você não tratar o quanto antes. É como um virus que se estabelece e há de ser tratado o quanto antes.
Meu contexto
Recentemente refatorei toda uma aplicação front-end na empresa em que trabalho pois a codebase anterior estava atrofiada a tal ponto que era complicado adicionar novas features. Como se tratava de um MVP, tento entender a pressa e as decisões escolhidas no momento. E, também por ser um MVP, refatorar não foi muito custoso. O resultado vem sendo um produto bom pro desenvolvedor e bom pro usuário.
Mas recentemente me peguei tomando decisões ruins na organização de pastas e arquivos, e na arquitetura no geral. Fui capaz de perceber que aquilo não escala, mas fui empurrando com a barriga até o momento atual.
Conclusão
Esta parte do primeiro capitulo de O programador pragmático serviu para deixar claro algo que eu já sabia, e foi o empurrão necessário para eu voltar e melhorar o meu código e não cometer o mesmo erro que cometeram no passado.
Com o objetivo de me tornar um melhor desenvolvedor, este capitulo deixou bem claro pra mim o primeiro passo que devo tomar. Deixar sua codebase atrofiar sabendo que poderia melhorar te faz irresponsável, e não é o que queremos, correto?
Top comments (0)