폴더 열기
대화 상자의 작업 폴더로 .dpr 및 .pas 파일을 포함하는 폴더를 선택하세요. 파일 도구는 해당 폴더 내에서 작동하므로, 변경하려는 프로젝트를 선택하고 관련 없는 작업이 포함된 상위 폴더는 피하세요. 여러 프로젝트가 있는 상위 폴더를 선택하면 첫 번째 검색 결과가 읽기 어려워지고 잘못된 유닛을 편집할 위험이 커집니다.
워크플로우
4단계로 완성하는 델파이 프로그래밍 워크플로우
03
프로젝트 열기, 한 가지 변경, 확인하기
좋은 델파이 프로그래밍 워크플로우는 간결해야 합니다. 프로젝트 폴더를 열고, 한 가지 변경 사항을 요청한 뒤 변경 내역을 확인하고 빌드 명령을 실행하세요. Arraydeck은 실제 도구를 사용해 이 루프를 따르므로, 첫 번째 검색부터 마지막 종료 코드에 이르기까지 각 단계는 채팅에 카드 형태로 남습니다. 이 카드를 확장해 내용을 검토하고 검사할 수 있습니다. 요약 뒤에 숨겨진 정보는 없습니다. 만약 한 단계가 잘못 보인다면, 그 시점에서 루프를 멈추고 변경 사항을 거부한 후 요청을 다시 작성하면 파일들은 해당 단계 이전 상태로 유지됩니다. 이 네 가지 단계는 작은 유닛부터 많은 폼을 가진 프로젝트까지 모두 동일하게 작동합니다. 초보자나 오랜 기간 유지보수를 해온 개발자 모두 읽기 전용 검색부터 시작할 수 있습니다. 이 작업은 파일을 변경하지 않지만 프로젝트 구조를 파악하는 데 도움이 됩니다.
변경 사항 설명하기
절차명이나 변경 내용 등 평이한 언어로 하나의 작업을 작성한 후, 전송 전에 Auto-run, Ask first 또는 Plan only 중 하나를 선택하세요. 작은 작업은 읽기 쉬운 작은 변경 내역을 생성합니다. 유닛을 알고 있다면 이름을 명시하세요. 에이전트는 glob로 유닛을 찾을 수 있지만, 유닛 이름을 지정하면 첫 번째 검색 범위를 좁힐 수 있습니다.
변경 내역 읽기
edit_file 카드를 확장해 추가된 줄과 제거된 줄을 모두 읽고, 변경 사항을 수락하거나 거부하세요. Plan only를 사용했다면 먼저 계획을 읽고 Ask first로 전환해 단계별로 실행하세요. 변경 내역이 매우 길다면 작업이 너무 큰 것이므로, 이를 거부하고 요청을 두 개의 작은 작업으로 나누세요.
빌드 및 테스트
Shell을 사용해 빌드 명령과 테스트 명령을 실행하고, 카드에 표시된 실제 종료 코드를 확인하세요. 빌드가 성공하면 좋은 신호이지만, 동작이 여전히 올바른지 확인하려면 자체 테스트가 필요합니다. 테스트 전에 빌드를 실행하고, 실패 원인을 한 가지 변경 사항으로 추적할 수 있도록 두 카드를 모두 열어 두세요.
연습용 작은 유닛
Greet 함수가 있는 Greeter.pas를 만들고 프로젝트 빌드가 되는지 확인하세요.
- list_dir
.6개 항목 - write_file
Greeter.pas저장됨 - read_file
Greeter.pas읽기 완료 - Shell
build.bat종료 코드 0
다음 단계 전에 사용자의 승인을 기다리는 중거부수락
Greeter.pas
unit 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은 이름을 받아 인사를 반환합니다. 이름이 비어 있으면 'Hello, guest'라고 응답하고, 그렇지 않으면 이름과 텍스트를 연결합니다. Result는 함수의 반환 값을 저장합니다. 인터페이스 섹션은 함수를 선언하고, 구현 섹션에는 코드가 위치합니다. 이 구조는 모든 유닛의 기본 레이아웃입니다.
델파이 소프트웨어 유지보수를 위한 네 가지 작업
설정 파일 저장 위치 찾기
델파이를 배우는 초보자들은 종종 값이 디스크의 어디에 저장되는지 궁금해합니다. Arraydeck에게 설정이 어디에 기록되는지 찾아달라고 요청하세요. 에이전트는 .pas 파일 전체에서 설정 이름에 대해 grep을 실행한 후, read_file로 해당 유닛을 엽니다. 그러면 파일 이름과 줄 번호가 채팅에 표시됩니다. 파일이 변경되지는 않습니다. 절차가 맞는지 확인하려면 자체 편집기에서 유닛을 열고, 편집 요청을 하기 전에 파일 이름을 메모해 두세요. 이 읽기 전용 검색은 자신이 작성하지 않은 프로젝트에서 시작할 때 좋은 첫 번째 요청입니다. 편집 요청을 하기 전에 파일과 줄 번호를 적어두세요. 정확한 파일 이름과 줄 번호는 다음 요청을 간결하게 만들고, 이후 프로젝트를 읽는 사람이 변경 내역을 쉽게 따라갈 수 있게 합니다.
객체 주변에 try finally 추가하기
더 안전한 핸들러를 요청하세요: 객체를 생성하는 절차를 찾아 객체가 해제되도록 보장하세요. 에이전트는 grep으로 검색하고 유닛을 읽은 후 edit_file을 사용해 코드를 try ... finally ... Free로 감싸는 변경 사항을 제안합니다. Ask first 모드에서는 변경 내역이 표시되며, 수락하기 전까지 파일이 변경되지 않습니다. 그런 다음 Shell로 빌드 명령을 실행하면 카드에 실제 종료 코드가 표시됩니다. 테스트도 실행하세요. 빌드가 성공한다는 것은 구문이 맞다는 의미일 뿐, 모든 경로에서 객체가 해제된다는 보장은 아닙니다. 따라서 변경 내역을 천천히 읽으세요. 변경 내역을 수락한 후 테스트를 한 번 더 실행하고, 핸들러가 모든 분기에서 객체를 해제하는지 확신이 들 때까지 자체 백업이나 버전 관리 시스템에 유닛의 이전 버전을 보관하세요.
절차명 전체 변경하기
델파이 앱을 작은 단계로 현대화하는 방법입니다: 명확하지 않은 절차명을 한 번에 하나씩 변경하세요. 에이전트에게 모든 유닛에서 절차명을 변경하도록 요청하세요. 에이전트는 grep을 사용해 이름이 사용되는 모든 위치를 나열한 후 edit_file로 각 파일을 변경합니다. 변경 내역에는 이동된 모든 줄이 표시됩니다. 한 번 변경한 후, 문자열이나 주석 내부의 일치하는 단어가 항상 호출을 의미하는 것은 아니므로 모든 변경 내역을 함께 검토하세요. 마지막 파일을 수락하기 전에 프로젝트를 빌드하고 테스트를 실행하세요. 빌드와 테스트가 모두 성공했을 때만 다음 절차명에 대해 변경을 반복하세요. 이렇게 하면 실수가 항상 작은 변경 내역에 머물러 있고, 여러 유닛에 걸친 관련 없는 변경 목록 속에 숨지 않게 됩니다.
반복문 줄별로 설명하기
파스칼 삼각형 로직을 짧은 유닛으로 설명하는 것은 좋은 연습 요청입니다. 에이전트에게 반복문을 읽고 각 변수가 각 반복마다 어떤 값을 가지는지 줄별로 설명하도록 요청하세요. 에이전트는 read_file을 호출한 후 아무것도 작성하지 않고 채팅으로 답변하므로 Plan only로 충분합니다. 빌드 명령을 통해 유닛을 직접 실행하고, 종이 위에 3~4개의 행에 대해 반복문을 따라가며 설명이 맞는지 확인하세요. 에이전트의 설명과 프로그램의 실행 결과가 다르면 프로그램을 신뢰하고, 정확한 줄을 인용해 질문을 다시 하세요. 첫 번째 답변이 도움이 되었다면 두 번째 반복문에도 동일한 작업을 수행하세요. 설명이 너무 길다면 더 짧은 설명을 요청하세요. 정확히 어떤 줄이 헷갈리는지에 대해서는 언제든지 더 자세한 정보를 요청할 수 있습니다.
