Como funciona o desenvolvimento web na prática
Do lado de fora, o desenvolvimento parece uma caixa negra: aprova-se o desenho, espera-se algumas semanas, aparece um site. Perceber o que acontece lá dentro ajuda a fazer as perguntas certas e a reconhecer sinais de problema cedo.
Este guia explica o funcionamento prático, para quem contrata em vez de para quem programa.
Ambientes: onde o trabalho acontece#
Um projeto sério tem pelo menos dois ambientes, e frequentemente três. Se só houver um, isso por si é um sinal.
| Ambiente | Para que serve | Quem acede |
|---|---|---|
| Local | A máquina de quem programa | A equipa |
| Testes | Versão partilhada para rever | Equipa e cliente |
| Pré-produção | Cópia igual à de produção | Equipa, antes de publicar |
| Produção | O site público | Toda a gente |
Alterações feitas diretamente em produção são a origem mais comum de avarias inesperadas. Se lhe disserem que não há ambiente de testes, pergunte porquê.
O ciclo de trabalho#
A maioria das equipas trabalha em ciclos curtos, com algo revisível no fim de cada um.
- O trabalho é dividido em tarefas pequenas, cada uma com um resultado verificável.
- Cada tarefa é desenvolvida separadamente, com controlo de versões.
- Outra pessoa revê o código antes de ser integrado, quando a equipa tem dimensão para isso.
- O resultado vai para o ambiente de testes, onde pode ser visto.
- Você revê e dá feedback concreto, com URL e captura de ecrã.
- Correções entram no ciclo seguinte, salvo se forem bloqueantes.
- A cada uma ou duas semanas há uma versão para rever, não apenas no fim.
Um projeto em que só vê o resultado no fim é um projeto de risco. Peça acesso ao ambiente de testes desde a primeira semana.
Testes antes de publicar#
O que deve estar verificado antes de qualquer publicação, independentemente da dimensão do projeto.
- Funcionalidade: cada formulário, cada percurso, cada botão que faz alguma coisa.
- Navegadores: os que os seus visitantes usam realmente, segundo a análise.
- Dispositivos: telemóveis reais, incluindo um antigo e lento.
- Desempenho: medido, não estimado, nos modelos principais.
- Acessibilidade: teclado, contraste, rótulos, estrutura de títulos.
- Conteúdo: sem texto de exemplo, sem ligações para o domínio de testes.
- Regressão: o que já funcionava continua a funcionar.
- Segurança: validação de entradas, permissões, HTTPS.
Publicação e reversão#
Publicar deve ser rotineiro e aborrecido. Quando é um acontecimento tenso, é sinal de que o processo está frágil.
| Prática | Porquê importa |
|---|---|
| Publicação automatizada | Elimina passos manuais esquecidos |
| Reversão em minutos | Transforma um erro grave num incidente pequeno |
| Cópia de segurança antes de publicar | Rede de segurança para a base de dados |
| Migrações de dados versionadas | Alterações à base de dados reproduzíveis |
| Verificação depois de publicar | Apanha o que só falha em produção |
| Publicar em momento calmo | Menos utilizadores afetados, mais atenção disponível |
| Registo do que foi publicado | Permite relacionar problemas com alterações |
Pergunte quanto tempo demora reverter. Se a resposta for «depende» ou «nunca precisámos», o plano de reversão não existe.
Perguntas frequentes
Com que frequência devo ver o progresso?
De uma a duas semanas, com algo visível no ambiente de testes. Ciclos mais longos aumentam o risco de descobrir tarde que houve um mal-entendido. Ciclos muito curtos com feedback constante também têm custo, porque interromper trabalho a meio é ineficiente. Uma cadência quinzenal funciona bem para a maioria dos projetos.
O que faço se o projeto atrasar?
Primeiro perceba a causa: conteúdo em falta, âmbito que cresceu, ou estimativa otimista. As três resolvem-se de maneiras diferentes, e a primeira é frequentemente do lado do cliente. Depois decida entre cortar âmbito ou mover a data — acrescentar pessoas a meio de um projeto atrasado costuma atrasá-lo ainda mais.
Preciso de perceber de código para gerir isto?
Não. Precisa de saber que perguntas fazer: há ambiente de testes, como se publica, quanto demora reverter, o que está testado, quem tem acesso ao código. As respostas dizem-lhe muito sobre a solidez do processo sem que precise de ler uma linha.
O que é controlo de versões e porque importa?
É o sistema — quase sempre Git — que guarda o histórico de todas as alterações ao código e permite voltar atrás. Importa por três razões: permite reverter um erro, permite várias pessoas trabalharem em paralelo, e é a prova de que o código é seu e transferível. Um projeto sem controlo de versões é um projeto sem histórico.
como funciona desenvolvimento webambiente de testescontrolo de versõespublicar siteprocesso desenvolvimentogestão projeto web
