Como se constrói software

Sabes escrever um programa (Parte I) e sabes do que é feita uma aplicação (Parte II). Falta a parte mais humana: como é que uma equipa transforma uma ideia numa coisa real, que outras pessoas usam todos os dias.

Antes de escrever código, percebe o problema

É tentador abrir logo o editor e começar a programar. Mas o software mais bem feito começa longe do código: a perceber quem vai usar aquilo e que problema real se está a resolver. Saltar este passo é a razão número um por que se constroem coisas que ninguém quer.

Problema não é o mesmo que solução

Repara nesta diferença, porque é subtil e importantíssima:

• Um problema é uma dificuldade que uma pessoa tem: "perco sempre a conta a quantos módulos já fiz."
• Uma solução é uma forma concreta de a resolver: "fazer uma barra de progresso no topo."

Quem se apaixona cedo por uma solução esquece-se de confirmar o problema — e arrisca-se a construir muito bem uma coisa que não servia. A regra de ouro: primeiro o problema, só depois a solução. Muitas vezes, quando percebes bem o problema, aparecem soluções melhores do que a primeira que te veio à cabeça.

Perceber o utilizador

O utilizador é a pessoa para quem estás a construir. Pode não ser nada como tu. Antes de decidir o que fazer, vale a pena perguntar: quem é? o que está a tentar fazer? o que o irrita hoje? A estas respostas — a lista do que a app tem mesmo de fazer — chamamos requisitos. Um bom requisito descreve uma necessidade, não um ecrã nem um botão.

Contar o que se quer, do lado de quem usa

Percebido o problema, como é que uma equipa combina o que vai construir sem se perder em documentos gigantes? Com uma ferramenta simples e poderosa: a história de utilizador — uma frase curta que descreve uma funcionalidade na perspetiva de quem a vai usar.

A frase mágica

Quase todas as histórias de utilizador cabem neste molde:

Parece simples de mais, mas cada peça tem um trabalho. O "enquanto" lembra para quem é. O "quero" diz o quê. E o "para" — a parte que toda a gente esquece — diz porquê. Uma história sem o "para" é uma tarefa sem sentido; com ele, a equipa percebe o valor e muitas vezes descobre uma forma melhor de o entregar.

Repara que em lado nenhum se fala de código, de botões ou de cores. Uma história descreve uma necessidade e deixa a equipa livre para encontrar a melhor solução. Constrói algumas:

Como saber que está "feito"? Critérios de aceitação

Uma história ainda deixa margem para dúvidas ("mostrar o progresso... como?"). Por isso junta-se-lhe uma pequena lista de critérios de aceitação: condições concretas que têm de ser verdade para se dizer que a história está pronta. São eles que evitam discussões no fim ("mas eu pensei que...") e que, mais tarde, se transformam em testes — o tema do Módulo 5.

Muitas mãos no mesmo código, sem caos

Já alguma vez guardaste "trabalho_final", "trabalho_final_2", "trabalho_final_MESMO"? Multiplica isso por cinco pessoas a mexer nos mesmos ficheiros ao mesmo tempo e tens o caos. A ferramenta que resolve isto — e que sustenta praticamente todo o software do mundo — chama-se git.

Uma máquina do tempo para o código

O git guarda o teu projeto como uma sequência de fotografias. A cada fotografia chama-se commit: um instante congelado de todos os ficheiros, com uma mensagem a dizer o que mudou ("adiciona o botão de progresso"). A lista de todos os commits é o histórico — e podes viajar nele.

Isto dá-te dois superpoderes:

• Voltar atrás. Partiste tudo? Regressas a um commit anterior, de quando funcionava. Nada se perde: o histórico fica lá inteiro.
• Trabalhar em paralelo. Cada pessoa faz os seus commits e depois juntam-se, com o git a ajudar a combinar as mudanças sem se atropelarem.

Curiosidade: este curso vive num repositório git. Cada melhoria que lhe é feita é um commit — exatamente como os que vais criar aqui:

Partir o grande em pedaços que se entregam

