34장: 소프트웨어 장인정신에 대한 주제

34장: 소프트웨어 장인정신에 대한 주제

• 이 책은 주로 고급 클래스, 반복문, 소스코드 레이아웃 같은 구체적 주제를 다뤘으며, 이 장은 복잡성·프로세스·가독성 등 추상적인 주제를 소개함.
• 이러한 추상적 주제가 해킹과 소프트웨어 장인정신의 차이를 많은 부분에서 설명함.

34.1 복잡성 정복

• 소프트웨어의 주요 기술적 의무는 복잡성 관리이며, 이는 효과적인 개발자가 되기 위한 핵심 요소임.
• 서브시스템 분리, 클래스 인터페이스 추상화, 전역 데이터·깊은 상속·중첩 반복문·goto 회피, 일관된 오류 처리, 루틴 간략화, 명확한 이름 등이 복잡성을 줄이는 방법임.
• 코드 작성 규약도 복잡성을 줄이기 위한 것임; 임의의 결정을 표준화해 더 어려운 문제에 집중하게 해줌.
• 추상화(고급 언어, 루틴, 클래스, 이름 상수, 객체지향)는 복잡성 관리의 강력한 도구이며, 소프트웨어 설계·구현의 핵심 목적은 결국 복잡성 정복임.

34.2 자신에게 맞는 프로세스 선택

• 프로세스가 중요함: 작은 프로젝트는 개인 능력이, 여러 명이 참여하는 프로젝트는 조직적 프로세스가 품질을 좌우함.
• 요구사항을 견고하게: 요구사항이 부실하면 설계·코드가 흔들리므로, 유연성이 필요하면 점진적 개발 방식을 사용함.
• 품질은 처음부터: 나중에 테스트로 다 고칠 수 있다는 생각은 잘못됨; 테스트는 결함을 알려줄 뿐 품질을 만들어주지는 않음.
• 성급한 최적화 금지: 효과적인 프로세스는 처음엔 굵직하게, 나중에 세밀하게 다듬음.
• 큰 프로세스든 하위 수준 프로세스든 의식적으로 좋은 프로세스를 따르는 것이 두뇌를 최대로 활용하는 길임.

34.3 컴퓨터보다 사람을 위한 프로그램을 작성하라

• 컴퓨터는 가독성에 신경 쓰지 않지만, 사람은 코드를 읽어야 하므로 가독성 있는 코드를 작성해야 함.
• 가독성은 이해도·검토 용이성·오류 비율·디버깅·수정 용이성·개발 시간·외적 품질에 긍정적 영향을 줌.
• 읽기 쉬운 코드는 장기적으로 더 빠르며, “개인 프로그램”이라도 나중의 자신을 위해 읽기 쉽게 작성해야 함.

34.4 언어에 제약을 받지 않고 언어를 활용한 프로그래밍

• 언어가 지원하지 않는 기능(assert, 열거형 등)은 직접 만들어 활용하면 됨; “언어에 얽매이지 말고 언어를 활용하라.”
• 툴이 원시적이라면 접근 방법을 조정해 균형을 맞추되, 어려운 기능을 해결해주는 규칙에서 더 큰 이득을 얻을 수 있음.

34.5 규약을 활용하여 핵심에 집중

• 프로그래밍의 상당 부분은 임의적임; 규약은 그런 임의의 결정을 표준화해 반복되는 수고를 덜어줌.
• 이름 짓기·들여쓰기·정렬 규칙은 정보를 간결히 전달하고, 위험한 습관을 없애거나 보완함.
• 규약은 하위 수준 작업을 예측 가능하게 만들어 코드 이해도를 높이고, 언어의 약점도 보완함.
• 큰 프로젝트는 규약을 과용하기 쉽고 작은 프로젝트는 무시하기 쉬우니, 구조가 필요한 곳에만 사용해야 함.

34.6 문제 중심의 프로그래밍

• 가장 높은 추상화 단계, 즉 컴퓨터 과학의 해결책이 아니라 문제 자체를 중심으로 작업하는 것이 복잡성을 다루는 또 다른 방법임.
• 최상위 수준 코드는 구현 세부 사항이 아니라 해결하려는 문제를 기술해야 함.

추상화 수준

