O dev e seu legado

Esses anos de carreira me deram muitas oportunidades e conhecimentos que eu não imaginava que poderia adquirir e assimilar. Ps: As vezes a gente esquece de alguma coisa mas faz parte.

E algo que vejo que soa quase como um insulto para alguns é trabalhar com sistemas legados. Quase todo mundo tem aquela velha tv em casa, que não é smart porém se colocar um chromecast ela ainda atende o seu propósito. Se você olhar na visão objetivo, ela ainda está cumprindo o seu. Mesmo que você tenha dado um plus usando um chromecast. Quando eu olho para uma aplicação eu tento entender para qual propósito ela foi criada, e se ela ainda atende o mesmo. Hoje nós temos várias fontes de informação por onde podemos conseguir dados, que podem ratificar que algo ainda é usual e que tem cumprindo o seu propósito. Quando você passa a enxergar que o propósito de um produto é retornar algum tipo de valor para alguém, talvez você consiga visualizar que dentro de um pipeline, aquele legado não merece seu nariz torcido. Talvez quando ele foi concebido fazia muito sentindo ele ser daquela forma.

A algum tempo atrás eu escrevi o post How to use Amazon SNS/SQS for integrate different systems que mostra um exemplo simples de como nós podemos construir aplicações desacopladas, que podem ter suas partes removidas ou alteradas de uma forma mais simples, sem afetar todo o cerne do produto. Hoje quando nós vemos o tamanho das aplicações, elas não são somente um simples site, que recebe alguns míseros requests e que talvez no fim do dia faça uma venda.

Você é quem está escrevendo o novo legado

Boas decisões fazem com que algo perdure por mais tempo dentro de um flow, saca? Cada peça que você adiciona ou não adiciona, pode fazer com que o seu código em um futuro não muito distante passe a ser um legado, e com pessoas que se arrepiam toda vez ao ter que aplicar um fix nesse código.

Tá e como podemos evitar ou pelo menos diminuir o impacto?

• Nunca pense que é apenas um MVP.
• Mitigue o máximo de cenários possíveis.
• Aplicações sem teste nem pensar!
• Não pense que nunca mais você vai precisar ver aquele código.
• Compartilhe o máximo de informação com seus pares e talvez até com outros times.
• Pense que você tem uma pilha de copos, e que se você precisar tirar o copo da base primeiro, isso não deveria ser muito doloroso.
• Não pense apenas no código rodando na sua máquina, onde ele vai rodar vai influenciar em como você deve fazer.
• Não faça só porque alguém pediu. Boas aplicações saem de bons diálogos.
• Micro commits e pull requests pequenos ajudam na hora do review.
• Não é porque todo mundo faz que é o melhor para oque você precisa entregar. Existem N formas de fazer a mesma coisa.
• Não tenha medo de errar.

A ideia aqui é criar algo bem básico, porém o desejo é despertar a sua curiosidade para pesquisar e encontrar o caminho. Espero que te ajude. Se tiver duvidas não tenha medo comenta ai, estamos aqui pra crescer juntos.