Eu e mais um colega estávamos no processo da criação de um negócio. Eu, como programador, e ele, como a pessoa experiente na parte de negócio.

Com meus três poucos anos de experiência, pude ter contato com o famoso código legado, e com as más práticas de programação. Tendo em mente isso, pensei em todas as etapas, e o que seria necessário, tecnologicamente, para poder colocar nosso projeto no ar, e foi pensando nisso tudo, que percebi como uma péssima escolha poderia custar muito.

Planejando a aplicação

Sem longos detalhes, a aplicação web terá uma parte administrativa, e outra parte do cliente, onde ele poderá efetuar algumas operações. Pensando no futuro, e no trabalho que já tive em meus trabalhos anteriores, eis que pensei na seguinte organização para meu projeto:

• SPA: Já trabalho com isso. Por que não usar algum lib para fazê-lo?
• API projeto: SPA, front, e api no back.

Tenho um pouco mais de três anos de desenvolvimento, estou só no projeto, enquanto desenvolvedor, e só poderei realizar as tarefas em meu tempo livre. O que posso fazer?

Otimização prematura

Otimize hoje, para não precisar otimizar amanhã.
Agora vamos retomar tudo isso para meu contexto?

Olhando para a imagem colocada acima, o que ela está dizendo para mim?

• Tempo: Estou sozinho nessa, e ninguém vai dividir a carga de desenvolvimento. Apesar de já ter trabalhado com sistemas assim, não tenho experiência para desenvolver tudo. O resultado? Vou demorar muito tempo para realizar o desenvolvimento de ambas as partes, e pra piorar, sempre que precisar adicionar algo novo, também levarei mais tempo.

O tempo culminará em um terceiro e mais letal ponto negativo, que deixarei mais pra frente.

Dando uma analisada melhor, percebi que essa talvez não seja a melhor abordagem, então vamos passar ao próximo tópico, e mostrarei como farei minha aplicação, e o que terei de negativo posteriormente.

Divida técnica

Pense nela como um empréstimo. Você conseguirá o que precisa, mas precisará pagar juros depois.

Agora o que acha de eu deixar a aplicação seguindo o esquema abaixo?

Séloko cachuera! Mas que arquitetura robusta :P.

Brincadeiras a parte, por mais simplória que possa ficar a aplicação, terei a seguinte vantagem:

• Tempo: Reduzirei drasticamente o tempo de desenvolvimento em comparação ao modelo anterior, onde faria a construção de uma api e spa. Aqui, back e front se unem, dando mais velocidade no desenvolvimento.

Esquerda ou direita?

No primeiro caso, percebi que estava construindo uma aplicação que me proveria um melhor crescimento no futuro — mas não o ideal — , mas que dificultaria o desenvolvimento do produto. E no segundo caso?

Deixar a aplicação tudo junto e misturado realmente é uma baita ajuda inicialmente, mas o problema começará a surgir futuramente, quando a aplicação ficar maior, quando mais pessoas estiverem no projeto, quando mais clientes acessarem minha aplicação.

A dívida técnica, como o nome diz, é o que acontecerá por aceitar um mau design para minha aplicação. Com o tempo, ficará mais difícil dar manutenção e adicionar novas features. A partir dela, terei o mesmo problema que o primeiro caso: tempo. Gastarei mais tempo e dinheiro para manter, e melhorar o produto.

E o que essas duas abordagens tem em comum?

Time to market!

O tempo nos dois casos, vai acabar culminando em um problema com time to market.

Quanto mais tempo eu demorar para disponibilizar algo novo para meu cliente, mais tempo um concorrente tem para desenvolver algo melhor. Quando mais tempo eu demorar para corrigir algo, maior será a chance de meu cliente abandonar o serviço.

O modo como você escolhe desenvolver sua aplicação afeta sim o negócio, e muito!

Sabendo disso, qual é a abordagem correta?

Apesar de cair em qualquer um dos casos ser ruim, muito pior que criar uma dívida técnica, é abraçar um otimização desnecessária, que só vai dificultar o desenvolvimento inicial do produto. Ele ainda não existe, então por que dificultar sua existência?

A mensagem que deixo para o final disso tudo, é simples:

Abrace a dívida técnica para crescer, mas saiba deixá-la quando tiver crescido.

Esse texto foi feito com base em uma talk que fiz na Pagar.me. Para vê-la, clique aqui