Programação para engenheiros civis: automações que economizam horas + boas práticas explicadas simples

Dados duros:

• Tarefas repetitivas num escritório de engenharia típico: 40-60% do tempo da equipe.
• Salário premium de engenheiros com habilidades de programação: +30-70% conforme a região.
• Redução de erros humanos automatizando: 60-90% para tarefas típicas.

E acima de tudo: te muda o chip. Você começa a ver problemas como sistemas — com inputs, processos e outputs. Essa mentalidade, além do código, te faz melhor engenheiro.

O que NÃO significa programar como engenheiro civil:

• Não significa virar desenvolvedor de software.
• Não significa largar a engenharia.
• Não significa aprender 20 linguagens.
• Significa usar programação como mais uma ferramenta, como AutoCAD ou Excel — igual de natural.

Ordenadas da mais fácil à mais avançada. Todas viáveis com Python ou Dynamo + IA.

1. Renomeação massiva de famílias / camadas / vistas (Revit / AutoCAD). Antes: 2-4 h. Depois: 30 s. Economia: ~99%.
2. Exportar tabelas de quantitativos para Excel com formato corporativo. Antes: 1-2 h. Depois: 10 s. Economia: ~99%.
3. Colocar cotas ou tags automáticas seguindo regras. Antes: 3-5 h/prancha. Depois: 5 min. Economia: ~95%.
4. Gerar perfis longitudinais a cada X metros no Civil 3D. Antes: 3 h. Depois: 15 min. Economia: ~92%.
5. Quantitativo automático de movimento de terra. Antes: 2 h. Depois: 30 s. Economia: ~99%.
6. Checagem de padrões BIM (naming, categorias, parâmetros). Antes: 2 h. Depois: 30 s + relatório. Economia: ~99%.
7. Geração massiva de pranchas com vistas + tabelas + selo. Antes: 4-8 h. Depois: 2 min. Economia: ~98%.
8. Detecção de interferências entre disciplinas + relatório. Antes: 3 h. Depois: 15 min. Economia: ~92%.
9. Modelagem paramétrica de taludes a partir de polilinha + regras. Antes: 4 h. Depois: 30 min. Economia: ~87%.
10. Exportar pontos topográficos para CSV com classificação. Antes: 1 h. Depois: 10 s. Economia: ~99%.

"Arquitetura de software" soa como algo enorme. Para você, engenheiro que automatiza, é MUITÍSSIMO mais simples. Se resume em:

Regra única: organize seu código em camadas que fazem uma coisa só cada uma.

Tradução para pastas do seu projeto:

MeuPlugin/
  UI/              (formulários, janelas, botões)
  Logic/           (suas regras: "vigas <3m não contam")
  Revit/           (tudo que toca a API — SetParameter, GetElement)
  Program.cs       (ponto de entrada, monta as 3 camadas)

Por que isso importa? Porque no dia que a Autodesk mudar a API (e sempre muda), você só toca a pasta Revit/. Sua lógica e UI ficam intactas. E se amanhã quiser trocar de C# para outra linguagem, sua lógica é reaproveitável.

Analogia civil: é como projetar um edifício com estrutura, arquitetura e instalações separadas. Se toca mudar as instalações, não redesenha a estrutura. Com código igual.

"Código limpo" são 4 hábitos concretos:

a) Nomes que dizem a verdade.

Ruim:

def calc(x, y):
    return x * y * 0.18

Bom:

def calcular_imposto(preco, quantidade):
    return preco * quantidade * TAXA_IMPOSTO

O segundo se lê. O primeiro te obriga a adivinhar o que faz.

b) Funções curtas que fazem UMA coisa.

Ruim — uma função que faz 5 coisas: ler arquivo, filtrar dados, calcular, gerar relatório, enviar email.

Bom — 5 funções:

def ler_dados(arquivo): ...
def filtrar_por_categoria(dados, cat): ...
def calcular_totais(dados): ...
def gerar_relatorio(totais): ...
def enviar_email(relatorio, destinatario): ...

c) Constantes com nome, não números mágicos.

Ruim: if idade > 18: (por que 18? o que significa?).

Bom:

IDADE_MAIORIDADE = 18
if idade > IDADE_MAIORIDADE:
    ...

d) Comentários onde importam, não no óbvio.

Ruim:

# Somar 1
x = x + 1

Bom:

# Vigas <3m não contam por norma interna DGA-2023
if comprimento_viga >= COMPRIMENTO_MINIMO_VIGA:
    contador += 1

O problema: cada script começa do zero. Você copia e cola as mesmas 30 linhas de sempre para conectar com Excel, para ler um arquivo, para montar um relatório.

A solução: quando escrever a mesma coisa duas vezes, é uma função. Na terceira, é um componente.

Exemplo real: todos seus scripts terminam exportando para Excel com o mesmo selo corporativo. Extraia esse código para uma função que possa importar:

# arquivo: helpers/excel_corporativo.py
def exportar_com_selo(dados, caminho):
    """Exporta uma lista de dados para um Excel com o
    selo e estilos corporativos da empresa."""
    ...

Agora em qualquer script: from helpers.excel_corporativo import exportar_com_selo. Uma linha, não 30.

Efeito composto: com 6-8 componentes bem feitos, cada novo script leva 1/3 do tempo. E todos compartilham o mesmo padrão corporativo automaticamente.

Regra de ouro: sempre que copiar e colar código, pare e pergunte: "isso merece ser uma função?". A maioria das vezes, sim.

Se só aprender uma ferramenta deste guia, que seja Git. É o backup infinito do seu código.

Setup fácil (sem terminal):

1. Instale GitHub Desktop (interface visual, gratuito).
2. Crie uma conta em GitHub.com (grátis).
3. Crie um repositório privado para cada projeto de automação.
4. Sempre que algo funciona: botão "Commit" → botão "Push". Pronto. Está salvo na nuvem.

O que você ganha:

• Se amanhã quebrar algo, volta para a versão de ontem com um botão.
• Trabalha de outra máquina e tudo está sincronizado.
• Se vai compartilhar com um colega, é uma URL.
• Nunca mais "perdi o arquivo".

Custo total de aprender bem: 20 minutos + um vídeo do YouTube. Valor: infinito.

Você não precisa escrever testes automatizados como um dev sênior. Precisa de um mínimo de disciplina para não quebrar coisas.

O protocolo mínimo antes de dar como bom um script:

1. Teste com dados reduzidos — não com o modelo de produção. Um arquivo pequeno.
2. Teste com dados limite — 0 elementos, 1 elemento, muitos elementos.
3. Teste com dados "ruins" — um dado faltando, um valor negativo, um texto onde ia número.
4. Verifique manualmente o output nas primeiras 2-3 vezes. Depois começa a confiar.
5. Tenha um "modo dry-run" — um modo que só lista o que FARIA sem fazer. Perfeito para revisões antes de rodar em produção.

Exemplo de dry-run:

def renomear_familias(dry_run=False):
    for familia in obter_familias():
        novo_nome = calcular_novo(familia)
        if dry_run:
            print(f"[DRY] {familia.nome} -> {novo_nome}")
        else:
            familia.rename(novo_nome)

Roda com dry_run=True primeiro, revisa a saída, e só se estiver tudo bem roda de verdade.

Siga esta ordem:

Etapa 1 — Script pessoal (semanas): Um arquivo. Só você usa. Vale. Não precisa mais.

Etapa 2 — Ferramenta compartilhada (meses): Já usam 2-3 pessoas. Agora sim: coloca no Git, organiza em pastas, documenta as três coisas críticas (como instalar, como usar, quando NÃO usar).

Etapa 3 — Produto da equipe (semestre): Já usam 10+ pessoas. Toca: instalador, versão, canal de suporte (mesmo que WhatsApp), regras de contribuição.

Etapa 4 — Ferramenta do setor (ano ou mais): Já é distribuída a clientes externos. Precisa: assinatura digital, updates automáticos, testes, licenciamento. E é aí que uma mentoria ou parceiro técnico economiza semanas de erros.

Regra chave: não pule de etapa antes da hora. Um script que só você usa não precisa de instalador. Um produto que 20 pessoas usam não sobrevive sem Git. Ajuste a disciplina ao momento.