• 0수준: 운영체제 연산과 기계 명령 — 고급 언어에서는 신경 쓸 필요 없음.
• 1수준: 프로그래밍 언어 구조와 도구.
• 2수준: 저수준 구현 구조(스택, 큐, 정렬·검색 알고리즘 등).
• 3수준: 저수준 문제 도메인 관점 — 문제 영역 어휘의 빌딩 블록을 만듦.
• 4수준: 고수준 문제 도메인 관점 — 비전문가도 읽을 수 있고, 언어 기능에 의존하지 않는 코드.
• 좋은 설계는 상위 계층에 집중하고 하위 계층은 무시할 수 있게 함.

34.7 낙석을 주의하라

• 프로그래밍은 예술과 과학 사이의 “기술”이며, 좋은 판단을 위해 경고 표시에 민감해야 함.
• “교묘한 코드”라는 말, 평균 이상의 오류를 가진 클래스, 비정상적인 결함 수는 모두 다시 개발하거나 프로세스를 점검하라는 경고임.
• 설계 측정법(7개 이상 멤버, 10개 이상 의사결정 지점, 낮은 응집력·높은 결합도 등)도 경고 신호임.
• 찾을 수 없는 오류의 가장 흔한 원인은 경고를 무시하는 것임; 자신만의 경고를 만들면 오류를 간과하기 어려워짐.
• 이해하기 어렵다는 느낌 자체가 경고임 — 어려운 것은 잘못된 것이므로 단순하게 만들어야 함.

34.8 반복, 반복, 또 반복

• 요구사항 정의, 단계적 배포, 프로토타이핑 등 반복은 소프트웨어 개발 전반에 적합하며, 대안을 보지 않고 한 해결책만 붙잡으면 실패함.
• 소프트웨어 설계는 발견적 과정이라 반복적으로 개정·향상되어야 하며, 첫 시도가 최적의 해결책은 아님.
• 코드 튜닝도 반복이 필요하지만 모든 최적화 시도가 도움이 되는 건 아님; 검토를 통과하지 못하면 되돌리는 것도 반복임.
• 초기 단계의 반복은 저비용으로 쓰고 버릴 수 있는 것을 빨리 만드는 것이 핵심임.

34.9 소프트웨어와 신조를 떼어 놓아라

• 신조(하나의 설계 방법에 대한 교리적 집착, 확고한 형식화 믿음 등)는 어떤 형태든 부적절함.

소프트웨어 신탁(Oracles)

• 새 기술은 검증 전까지 계속 사용해봐야 하지만, 모든 문제를 해결해줄 것처럼 파는 “교리적 방법론”은 경계해야 함.
• 최신 유행에 집착하지 말고 오래되고 신뢰할 수 있는 방법과 섞어 사용하라.

절충주의

• 소프트웨어 개발은 발견적 과정이라 견고한(rigid) 방법론이 부적절하며, 여러 접근 방법을 시도해 봐야 함.
• 하나의 방법만 고집하는 것도, 문제를 이해하기 전에 성급히 해결책을 정하는 것도 해로움.
• 기법을 도구로 여기고 문제에 맞는 도구를 선택하되, 독단적인 태도는 이 접근과 상충함.

실험

• 실험 결과에 따라 기꺼이 신념을 바꿀 수 있어야 실험이 의미 있음; 실수를 피하려는 시도 자체가 가장 큰 실수임.
• 아키텍처·상세 설계·언어·프로세스 등 모든 수준에서 실험이 가능하며, 핵심은 열린 마음을 유지하는 것임.

요점 정리

• 프로그래밍의 한 가지 중요한 목표는 복잡성을 관리하는 것이다.
• 프로그래밍 프로세스는 최종 제품에 큰 영향을 미친다.
• 팀 프로그래밍은 컴퓨터보다 사람들과의 의사소통 작업이다. 개인 프로그래밍은 컴퓨터보다 자신과의 의사소통 작업이다.
• 프로그래밍 규약을 남용하면 병보다 더 나쁜 약이 될 수 있지만, 심사숙고하여 사용한다면 복잡성 관리와 의사소통에 도움이 된다.
• 해결책보다는 문제의 관점에서 프로그래밍하는 것이 복잡성을 관리하는 데 도움이 된다.
• “의심으로부터 오는 짜증”과 같은 지적인 경고 표시에 특히 주의해야 한다.
• 각 개발 활동을 반복하면 할수록 제품은 더욱더 좋아질 것이다.
• 독단적인 방법론과 품질이 뛰어난 소프트웨어는 어울리지 않는다. 지적인 도구 상자를 대안으로 채우고 일에 맞는 올바른 도구를 선택할 수 있는 기술을 향상시켜라.