Um sistema Delphi que funciona há anos não é uma folha em branco. Ele reúne decisões, componentes, integrações e comportamentos que nem sempre estão registrados em um documento.
Ver resumo completo
Um sistema Delphi que funciona há anos não é uma folha em branco. Ele reúne decisões, componentes, integrações e comportamentos que nem sempre estão registrados em um documento. Quando pedimos à IA para melhorar uma rotina, a sugestão pode parecer elegante e ainda assim remover uma exceção importante, mudar uma assinatura usada por outro módulo ou depender de um recurso que o ambiente não oferece.
Este é o quarto capítulo da série IA na prática: do protótipo à operação responsável. Vamos transformar o contexto e as instruções anteriores em um fluxo de trabalho: compreender o ambiente, delimitar uma mudança, proteger o comportamento e revisar a evidência produzida. O objetivo não é impedir a evolução, mas torná-la examinável antes de chegar ao usuário.
Se sua rotina envolve melhorar um sistema que não pode parar, Delphi Vivo aprofunda a modernização incremental: diagnóstico de dependências, compilação reproduzível, proteção de comportamentos com testes, separação de responsabilidades e retorno seguro de uma mudança. Conheça a proposta e leia a degustação gratuita para avaliar como organizar esse percurso sem começar por uma reescrita. Para descrever exatamente o que a IA pode alterar e como verificar a entrega, SDD em Delphi complementa a leitura com requisitos, contratos e critérios de aceite.
Um sistema Delphi em produção raramente é apenas um conjunto de arquivos-fonte. Ele costuma concentrar regras de negócio acumuladas, integrações pouco documentadas, decisões tomadas sob restrições que já não existem e rotinas que funcionam porque foram ajustadas ao longo de muitos anos.
Ver resumo completo
Um sistema Delphi em produção raramente é apenas um conjunto de arquivos-fonte. Ele costuma concentrar regras de negócio acumuladas, integrações pouco documentadas, decisões tomadas sob restrições que já não existem e rotinas que funcionam porque foram ajustadas ao longo de muitos anos. Essa realidade pode gerar duas reações igualmente arriscadas: não mexer em nada ou decidir reescrever tudo.
A primeira conserva problemas conhecidos e reduz, aos poucos, a capacidade de adaptação. A segunda troca riscos visíveis por riscos novos: funcionalidades esquecidas, diferenças de comportamento, longos períodos sem entrega relevante e uma convivência difícil entre o sistema antigo e o substituto em construção. Entre esses extremos há uma disciplina de engenharia: modernizar progressivamente, em mudanças pequenas, verificáveis e reversíveis.
Modernizar não significa aplicar tecnologias recentes a qualquer custo. Significa aumentar a capacidade de entender, alterar, testar, entregar e operar o software com menos incerteza. Em um sistema Delphi, isso pode envolver desde tornar a compilação repetível até reduzir o acoplamento entre formulários VCL, regras de negócio e acesso a dados. O ponto de partida não é uma lista de ferramentas; é um diagnóstico honesto do risco.
Conheça o livro e leia uma degustação: acesse a página oficial de Delphi Vivo.
Quem mantém um projeto Delphi grande conhece a pergunta: se eu alterar ou remover esta unit, quais partes da aplicação serão afetadas? Encontrar as referências diretas na cláusula uses ajuda, mas nem sempre mostra o caminho completo.
Ver resumo completo
Quem mantém um projeto Delphi grande conhece a pergunta: se eu alterar ou remover esta unit, quais partes da aplicação serão afetadas? Encontrar as referências diretas na cláusula uses ajuda, mas nem sempre mostra o caminho completo. Uma unit pode ser usada por outra, que é usada por uma terceira, até chegar ao arquivo principal do projeto.
Foi para tornar essa investigação mais prática que criei o Delphi Unit Backtrace. A primeira versão pública já está disponível no GitHub, com executáveis para Win32 e Win64. A ferramenta recebe um arquivo .dproj e o nome da unit, descobre o fonte correspondente e percorre as dependências no sentido inverso: da unit escolhida até seus consumidores e, quando existe essa ligação, até o DPR.
Você já ouviu falar em TDD (Test-Driven Development), mas ainda tem dúvidas sobre como essa abordagem realmente funciona?
Ver resumo completo
Você já ouviu falar em TDD (Test-Driven Development), mas ainda tem dúvidas sobre como essa abordagem realmente funciona?
Neste minicurso, Landerson Gomes apresenta os fundamentos do Desenvolvimento Guiado por Testes e explica a mudança de pensamento por trás dessa prática. Mais do que simplesmente criar testes para um código pronto, o TDD coloca os testes como parte do próprio processo de construção do software. Um conteúdo direto para quem deseja compreender melhor essa abordagem e começar a aplicá-la de forma consciente no desenvolvimento de software.
Quem trabalha há bastante tempo com Delphi provavelmente já encontrou units com cláusulas uses enormes, formadas por dezenas de dependências que ninguém sabe ao certo se ainda são necessárias. Algumas foram adicionadas automaticamente pela IDE, outras eram utilizadas por trechos de código que já não existem e muitas permanecem na seção interface mesmo sendo necessárias apenas na implementação.
Ver resumo completo
Quem trabalha há bastante tempo com Delphi provavelmente já encontrou units com cláusulas uses enormes, formadas por dezenas de dependências que ninguém sabe ao certo se ainda são necessárias. Algumas foram adicionadas automaticamente pela IDE, outras eram utilizadas por trechos de código que já não existem e muitas permanecem na seção interface mesmo sendo necessárias apenas na implementação. Embora pareça um problema meramente estético, esse acúmulo pode aumentar o acoplamento entre as units, dificultar a manutenção e ampliar desnecessariamente o impacto de cada alteração realizada no projeto.
Remover essas dependências manualmente nem sempre é simples. Excluir uma unit da cláusula uses, compilar o projeto e repetir o processo até encontrar todas as dependências desnecessárias pode consumir muito tempo, principalmente em sistemas antigos ou de grande porte. Além disso, algumas units possuem efeitos colaterais durante a inicialização da aplicação e não podem ser removidas apenas porque seus símbolos não aparecem diretamente no código. É nesse cenário que o Atropos se apresenta como uma ferramenta interessante para a comunidade Delphi.
O Atropos é um projeto open source (github.com/ViniAbreu/Atropos) criado para analisar e otimizar automaticamente as cláusulas uses de projetos Delphi. A ferramenta identifica units aparentemente não utilizadas, verifica quais dependências podem ser transferidas da seção interface para a seção implementation e modifica os arquivos de código. Depois disso, ela tenta compilar o projeto para confirmar que as alterações continuam válidas. Se a compilação falhar, os arquivos modificados são restaurados automaticamente.
Há sistemas Delphi que sustentam empresas inteiras há muitos anos, eles faturam, controlam estoque, emitem documentos fiscais, conversam com bancos, integram setores e preservam regras que foram construídas depois de incidentes, mudanças legais, negociações e necessidades que já não cabem em uma documentação simples.
Ver resumo completo
Há sistemas Delphi que sustentam empresas inteiras há muitos anos, eles faturam, controlam estoque, emitem documentos fiscais, conversam com bancos, integram setores e preservam regras que foram construídas depois de incidentes, mudanças legais, negociações e necessidades que já não cabem em uma documentação simples.
Esses sistemas continuam importantes. O problema é que, com o tempo, cada mudança começa a custar mais, a versão do Delphi fica para trás. Componentes deixam de receber atualizações. O build depende de uma máquina específica. Regras de negócio aparecem em Forms, DataModules, SQL, triggers e integrações. Testes automatizados são poucos ou inexistentes. A equipe sabe que precisa avançar, mas não consegue demonstrar que a próxima alteração preservará aquilo que mantém a empresa funcionando.
Foi a partir dessa realidade que escrevi Delphi Vivo: Como modernizar sistemas existentes sem reescrever tudo.
O livro já está disponível em edição impressa pela UICLAP e em versão digital para Kindle na Amazon.
Desde a versão 2.14, o RadIA passou por uma evolução importante. O foco deixou de estar apenas na expansão do catálogo de ferramentas e avançou para algo mais ambicioso: permitir que o desenvolvedor Delphi compreenda, altere, valide, execute e investigue uma aplicação dentro de um fluxo integrado e verificável.
Ver resumo completo
Desde a versão 2.14, o RadIA passou por uma evolução importante. O foco deixou de estar apenas na expansão do catálogo de ferramentas e avançou para algo mais ambicioso: permitir que o desenvolvedor Delphi compreenda, altere, valide, execute e investigue uma aplicação dentro de um fluxo integrado e verificável.
As versões 2.15.0 e 2.15.1 ampliaram a integração com o código Delphi, fortaleceram a automação de aplicações VCL em execução, melhoraram o processo de diagnóstico e adicionaram novas proteções às interfaces baseadas em WebView2.
Neste artigo, veremos o que mudou e como essas melhorias afetam o uso diário do RadIA.
Se você tem acompanhado a evolução do Rad IA — nosso plugin open-source de assistência de IA integrado nativamente à IDE do Delphi (Alexandria, Athens e Florence) —, sabe que nosso compromisso vai muito além de "envelopar APIs de IA". Buscamos trazer produtividade real para o desenvolvedor Object Pascal sob as regras mais rígidas de Clean Code, SOLID e segurança…
Ver resumo completo
Se você tem acompanhado a evolução do Rad IA — nosso plugin open-source de assistência de IA integrado nativamente à IDE do Delphi (Alexandria, Athens e Florence) —, sabe que nosso compromisso vai muito além de "envelopar APIs de IA". Buscamos trazer produtividade real para o desenvolvedor Object Pascal sob as regras mais rígidas de Clean Code, SOLID e segurança em runtime.
Na recém-lançada versão v0.0.26, demos um salto gigantesco. Redesenhamos a experiência visual do chat para torná-la mais orgânica e premium, e realizamos uma profunda reforma estrutural de engenharia de software na base de código do plugin.
Neste artigo, convido você a dar uma olhada nos bastidores do que mudou no Rad IA, nas decisões de arquitetura que tomamos e em como blindamos o plugin contra travamentos e concorrência no Delphi.
O Rad IA, assistente de inteligência artificial integrado diretamente à IDE do Delphi, passou por uma série de atualizações profundas desde a versão v0.0.21. O foco do desenvolvimento nesse período foi elevar a robustez da integração com o ecossistema Embarcadero, introduzir ferramentas inteligentes de auditoria e melhorar significativamente a experiência visual e a confiabilidade das refatorações direto no…
Ver resumo completo
O Rad IA, assistente de inteligência artificial integrado diretamente à IDE do Delphi, passou por uma série de atualizações profundas desde a versão v0.0.21. O foco do desenvolvimento nesse período foi elevar a robustez da integração com o ecossistema Embarcadero, introduzir ferramentas inteligentes de auditoria e melhorar significativamente a experiência visual e a confiabilidade das refatorações direto no editor de código.
Abaixo, detalhamos as principais novidades, recursos e correções implementadas nas últimas versões do plugin.
Muitos desenvolvedores Delphi veem os testes unitários como uma perda de tempo ou um fardo adicional. No entanto, o Código Limpo nos ensina que testes e código de produção são igualmente importantes.
Ver resumo completo
Muitos desenvolvedores Delphi veem os testes unitários como uma perda de tempo ou um fardo adicional. No entanto, o Código Limpo nos ensina que testes e código de produção são igualmente importantes. Um código sem testes não é apenas perigoso; ele é, por definição, "sujo", pois não oferece a confiança necessária para futuras refatorações.
No Delphi 13, utilizamos o DUnitX como o framework padrão para garantir que cada pequena engrenagem do nosso sistema funcione exatamente como planejado.
Refatoração é o processo de alterar um sistema de software de modo que não mude o comportamento externo do código, mas melhore sua estrutura interna. No contexto do Código Limpo, a refatoração não é um evento isolado ou uma "parada para manutenção", mas um hábito contínuo conhecido como a Regra do Escoteiro: "Deixe o código sempre um pouco…
Ver resumo completo
Refatoração é o processo de alterar um sistema de software de modo que não mude o comportamento externo do código, mas melhore sua estrutura interna. No contexto do Código Limpo, a refatoração não é um evento isolado ou uma "parada para manutenção", mas um hábito contínuo conhecido como a Regra do Escoteiro: "Deixe o código sempre um pouco mais limpo do que você o encontrou".
No Delphi 13 (Athens), refatorar código legado é essencial para reduzir a dívida técnica e permitir que o sistema continue evoluindo sem colapsar sob sua própria complexidade.
No desenvolvimento de software, as funções são a primeira linha de organização. No Delphi, onde a sintaxe procedure e function define o ritmo do sistema, a qualidade desses blocos determina se o projeto será sustentável ou se tornará um "legado intocável".
Ver resumo completo
No desenvolvimento de software, as funções são a primeira linha de organização. No Delphi, onde a sintaxe procedure e function define o ritmo do sistema, a qualidade desses blocos determina se o projeto será sustentável ou se tornará um "legado intocável".
O capítulo de funções do Clean Code pode ser resumido em uma frase de Robert C. Martin: "A primeira regra das funções é que elas devem ser pequenas. A segunda regra é que elas devem ser ainda menores."
No ecossistema Delphi, herdamos décadas de evolução. Muitas vezes, ainda encontramos códigos com variáveis globais nomeadas como v_1, componentes com nomes padrão (Button1, Edit2) ou métodos cujos nomes não explicam o que fazem.
Ver resumo completo
No ecossistema Delphi, herdamos décadas de evolução. Muitas vezes, ainda encontramos códigos com variáveis globais nomeadas como v_1, componentes com nomes padrão (Button1, Edit2) ou métodos cujos nomes não explicam o que fazem. No Delphi 13, temos recursos modernos para tornar o código uma leitura tão clara quanto um livro bem escrito.
O primeiro princípio do Código Limpo é simples: O nome de uma variável, função ou classe deve dizer por que ela existe, o que ela faz e como é usada.
