9장: 의사코드 프로그래밍 프로세스

9장: 의사코드 프로그래밍 프로세스

• 이 장은 클래스와 루틴을 만드는 작은 단위의 프로그래밍 절차에 초점을 맞춤
• 의사코드 프로그래밍 프로세스(PPP)는 상세 설계, 문서화, 코딩을 한 흐름으로 묶어 품질을 높이고 작업량을 줄임
• PPP만이 유일한 방법은 아니지만, 많은 프로그래머가 충분히 활용하지 못하는 강력한 도구임

9.1 클래스 및 루틴 개발 단계 요약

• 클래스 작성은 보통 반복적임
• 클래스의 일반 설계를 만들고, 내부 루틴을 나열하고, 각 루틴을 구현하고, 클래스 전체를 점검하는 흐름으로 진행됨
• 구체 루틴을 만들면서 새 루틴이 필요해지고, 그 결과가 다시 클래스 설계로 되돌아갈 수 있음

클래스 작성 단계

• 클래스의 일반 설계 만들기: 책임, 숨길 비밀, 인터페이스가 표현할 추상화, 상속 여부, 파생 허용 여부, 주요 공개 메서드, 복잡한 데이터 멤버를 정의함
• 클래스 안의 각 루틴 작성: 주요 루틴을 만들다 보면 보조 루틴이나 새로운 주요 루틴이 필요해질 수 있음
• 클래스 전체 리뷰와 테스트: 개별 루틴 테스트 뒤, 클래스 단위에서만 보이는 문제를 확인함

루틴 작성 단계

• 단순 접근자나 전달 루틴은 바로 작성할 수 있지만, 복잡한 루틴은 체계적 접근이 필요함
• 보통 루틴 설계, 설계 점검, 루틴 코딩, 코드 리뷰와 테스트 순서로 진행함
• 필요하면 각 단계는 반복됨

9.2 전문가를 위한 의사코드

• 의사코드는 알고리즘, 루틴, 클래스, 프로그램이 어떻게 동작할지 설명하는 영어식 비공식 표기임
• PPP는 루틴 내부 코드를 더 쉽게 만들기 위해 의사코드를 사용하는 구체적 방법임

좋은 의사코드 작성 지침

• 구체적인 연산을 정확하게 설명하는 자연어 문장을 사용함
• 목표 프로그래밍 언어의 문법 요소를 피함
• 구현 방식보다 의도를 설명함
• 코드를 거의 기계적으로 만들 수 있을 만큼 충분히 낮은 수준까지 상세화함
  • 너무 높은 수준이면 문제가 되는 세부를 가릴 수 있으므로, 코드 작성이 더 쉬워 보일 때까지 다듬음

의사코드의 효과

• 의사코드는 작성 뒤 코드 주석으로 바뀌므로 별도의 주석 작성 노력을 줄임
• 소스 코드를 보기 전 상세 설계를 리뷰할 수 있어 리뷰가 쉬워짐
• 높은 수준 설계에서 의사코드, 다시 소스 코드로 점진적으로 정제할 수 있음
• 오류를 가장 적은 노력이 들어간 단계에서 발견할 가능성이 커짐
• 몇 줄의 의사코드는 한 페이지의 코드보다 고치기 쉬움
• 의사코드가 코드 안의 주석으로 남으면 설계 문서와 구현이 따로 노는 문제도 줄어듦

9.3 PPP를 이용한 루틴 구현

• PPP의 루틴 작성 흐름은 루틴 설계, 루틴 코딩, 코드 점검, 남은 문제 정리, 필요 시 반복으로 나뉨

루틴 설계

• 선행 조건 확인: 루틴의 일이 잘 정의되어 있고 전체 설계에 자연스럽게 맞는지 확인함
• 루틴이 풀 문제 정의: 루틴이 숨길 정보, 입력, 출력, 선조건, 후조건을 정함
• 루틴 이름 짓기: 명확한 이름이 안 나오면 루틴 목적이나 설계가 흐릿하다는 신호로 봄
• 테스트 방법 생각하기: 작성 중에 유효 입력, 무효 입력, 경계 조건을 어떻게 확인할지 생각함
• 표준 라이브러리 조사: 이미 검증된 라이브러리나 사내 코드가 있는지 먼저 확인함
• 오류 처리 생각하기: 나쁜 입력, 다른 루틴의 무효 반환값, 예외 상황에 어떻게 대응할지 정함
• 효율 생각하기: 대부분은 안정적인 인터페이스와 읽기 쉬운 구현을 우선하고, 성능 중요 영역만 예산에 맞춰 설계함
• 알고리즘과 데이터형 조사: 직접 복잡한 코드를 쓰기 전에 알고리즘 책이나 기존 구현을 확인함
• 의사코드 작성: 일반적인 설명에서 시작해 점점 구체화함
• 데이터 생각하기: 데이터 조작이 핵심인 루틴은 주요 데이터형을 먼저 잡아야 로직 설계가 쉬움
• 의사코드 점검: 의사코드만 보고 루틴을 설명할 수 있는지 확인하고, 다른 사람에게 리뷰를 요청함
• 여러 아이디어 반복: 코딩 전에 의사코드 수준에서 여러 접근을 시도하고 가장 나은 것을 고름

루틴 코딩

