A beleza da programação de computadores está em poder criar qualquer coisa que a imaginação humana seja capaz de pensar. É loucura pensar que, nesse momento, existe um código sendo executado em foguetes, carros, aplicativos de celular, geladeiras, bicicletas e milhões de outros aparelhos.
Existem milhares de possibilidades para se escrever o mesmo software. Na minha opinião, escrever código é muito semelhante à escrever um livro, no sentido de que uma mesma mensagem pode ser transmitida de infinitas formas. Por exemplo, posso escrever sobre consumo de carboidratos em corridas de longas distâncias de várias maneiras, assim como posso criar um botão em um aplicativo da forma como eu quiser. Eu escolho como transmitir a mensagem.
Acredito que um livro não se torna best seller apenas pelo conteúdo que foi escrito, o conteúdo final é apenas o resultado do processo. O trabalho difícil vem muito antes. O primeiro desafio é ter a ideia, sem a ideia nada acontece. E depois disso, é trabalho duro, é necessário muita imaginação, mão na massa, e principalmente, a organização. Como pegar um milhão de insights e separá-los em capítulos? Como organizar a rotina, como será a distribuição do trabalho? O quão longe queremos ir? Vão ser 200, 300 ou 500 páginas?
Para mim, por isso que, desenvolver software é semelhante a escrita de um livro. Eu tenho a liberdade de construir o que quiser, como quiser, depende da minha capacidade técnica, e de como eu vou escrever e organizar as minhas ideias. Eu posso escrever algo complexo de tal maneira que fique simples, e que todos vão entender. Por outro lado, eu também posso escrever algo que deveria ser simples, mas que fica complexo, e ninguém consegue entender.
Fazer software vai muito além de só escrever código. Se o seu trabalho é só escrever código, já aviso que o seu trabalho não existirá no futuro, a IA já faz isso por nós. Mas isso não é assunto desse post. Para mim, desenvolver software é resolver um problema do mundo real. Quero escrever aqui o que me ajuda na hora de desenvolver um produto de qualidade.
1. Entenda detalhadamente o problema que está sendo resolvido
Uma vez definido o que será feito, é muito importante absorver o máximo de detalhes da demanda, e aqui estou falando de regras de negócio e UX, ainda não é hora de pensar se vou usar a variável X ou classe Y. No entanto, é importante ressaltar que, dependendo do tamanho do problema, é necessário pensar de forma macro, sem entrar muito nos detalhes internos do código. Aqui é uma etapa que precisa de muito alinhamento com o time de design/produto, pois é onde pode surgir impedimentos técnicos.
2. Anote tudo
Eu gosto de usar checkboxes, pois durante o desenvolvimento basta ir dando check nos pontos que já foram feitos. Eu gosto de anotar tanto a parte técnica quanto a parte negocial. Anoto coisas como: regras de negócio que não foram discutidas, detalhes técnicos que ainda não possuem solução, novas definições, etc. É sempre bom anotar a mais do que de menos.
3. Rabisque soluções
É hora de usar todo o conhecimento técnico e desenhar soluções para o problema proposto. Aqui é onde usamos aquilo que aprendemos na faculdade, nos livros e nos cursos da vida. Quanto mais tempo de experiência, melhor será o desenho da solução. É importante pensar sempre a longo prazo e no máximo de cenários possíveis, alguns são:
- Que tipo de modificações poderá ter no futuro? Hoje esse botão é azul, amanhã pode ser amarelo? (esse exemplo foi muito simples)
- A sua solução escala para 1.000.000 de usuários? Se amanhã tivermos um pico de usuários, o servidor, banco, etc., vão aguentar esse volume?
- Quais pontos poderão sofrer alterações no futuro? como será uma 2º versão dessa funcionalidade?
- Quais outras partes vão ser impactadas? O time de design/produto já tinha pensado nesse impacto? caso não tenha, é necessário um novo alinhamento.
- O prazo está apertado, devo aproveitar a classe Y ou criar a classe X?
Decisões tomadas aqui são muito relevantes, pois pode levar ao sucesso, como também pode levar a ruína.
4. Hora de codar
Uma vez aprovado o desenho da solução, é hora de codar, dia e noite. É nessa etapa que criamos mais casca, melhoramos o nosso nível como engenheiro, e aprendemos a trabalhar sob pressão. A pressão faz bem, precisamos disso para crescer.
E aqui não tem segredo, é codar tudo o que foi planejado. Vão aparecer impedimentos, e as suas anotações nos tópicos 2 e 3 vão te ajudar.
Em alguns casos o ciclo deverá ser reiniciado, e se isso acontece com muita frequência, provavelmente a etapa 1 não está boa o suficiente.
5. Crie testes automatizados e teste manualmente
Tem gente que gosta de criar testes antes, e tem gente que gosta de criar testes depois. Para mim, o importante é ter testes, e principalmente garantir que o que já existe não foi quebrado. Essa etapa é tão importante quanto as outras, é o teste automatizado que garantirá a estabilidade do produto a longo prazo. Sem teste estaremos correndo um risco muito alto.
O teste manual é tão importante quanto os testes automatizados, pois dificilmente será possível cobrir todos os cenários com testes automatizados. É aí que entra o teste manual.
6. Produção e Observabilidade
Uma vez rodando em produção, precisamos garantir que tudo está dentro do esperado. Nessa etapa são necessárias métricas que mostrem que a aplicação está rodando sem erros, e que a performance está dentro do previsto.
Escrevi esse post para pessoas que têm pressa, é claro que o processo de desenvolvimento de software vai muito além disso, algumas não foram descritas aqui, como por exemplo, code review, pair programming, handoff's, plannings e etc. Essas e outras são tão importantes quanto as citadas acima.
Quando todos os envolvidos conseguem entregar essas etapas sem entraves, significa que o processo está indo muito bem. Na prática, sabemos que não acontece perfeitamente assim. Pois no meio disso tudo, ocorrem problemas em produção, clientes reportam bugs, novas demandas surgem no meio, e assim por diante.
É por isso que, para construir um produto bem feito é necessário organização.