A pergunta que sempre faço quando vou desenvolver algo, seja pra mim, ou seja no trabalho é: "Eu preciso mesmo disso?". E durante todos esses anos na profissão, muita coisa eliminei da minha rotina, e muita coisa aprendi a dosar, pra não gerar burocracia demais aonde não é necessário.
Aqui, vou me ater apenas à explicar como desenvolvo meus projetos pessoais, pois no trabalho, por conta de processos de desenvolvimento já definidos, fica difícil sair da linha sem que o processo em si seja modificado (Trabalho em uma empresa certificada MPS-Br).
Minha explicação será dividida em tópicos, sendo cada tópico a representação real de um passo no meu processo de desenvolvimento. Sendo assim, vamos ao que interessa!
#1 Concepção da Ideia: quais são meus casos de uso principais?
É fundamental ter ideia do que você quer fazer. Parece primário isso, mas muita gente desiste de uma ideia no meio do caminho por não saber exatamente a "forma" dela. Nesse sentido, sempre penso: Quais são os casos de uso principais? Ou seja, quais funcionalidades realmente geram valor para meu produto? É isso mesmo que quero resolver com esse produto?
Geralmente vejo muitos devs gastando horas desenvolvendo login, recuperação de senha, cadastro, quando na realidade, seu caso de uso principal é a gestão de uma única informação. Oras, porque não começar pelo caso de uso principal?
Sempre faça essa pergunta: Eu preciso mesmo disso? (Eu preciso mesmo de login?; Eu preciso mesmo de um cadastro de perfil completo?). Se precisar, e não for seu caso de uso principal, deixe pra depois. Sem dó!
#2 Projetar as interfaces
É engraçado como para a maioria dos profissionais em início de carreira, o termo interface é entendido apenas como: "As telas do sistema; o layout gráfico". A realidade é que interface é tudo aquilo que propõe uma ligação lógica entre duas entidades - sejam elas humano-computador, ou sistema com sistema.
Vamos supor um cenário aonde Eu tenha uma arquitetura com: Um sistema web; um app mobile; e uma API no backend para lidar com as regras de negócio. Nesse contexto, devo projetar as interfaces gráficas que são aquelas que o usuário terá contato (geralmente uso Balsamiq para protótipos de baixo nível, e quando tenho a oportunidade de ter um designer na equipe, ele se encarrega de fazer os protótipos de alto nível), e de quebra elaboro a interface JSON (geralmente trabalho com esse formato) que o backend deverá servir para os apps web e mobile, já pensando em cada endpoint. Com o JSON definido, fica muito mais fácil os avanços das 3 partes acontecerem em paralelo (quando se tem uma equipe pra isso), pois o "acordo de interface" já existe e o front web e mobile não dependem da API avançar as entregas.
Dica: Se você estiver usando um framework javascript (node que seja), recomendo o uso da lib Json Server, que permite simular um servidor à partir de uma estrutura JSON.
#3 Mãos ao código
Para essa etapa, uma auto-avaliação do que está sendo desenvolvido deve sempre ser feita, tanto pra ir validando a ideia, quanto avaliando se seu código é um código limpo. Se você não conhece esse conceito, recomendo fortemente a leitura do livro de Robert C. Martin, Código Limpo: Habilidades Práticas do Agile Software, pois te garanto que seus ensinamentos serão valiosos para sua carreira. E é claro, se você ainda não é adepto ao uso de testes unitários, essa é uma boa hora para começar a estudar sobre o assunto.
Não tinha a intenção de te oferecer um handbook com este artigo, mas apenas te mostrar um pouco o que Eu tenho feito que tem dado resultado no meu dia-a-dia.
Um forte abraço!
Comentários
Postar um comentário