Um projeto inteiro assusta: "fazer uma app" é grande de mais para agarrar. O segredo das equipas que entregam é não atacar tudo de uma vez — partem o trabalho em pedaços pequenos e completam-nos em ciclos curtos. A esta forma de trabalhar chama-se, muitas vezes, ágil.

O sprint

Um sprint é um período curto — tipicamente uma a duas semanas — com um objetivo claro: "no fim disto, o progresso já se guarda". Escolhem-se poucas tarefas, fazem-se até ao fim, e mostra-se algo que funciona. Depois começa outro sprint. Entregar pouco mas a sério, muitas vezes, é quase sempre melhor do que prometer tudo para um grande fim distante que nunca chega.

O quadro: onde o trabalho anda

Para ver o trabalho a andar, as equipas usam um quadro (muitas vezes chamado kanban). É simples: colunas por onde os cartões (as tarefas) passam, da esquerda para a direita.

• A fazer — o que está planeado para o sprint (o backlog do sprint).
• A fazer agora — aquilo em que alguém está a trabalhar neste momento.
• Feito — o que já está pronto (e cumpre os critérios de aceitação do Módulo 2!).

Só de olhar para o quadro, toda a gente vê como vai o sprint. Faz este andar:

Como sabemos que funciona

Escreveste código. Funciona mesmo? "Parece que sim" não chega — sobretudo quando, amanhã, uma mudança pequena pode partir uma coisa que já funcionava. As equipas provam que o software faz o que devia com testes.

O que é um teste

Um teste é só um pequeno programa que verifica outro programa. Dá-lhe uma entrada conhecida e confirma se a saída é a esperada. Lembras-te dos critérios de aceitação do Módulo 2? Um teste é um critério desses transformado em código: "para a idade 13, a função tem de dizer verdadeiro".

Quando algo se porta mal — dá um resultado errado, ou rebenta — a esse defeito chama-se bug. O grande valor dos testes é duplo: apanham o bug antes do utilizador, e — depois de arranjado — impedem-no de voltar, porque o teste fica lá a vigiar para sempre.

Vê um caso clássico. Esta função devia reconhecer um adolescente (dos 13 aos 19), mas tem um bug. Corre os testes, descobre qual falha, e arranja-o:

"Estar pronto"

Isto ajuda a responder a uma pergunta traiçoeira: quando é que uma tarefa está mesmo feita? Uma equipa combina uma definição de pronto — por exemplo: "o código funciona, tem testes que passam, e alguém o reviu". Sem isto, "está quase" arrasta-se para sempre.

Pôr o software nas mãos das pessoas

O código mais bonito do mundo não vale nada enquanto vive só no teu computador. O último passo — e o que fecha o círculo — é entregá-lo a quem o vai usar. E, tal como tudo nesta Parte, tem um método para não correr mal.

Versões e releases

À medida que o software cresce, dá-se um nome a cada entrega, para toda a gente saber do que se fala: são as versões (v1.0, v1.1, v2.0…). A um conjunto de mudanças prontas, empacotado e anunciado, chama-se uma release. "Saiu a versão 2.0" quer dizer que uma nova release foi entregue.

Deploy (publicar)

Ao ato de levar o software do teu computador para o sítio onde as pessoas lhe acedem chama-se fazer deploy — publicar. Idealmente é automático e repetível: carrega-se num botão (ou faz-se um git push) e o mesmo processo corre sempre da mesma maneira, sem passos manuais para esquecer. É exatamente assim que este curso é publicado: um push para o git dispara o deploy para a nuvem.

Quando corre mal: rollback

Mesmo com testes, às vezes uma release traz um problema que só aparece com utilizadores a sério. A rede de segurança chama-se rollback: voltar depressa à versão anterior, que se sabe boa, enquanto se arranja o problema com calma. Publicar sem medo depende de saber recuar sem drama. Experimenta:

Do bit ao produto

Fechaste o arco. Começaste num bit — um interruptor ligado ou desligado — e chegaste a um produto: software pensado para pessoas, construído por uma equipa, testado e entregue ao mundo.

Pelo caminho percebeste a máquina (Parte I), a anatomia de uma aplicação (Parte II) e o processo humano que a constrói (Parte III). Já não olhas para um ecrã da mesma maneira — sabes o que está por baixo, em todas as camadas.