APRENDER. PRATICAR. EVOLUIR.Preparar uma alteração que se consegue rever
Um serviço fictício de valorização precisa de uma regra de arredondamento. O pedido também desloca centenas de linhas e altera a configuração que ativa a regra. Antes de discutir aprovação, separa as perguntas: o movimento preserva comportamento, a regra cumpre o requisito e a ativação encontra código disponível? Uma divisão útil segue estas decisões. Cortar o diff de cem em cem linhas pode deixar cada parte incompreensível. Mantém os testes relacionados com o comportamento que demonstram; uma alteração com menos linhas, mas sem o seu contraexemplo, pode ser mais difícil de avaliar. Prepara uma descrição que indique o resultado esperado e o caso que falhava anteriormente. Se a regra exige arredondamento por linha, um total coincidente não basta. O revisor deve conseguir relacionar requisito, alteração e resultado sem depender de uma conversa privada com o autor.
Analisar estados intermédios
No exercício local, A acrescenta uma função, B passa a chamá-la e C ativa esse caminho. A ordem A, B, C respeita as dependências declaradas. B antes de A deixa uma chamada sem função; C antes de B ativa um caminho inexistente. O modelo assume explicitamente que os restantes requisitos estão satisfeitos. Não compila aplicações nem descobre dependências escondidas. Na prática, pede à equipa que descreva o estado depois de cada integração, incluindo canais de configuração que podem avançar mais depressa do que o código. Dois revisores podem discutir interface e consumidor ao mesmo tempo se partilharem contexto. Essa simultaneidade não remove a ordem necessária de integração. Uma proposta de reversão também merece análise própria: desfazer A enquanto B permanece pode recriar a chamada inválida. O resultado útil é uma sequência com pré-requisitos observáveis, não apenas três cartões movidos para concluído.
Fechar lacunas, não apenas comentários
Uma resposta “feito” não identifica o que foi corrigido. Para um relatório que omitia a última linha, pede a alteração e um exemplo que distinga o defeito da correção. Se o teste falhou duas vezes e passou à terceira sem alterações, regista a inconsistência; o terceiro resultado não explica os anteriores. Uma investigação pode encontrar defeito no produto, no ambiente ou no teste. Enquanto isso, a conclusão deve explicitar a cobertura incerta. Quando o revisor conhece o fluxo funcional, mas não consegue avaliar uma implementação criptográfica, mantém o âmbito útil e encaminha a especialidade em falta. A pressão comercial não converte familiaridade com o produto em competência para todas as áreas. Se uma explicação importante só existe no chat da revisão, torna-a acessível junto do código ou da documentação apropriada para o próximo leitor.
Prática local e passagem internacional
Copia o código completo abaixo para technical-review.py e executa python3 technical-review.py. Não requer pacotes externos. As doze verificações usam dados inventados: seis sequências, uma fila, três contas de esforço e duas consultas a campos declarados. Prevê o resultado antes de executar. A fila recebe seis pedidos e conclui quatro por dia; ao fim de cinco dias conserva dez. Esta conta não mede produtividade individual nem duração real das revisões. Experimenta alterar uma dependência e explica a falha antes de mudar a asserção. Depois escreve uma passagem em inglês para o próximo turno: versão analisada, comportamento coberto, alteração posterior, lacuna, responsável e próximo ponto de contacto. Compara “approved” com “calculation reviewed at R7; concurrency pending”. A segunda formulação permite continuar trabalho sem inventar conclusão. A passagem humana e a revisão de um repositório real ainda não foram executadas neste material.
"""Original teaching fixtures. No repository, identity, network or approval is inspected."""
import hashlib
import json
from fractions import Fraction
from pathlib import Path
import platform
checks = []
def check(name, actual, expected):
assert actual == expected, (name, actual, expected)
checks.append(dict(name=name, actual=actual, expected=expected, passed=True))
def sequence_ok(order, dependencies):
# Closed fixture: every declared step must appear once, no unknown steps.
if len(order) != len(dependencies) or set(order) != set(dependencies):
return False
done = set()
for step in order:
if not set(dependencies[step]).issubset(done):
return False
done.add(step)
return True
steps = {'A': [], 'B': ['A'], 'C': ['B']}
check('declared_sequence_valid', sequence_ok(['A', 'B', 'C'], steps), True)
check('caller_before_function', sequence_ok(['B', 'A', 'C'], steps), False)
check('activation_before_caller', sequence_ok(['A', 'C', 'B'], steps), False)
check('missing_step_rejected', sequence_ok(['A', 'B'], steps), False)
check('duplicate_step_rejected', sequence_ok(['A', 'A', 'C'], steps), False)
check('unknown_step_rejected', sequence_ok(['A', 'B', 'D'], steps), False)
backlog = 0
balances = []
for day in range(5):
backlog = max(0, backlog + 6 - 4)
balances.append(backlog)
check('fixed_review_queue', balances, [2, 4, 6, 8, 10])
effort = 24 + 12
check('effort_break_even_weeks', str(Fraction(effort, 5)), '36/5')
check('effort_sensitivity_weeks', [str(Fraction(effort, x)) for x in (6, 3)], ['6', '12'])
check('reserved_capacity_weeks', str(Fraction(effort, 6)), '6')
# Declared fields alone are not observed competence or authorization.
people = [dict(name='Ana', available=False, areas=['module', 'access']),
dict(name='Rui', available=True, areas=['module'])]
def declared_candidates(area):
return [p['name'] for p in people if p['available'] and area in p['areas']]
check('declared_module_candidate', declared_candidates('module'), ['Rui'])
check('declared_access_gap', declared_candidates('access'), [])
print(json.dumps(dict(groups=len(checks), checks=checks, python=platform.python_version(),
scope='Synthetic dependency, queue, effort and declared-field models. No network, actual code review, competence verification or approval.',
scriptSha256=hashlib.sha256(Path(__file__).read_bytes()).hexdigest()), ensure_ascii=False, indent=2))R4 cobria entradas válidas; R5 altera rejeição de entradas inválidas. Reutiliza o que continua aplicável e identifica explicitamente a análise em falta.
Armadilhas comuns
Dividir por contagem de linhas; separar testes relacionados; aprovar um delta não analisado; usar um teste verde para explicar falhas anteriores.
Tópicos relacionados: Integração contínua · Passagem de conhecimento
Uma revisão útil liga um requisito a uma alteração e à evidência obtida, mantendo visível o que ainda falta analisar.
Referência: Small CLs · Google Engineering Practices, SRE and DORA; Microsoft architecture decision and collaboration guidance; OWASP threat modeling; UK lead developer framework; inspected 2026-10-01