Um bom fluxo de trabalho de programação Delphi é enxuto. Abra a pasta do projeto, peça uma alteração, leia o diff e execute o comando de build. O Arraydeck segue esse loop com ferramentas reais, então cada etapa deixa um cartão no chat que você pode expandir e inspecionar, desde a primeira pesquisa até o último código de saída. Nada fica oculto atrás de um resumo. Se uma etapa parecer errada, você interrompe o loop ali, rejeita a alteração e reformula o pedido, e os arquivos permanecem como estavam antes dessa etapa. As mesmas quatro etapas funcionam em uma unidade pequena e em um projeto com muitos formulários. Iniciantes e mantenedores experientes podem começar com uma pesquisa apenas para leitura, pois ela não altera nenhum arquivo e ainda mostra como o projeto está estruturado.
Escolha a pasta que contém seus arquivos .dpr e .pas como a pasta de trabalho do chat. As ferramentas de arquivo atuam dentro dela, então selecione o projeto que deseja alterar e não uma pasta pai com trabalho não relacionado. Uma pasta pai com muitos projetos torna a primeira pesquisa mais difícil de ler e aumenta o risco de editar a unidade errada.
Descreva uma tarefa em palavras simples, como o nome de um procedimento e o que deve mudar, e selecione Auto-run, Ask first ou Plan only antes de enviar. Tarefas pequenas geram diffs pequenos, que são fáceis de ler. Nomeie a unidade quando souber qual é; o agente pode encontrá-la com glob, mas uma unidade nomeada restringe a primeira pesquisa.
Expanda o cartão edit_file, leia cada linha adicionada e removida, depois aceite ou rejeite a mudança. Se você usou Plan only, leia o plano primeiro e mude para Ask first para executá-lo passo a passo. Um diff muito longo significa que a tarefa era grande demais, então rejeite-a e divida o pedido em dois menores.
Deixe o Shell executar seu comando de build e seu comando de teste, e leia o código de saída real no cartão. Um build com sucesso é um bom sinal, mas apenas seus próprios testes dizem se o comportamento ainda está correto. Execute o build antes dos testes e mantenha ambos os cartões abertos para que uma falha possa ser rastreada até uma mudança.
.6 entradasGreeter.passalvoGreeter.paslidobuild.batexit 0unit Greeter;
interface
function Greet(const Name: string): string;
implementation
function Greet(const Name: string): string;
begin
if Name = '' then
Result := 'Hello, guest'
else
Result := 'Hello, ' + Name;
end;
end.Greet recebe um nome e retorna uma saudação. Quando o nome está vazio, ele responde Hello, guest; caso contrário, ele concatena o nome ao texto, e Result contém o valor de retorno da função. A seção interface anuncia a função, e a seção implementation contém seu código, que é o layout padrão de toda unidade.
Iniciantes que estão aprendendo Delphi frequentemente perguntam onde um valor é gravado no disco. Peça ao Arraydeck para encontrar onde a configuração é salva. O agente executa grep pelo nome da configuração em seus arquivos .pas, depois read_file abre a unidade correspondente e a resposta aparece no chat com nomes de arquivo e linhas. Nada muda. Abra a unidade no seu editor para confirmar que o procedimento é o que você pretendia, e anote o nome do arquivo antes de pedir uma edição. Essa pesquisa apenas para leitura é um bom primeiro pedido em qualquer projeto que você não escreveu. Anote o arquivo e a linha antes de pedir qualquer edição, porque um nome de arquivo e um número de linha precisos tornam o próximo pedido objetivo e o próximo diff fácil de seguir para qualquer pessoa que analisar seu projeto depois de você.
Peça um manipulador mais seguro: encontre o procedimento que cria um objeto e garanta que ele seja liberado. O agente pesquisa com grep, lê a unidade e propõe a mudança com edit_file, envolvendo o código em try ... finally ... Free. Em Ask first, o diff aparece e nada é gravado até você aceitá-lo. Então o Shell executa seu comando de build, e o cartão mostra o código de saída real. Execute seus testes também. Um build que passa prova apenas a sintaxe, não que o objeto é liberado em todos os caminhos, então leia o diff com calma. Execute os testes mais uma vez após aceitar o diff e mantenha a versão antiga da unidade no seu backup ou controle de versão até ter certeza de que o manipulador ainda libera todos os objetos em todos os ramos.
Aqui está como modernizar aplicativos Delphi em pequenos passos: renomeie um procedimento pouco claro, um nome de cada vez. Peça ao agente para renomeá-lo em todas as unidades. Ele usa grep para listar cada lugar onde o nome ocorre, depois edit_file altera cada arquivo, e os diffs mostram cada linha que se move. Renomeie uma vez. Revise todos os diffs juntos, porque uma palavra correspondente dentro de uma string ou comentário nem sempre é uma chamada, então compile o projeto e execute seus testes antes de aceitar o último arquivo. Repita a renomeação para o próximo procedimento apenas quando o build e os testes passarem, para que um erro sempre fique em um diff pequeno e nunca se esconda dentro de uma longa lista de alterações não relacionadas em muitas unidades.
A lógica do triângulo de Pascal explicada em uma unidade curta faz um pedido de prática justo. Peça ao agente para ler o loop e descrever, linha por linha, o que cada variável contém em cada iteração. Ele chama read_file, depois responde no chat sem gravar nada, então Plan only é suficiente. Verifique a explicação executando a unidade você mesmo através do seu comando de build e seguindo o loop no papel por 3 ou 4 linhas. Se o agente e o programa discordarem, confie no programa e faça a pergunta novamente com a linha exata citada. Faça o mesmo para um segundo loop se a primeira resposta ajudou, e peça uma explicação mais curta quando um parágrafo parecer longo, porque você sempre pode solicitar mais detalhes exatamente na linha que causa confusão.