• 루틴 선언을 작성하고, 의사코드의 머리말을 언어 주석으로 바꿈
• 루틴의 첫 문장과 마지막 문장을 만들고, 의사코드를 고수준 주석으로 바꿈
• 각 주석 아래에 실제 코드를 채움
• 한 줄의 의사코드가 예상보다 많은 코드로 커지면 새 루틴으로 분리함
  • 또는 PPP를 재귀적으로 적용해 그 의사코드를 더 작은 의사코드로 분해함
  • 의사코드 주석 하나는 보통 완결된 생각 하나와 그에 해당하는 코드 블록을 이룸

코드 점검

완성된 루틴은 바로 넘기지 말고 이 단계에서 최대한 오류를 찾음

• 먼저 머릿속으로 실행 경로, 정상 경로, 끝점, 예외 조건을 확인함
  • 혼자 하는 desk checking과 동료 리뷰, walk-through, inspection을 활용함
  • 동작하는 것만으로 충분하지 않음. 왜 동작하는지 이해해야 함
• 컴파일은 너무 일찍 하지 않는 편이 좋음. 한 번만 더 컴파일이라는 조급한 수정 루프에 빠질 수 있기 때문임
  • 컴파일러 경고 수준은 최대한 엄격하게 켜고, 모든 경고와 오류 원인을 제거함
  • 컴파일되지 않는 코드가 있다면 유효성 검사 도구를 사용함
• 디버거로 각 줄이 기대대로 실행되는지 확인함
• 미리 생각한 테스트 케이스로 테스트하고, 필요하면 테스트 하네스나 스텁을 만듦
• 유난히 버그가 많은 루틴은 땜질보다 다시 설계하고 다시 쓰는 편이 나을 수 있음

남은 문제 정리

• 루틴 인터페이스를 확인해 모든 입력과 출력, 매개변수 사용 여부를 점검함
• 루틴이 한 가지 일을 잘하는지, 느슨하게 결합되었는지, 방어적으로 설계되었는지 확인함
• 변수 이름, 미사용 객체, 초기화, 선언 문제를 확인함
• 명령문과 논리에서 경계 오류, 무한 루프, 잘못된 중첩, 자원 누수를 확인함
• 레이아웃이 논리 구조를 드러내는지 확인함
• 의사코드에서 변환된 주석이 여전히 정확한지 확인함
• 잘 지은 루틴 호출 바로 앞의 중복 주석처럼 의미가 사라진 주석은 제거함
• 품질이 낮다면 의사코드 단계로 돌아가 다시 반복함

9.4 PPP 대안

• 테스트 우선 개발: 코드를 쓰기 전에 테스트 케이스를 먼저 작성함
• 리팩터링: 의미를 유지하는 작은 변환을 반복해 기존 코드를 개선함
• 계약에 의한 설계: 각 루틴을 선조건과 후조건을 가진 계약으로 봄
• 해킹식 접근: 체계적 절차 없이 작동하는 코드 쪽으로 밀고 가는 방식임. 중간에 막히거나 일부 구현을 잊거나 시작점을 못 찾는다면 PPP가 더 적합하다는 신호임

참고 자료

• Beck, Test-Driven Development: By Example
• Fowler, Refactoring: Improving the Design of Existing Code
• Meyer, Object-Oriented Software Construction
• Grove, High Output Management
• Ramsey, Atwood & Van Doren의 의사코드 선호도 연구

체크리스트: 의사코드 프로그래밍 프로세스

• 선행 조건이 충족되었는지 확인했는가?
• 클래스가 풀 문제를 정의했는가?
• 상위 설계가 클래스와 각 루틴에 좋은 이름을 붙일 만큼 명확한가?
• 클래스와 각 루틴을 어떻게 테스트할지 생각했는가?
• 효율을 안정적인 인터페이스와 읽기 쉬운 구현 관점에서 볼지, 자원과 속도 예산 관점에서 볼지 정했는가?
• 표준 라이브러리와 다른 코드 라이브러리에서 적용 가능한 루틴이나 컴포넌트를 확인했는가?
• 참고서에서 도움이 되는 알고리즘을 확인했는가?
• 각 루틴을 상세 의사코드로 설계했는가?
• 의사코드를 머릿속으로 점검했는가? 이해하기 쉬운가?
• 전역 데이터 사용, 다른 클래스나 루틴에 더 어울리는 작업 등 설계로 되돌아가야 할 경고 신호에 주의했는가?
• 의사코드를 코드로 정확히 옮겼는가?
• 필요할 때 PPP를 재귀적으로 적용해 루틴을 더 작은 루틴으로 나누었는가?
• 가정을 세울 때마다 문서화했는가?
• 중복으로 변한 주석을 제거했는가?
• 첫 번째 반복에서 멈추지 않고 여러 반복 중 가장 나은 것을 선택했는가?
• 코드를 철저히 이해하는가? 이해하기 쉬운가?

요점 정리

• 클래스와 루틴 작성은 반복적이다. 특정 루틴을 만들며 얻은 통찰이 클래스 설계 전체로 되돌아갈 수 있다.
• 좋은 의사코드는 이해하기 쉬운 자연어를 사용하고, 특정 언어 문법을 피하며, 구현 방식보다 의도를 설명한다.
• PPP는 상세 설계 도구이며 코딩을 쉽게 만든다. 의사코드는 바로 주석으로 바뀌어 정확하고 유용한 설명을 남긴다.
• 처음 떠오른 설계에 만족하지 말고, 의사코드 수준에서 여러 접근을 반복한 뒤 가장 나은 방식을 고른다.
• 각 단계에서 작업을 점검하고 다른 사람의 검토를 받으면, 가장 비용이 적은 단계에서 실수를 잡을 수 있다.