A importância de planejar antes de codificar

Quando falamos em desenvolvimento de sistemas, é normal pensarmos na codificação, como os dados irão se relacionar, como as tabelas irão ser estruturadas e relacionadas entre si, a medida que pensamos nesses pontos, já entramos no desenvolvimento do projeto, escolhendo a tecnologia de banco de dados (MySQL, PostgreSQL, MongoDB), o framework e linguagem que irão ser utilizados, estrutura de pastas, seguindo padrões como Clean Arch, Hexagonal Arch, DDD, dentre outros padrões. Pensamos em todos esses pontos, mas muitas vezes esquecemos de pensar qual o propósito do sistema existir e ser desenvolvido, qual problema ele irá resolver. A codificação é importante? Sim, claro, mas primeiro temos que pensar em estruturar nosso projeto de modo a minimizar os riscos, custos com refatorações desnecessárias. Resumindo, temos que pensar o sistema além das tecnologias e sim no domínio, no core do sistema, nas funcionalidades e no que ele se propõe a resolver. Assim reduzimos o risco de um sistema nascer fadado ao fracasso, mesmo tendo utilizado todas as boas práticas de programação, mas no fim ele não resolve o problema do cliente, e é inútil a sua existência.

Bom, o texto acima é bonito, empolgante até, mas como pensamos em um sistema do “jeito” certo?

Focar na descrição clara das funcionalidades, levantar os requisitos funcionais e não funcionais, planejar a criação de casos de uso que realmente atendam ao desejo do cliente. Também podemos utilizar diagramas de classes que irão mostrar a interação entre a camada de domínio do sistema, diagramas de sequências para aprofundar no fluxo esperado de cada nova funcionalidade.

Você pode falar: mas, se for pensar em todas as funcionalidades antes de se iniciar o desenvolvimento, nunca iremos finalizar o projeto. Concordo com você, mas a questão que estou querendo passar é que, iniciar um novo sistema, ou pegar uma tarefa do backlog do projeto em que esteja trabalhando, primeiro tente pensar em como aquela funcionalidade poderia ser desenvolvida, pense em como ela irá impactar o cliente, quais maneiras você poderia implementá-la de modo a gerar uma boa documentação da mesma. Sabemos que em muitos casos, tarefas feitas sem planejamento são encontradas novamente no futuro para correção de bugs, correção de más práticas de programação, decisão equivocada de um fluxo, não atende ao que o cliente esperava da funcionalidade.