Após quase um ano atuando em um projeto desde sua concepção até sua primeira entrega, decidi "olhar pra trás" não somente para me questionar sobre tudo o que foi construído mas para também me questionar sobre onde eu e o time erramos.
A importância de uma arquitetura pré-estabelecida
Nesse projeto, seguimos uma especificação funcional. Uma especificação funcional contempla as funções básicas de uma aplicação.. opa, deixe-me repetir essa palavra: básicas.
Talvez seja muita presunção minha, mas, acredito que além de uma especificação funcional, um esboço de uma especificação arquitetural também fosse necessária. Como desenvolvedor que sempre trabalhou em startups pequenas e era recém-chegado na empresa, em muitos momentos a escala de centenas, milhares e até milhões de dados me fez cogitar saídas que, devido á escala, não eram viáveis. Não sei também em totalidade quais bancos e search engines temos á disposição ( e áo descobrirmos, muitas vezes é nosso primeiro contato com essas ferramentas ).
Com uma arquitetura mais pré-estabelecida conseguimos nos preparar melhor também no que viriam á ser débitos técnicos no conhecimento de ferramentas.
Por exemplo: nenhum dos desenvolvedores que atuou no projeto possuía efetivamente experiências anteriores com o banco de dados utilizado, e, o foco foi em "aprender fazendo" e não "aprender e fazer". E nisso nascem más-práticas que se proliferam pelas raízes projeto.
Dominar a linguagem e exercitar a modelagem de um banco é essencial para manter uma escala saudável no projeto.
Não tornar boas práticas desde o início
Julgo que temos uma qualidade de software mediana. Faltam muitas coisas, mas já seguimos bons padrões. Principalmente a falta de testes de integração no back-end é algo que efetivamente me preocupa á longo prazo.
Sempre fui entusiasta de testes e vejo a entrega de valor ( e a prevenção á incêndios ) que testes básicos porém bem estruturados entregam.
Há também alguns débitos técnicos no front-end: componentes grandes que poderiam ser menores, lógicas pouco e/ou nada comentadas e inconsistências em seguir alguns padrões dentro do sistema.
A falta de documentação estruturada
Esse aqui eu julgo ser um problema de muitas companhias: gerar documentação não gera valor efetivo pra stakeholders, mas, gera velocidade na criação de software. Até por isso, ferramentas como GraphQL que geram docs automaticamente têm seu valor intríseco.
Mas um swaggerzinho organizado não faz mal á ninguém 😂
Code review "camarada"
Julgo que aqui jaz o nosso maior erro: realizar pouquíssimos code reviews propondo efetivamente mudanças e/ou melhorias.
Quem melhor poderia nos policiar de subirmos inconsistências e códigos de qualidade duvidosa somos nós mesmos, e, por opção escolhemos deixar muita coisa passar.
Seja por pressa em "subir aquelas mudanças" ou em simplesmente acreditar que "isso é o jeito que ele(a) coda, não é melhor ou pior: é apenas diferente".
Mas.. tudo foi ruim e/ou mediano?
Não!
Na realidade, o projeto andou muito bem mesmo com as várias interpéries de um projeto realizado no mundo real. Construímos um sistema extremamente robusto e que resolve muitos problemas atuais e futuros da empresa, e sou extremamente grato por tudo que aprendi e aprendo diariamente participando da criação de um sistema do zero.
Top comments (0)