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

Provas de Conceito valem o esforço?

Sim! Fim do artigo.

Ok, você já sabe a minha opinião, agora vou tentar te explicar o porquê acredito na ideia de usar Provas de Conceito (Proof of Concept - PoC) sempre que possível.

O conceito por trás de uma PoC é responder a pergunta: "Se eu fizer desse jeito, será que resolve meu problema?". Aí você faz e descobre na prática se aquilo realmente resolve seu problema. E portanto, imagino que pode ser usado em qualquer área, além da programação.

Uma PoC por via de regra foca em validar uma ideia principal e portanto ela possui uma característica que é fundamental para um bom processo de desenvolvimento de software (embora isso não seja a regra do mercado) que é: Fazer somente o que é necessário. Nela, você vai testar se uma determinada abordagem, ferramentas, ou técnicas vão de fato resolver o seu problema e tudo que é periférico, você resolve depois, quando a implementação oficial for acontecer, se é que seja necessário.

Para ilustrar a ideia, a seguir eu relato uma experiência recente que tive em um projeto onde usei PoCs para me certificar que escolheria a melhor abordagem para resolver o problema do cliente.

React-Native e tarefas em segundo plano

O cliente possuía um aplicativo react-native e precisava que uma rotina de monitoramento fosse executada constantemente, e que fosse o mais reativa possível.

O React-Native possui uma API chamada Headless JS, que basicamente permite executar serviços nativos em segundo plano (cria uma ponte) -aqui, vou citar como resolvemos a implementação Android apenas.

No Android, você possui inúmeras formas de se executar um serviço em segundo plano: Work Manager; Alarm Manager; Download Manager; Serviços na thread principal.

Cada um deles possuía uma limitação, e o que eu fiz? Isso mesmo, testei cada uma das possibilidades para descobrir qual era a que melhor resolvia o problema específico do cliente.

No final das contas, optei por executar os serviços na thread principal, por conta justamente do ciclo de vida, e certamente o que tirei de proveito disso é que:

  • Pude notar qual a abordagem mais indicada para o caso específico e tive um vislumbre de problemas que eu poderia resolver com as outras abordagens;
  • O código desenvolvido na PoC foi totalmente reaproveitado, então não precisei reescrever código, pois o que foi feito ali e que resolvia o problema já estava pronto;
  • Um conhecimento foi construído ali, e certamente se eu precisar lidar com problemas parecidos, já terei uma base mais consistente para escolher uma abordagem que resolva problemas da mesma natureza.

Honestamente, não há uma resposta pronta para entender o melhor momento de optar por PoCs, porém, a régua que uso é: "Eu sei como resolver o problema? Ou eu acho que sei?". Se eu não sei, ou não tenho certeza, opto por sugerir o desenvolvimento de Provas de Conceito.

Se você gostou da discussão que abri aqui, deixe um comentário com o seu ponto de vista, e compartilhe com sua rede para que esse texto possa ser lido por mais pessoas (se você achar que ele precisa ser lido por mais pessoas haha).

Um forte abraço!

1

Sensacional meu caro! Concordo com você e isso para mim é o que separa uma Prova de Conceito de um Minimum Viable Product (MVP).

Na verdade, na minha visão uma coisa que realmente faz essa separação é que a PoC você não pode se sentir mal de jogar fora. Digo isso porque se você está escrevendo um código com altíssima qualidade, testes automatizados, ou outros acessórios, possivelmente você não está fazendo uma PoC. Se você conseguir reaproveitar, ótimo (como foi o caso do seu exemplo), mas se precisar reescrever tudo do zero, pois descobriu de fato o que queria e precisava fazer, será um processo super natural.

Eu vejo muito a PoC como um rascunho, que pode ou não ter sua versão final escrita em forma de MVP. Faz sentido?