O que aprendi entregando o meu primeiro sistema web completo

Recentemente entreguei um projeto que (basicamente) consiste num sistema web para registro e consulta de ordens de serviço, clientes e pedidos, o ERM System. O cliente era uma oficina de eletrônicos de pequeno porte aqui em Santa Catarina, que estava utilizando um sistema antigo, não mais adequado para as suas necessidades.

Eles buscaram, então, a minha amiga @Luana, que também é desenvolvedora e já tinha proximidade com a empresa. Nós já havíamos colaborado em alguns projetos anteriormente e essa seria uma ótima oportunidade para nós dois.

Antes que pudéssemos de fato codar, nos deparamos com uma parte extremamente importante do processo, que inclusive pavimentaria o restante da jornada: o levantamento de requisitos.

Conhecendo as regras de negócio

Não faz sentido escrever código sem um propósito em mente. Por isso, precisávamos descobrir quais problemas a oficina tinha, e fazer o possível e o impossível para resolvê-los através de software.

Eles já tinham uma boa ideia de como queriam que fosse o programa, e cabia a nós captar o máximo de informações possíveis, principalmente sobre os processos internos da empresa e sobre a visão que eles tinham do futuro programa (como o imaginavam, como ele funcionaria no alto nível, etc.).

Claro que desde a ideia inicial até o produto final várias coisinhas podem acabar sendo reformuladas (e foram), seja por uma mudança na visão ou até mesmo por conta de limitações com tecnologia, tempo, custos, dentre outros fatores.

Mas o importante era que cobríssemos em nossas anotações a maior parte das funcionalidades esperadas (ao mesmo tempo em que bolávamos como iríamos amarrar todas elas por debaixo dos panos).

O que queríamos conhecer sobre a oficina, que é específico do seu nicho e da sua realidade, leva o nome de regra de negócio, e isso fica mais claro com alguns exemplos de regras de negócio que copiei das anotações que fizemos para o sistema:

• O usuário não deve poder alterar o tipo de uma OS (Ordem de Serviço)
• O usuário deve confirmar seu login e senha para cancelar uma OS
• Cada OS deve possuir um “número” único

Como podemos notar, são informações específicas do “universo” daquele tipo de negócio e, mais especificamente, daquela empresa. Não podemos simplesmente seguir nossa intuição para defini-las: não há quem conheça melhor as regras de negócio do que o próprio cliente, e é para ele que estamos fazendo o projeto, não é mesmo? :)

Se você tem interesse em saber mais sobre levantamento de requisitos, recomendo este post aqui, em que eu explico mais a fundo como fazê-lo levando em conta os diferentes tipos de requisitos.

Escolhendo as tecnologias

Com boa parte das funcionalidades esperadas em mão (num arquivo de texto, pra ser mais específico 😄), era hora de tomar algumas decisões a respeito de quais tecnologias utilizaríamos no desenvolvimento.

Pra ser honesto, a maior parte desse processo de escolha se deu antes do levantamento completo dos requisitos, porque já havia ocorrido um diálogo inicial com o cliente. Sendo assim, tínhamos um “norte” do que iríamos precisar para a tarefa e só fomos validando isso ao longo do levantamento.

De qualquer modo, algumas restrições nos fizeram tomar as decisões que tomamos:

• O sistema deveria ser acessado por um computador, e não havia necessidade de app mobile
• O sistema deveria ser acessado pelos computadores na loja matriz e na loja filial, de forma que as duas lojas interagissem com a mesma base de dados (que contém as ordens de serviço, pedidos e clientes) Precisávamos de um servidor com banco de dados e para a “interface” tínhamos basicamente duas opções válidas:
• Um programa executável
• Um app web (site)

Considerando o conhecimento que eu e a minha amiga temos, optamos por uma stack baseada em Javascript: Javascript/Typescript, Node.js e React. Uma das vantagens foi que, apesar de eu ter focado mais no backend e ela no frontend, ambos fizemos a integração entre os dois lados, portanto a escolha da stack facilitou nossa “interoperabilidade”, por assim dizer.

Por exemplo, se precisávamos encontrar a origem de um erro, ou mesmo fazer algumas alterações, éramos capazes de compreender e transitar entre o back e o front. De modo geral, o sistema foi estruturado assim:

No backend: Node.js (e o framework Express) para rodar o servidor, fazendo uso de um banco de dados PostgreSQL

No frontend: React (e libs como create-react-app, Axios e algumas outras mais específicas)

Toda a descrição do projeto, bem como as tecnologias utilizadas se encontram na página do projeto no GitHub.

O que o coração vê, o coração sente

Outra coisa que um bom levantamento de requisitos permite fazer, é imaginar e projetar mais facilmente a interface de usuário da aplicação.

Num cenário mais complexo (com uma equipe maior e membros mais especializados), esse processo provavelmente seria feito por uma pessoa responsável por UX, outra por UI, e assim em diante. Mas não era o nosso caso.

Na nossa “dupla de dois”, a Luana se encarregou do design e projetou uma interface que ficou ao mesmo tempo simples e eficaz, com a sobriedade que o nosso cliente esperava do sistema.

Se você tiver interesse, a interface foi feita no Figma, e está disponível na página do projeto no GitHub. Algumas coisas foram alteradas/adicionadas ao longo do desenvolvimento (como é de se esperar), mas a essência está lá ;) .

Os pepinos vão aparecer

Antes, durante, depois… Os problemas aparecem em diferentes formatos, tamanhos e urgências, e não é uma questão de se, mas sim de quando.

Não acredito que seja possível nos blindarmos deles, mas na tentativa de fazer isso (como todo perfeccionista xD), me deparei com algumas dicas:

• Testes, testes e mais testes: Eu sei, pode ser chato (e talvez você mesmo(a) tenha que fazê-los), mas eles são simplesmente necessários (no mínimo os testes unitários, mas também tem os de integração, funcionais, e por aí vai)!

• Uma equipe que esteja no mesmo barco: Ter conhecimento técnico para resolver os problemas (se eles forem problemas técnicos, é claro) é essencial, mas ter uma equipe que esteja no mesmo barco impulsiona a evolução do projeto além. De bônus, você ganha alguém com quem compartilhar as mesmas frustrações e objetivos.

• Ao desenvolver, priorize as tarefas que merecem atenção: Parece óbvio, mas na prática quando menos esperamos estamos aperfeiçoando o hover de um botão que mal vai aparecer no app 🤪. Então, se tem duas funcionalidades pra implementar, faça aquela que tem mais impacto; se tem dois bugs pra consertar, corrija o que traz mais dor de cabeça pro cliente…

E você? O que já aprendeu nos projetos que fez?

Conte um pouquinho nos comentários!