4장: 구현 시 결정해야 할 핵심 사항

4장: 구현 시 결정해야 할 핵심 사항

• 선행 조건을 갖춘 뒤에는, 개별 프로그래머와 기술 리드가 직접 책임지는 구현 준비로 초점이 옮겨감
• 어떤 언어·도구·실천법을 고를지에 대한 결정을 다룸

4.1 프로그래밍 언어 선택

• 구현 내내 그 언어에 파묻혀 일하게 되므로 언어 선택은 중요하며, 여러 연구가 생산성과 품질에 미치는 영향을 보여줌
• 익숙한 언어를 쓰는 프로그래머가 더 생산적임, 3년 이상 써온 언어에서는 약 30% 더 높다는 데이터가 있음
• 고급 언어일수록 생산성·신뢰성·표현력이 높음, C++·Java 같은 언어는 어셈블리·C 대비 5~15배 향상으로 평가되며 한 줄이 더 많은 일을 함
• 언어는 사고 방식까지 좌우함, 표현할 단어가 없으면 그 생각 자체를 떠올리지 못한다는 Sapir-Whorf 가설처럼 언어가 떠올릴 수 있는 해법의 범위를 제한함
  • Fortran 사고에 머문 사람은 C++로 와도 “위장된 Fortran”을 쓰게 됨
• 결국 핵심은 쓰는 언어의 강점과 약점을 분명히 알고, 약점은 의식적으로 보완하는 것임

4.2 프로그래밍 규약

• 고품질 코드에서는 아키텍처의 개념적 일관성이 저수준 구현까지 이어짐, 변수·클래스·루틴 이름과 형식·주석 규약이 그 일관성을 만드는 수단임
• 통일된 규율이 없으면 코드가 제멋대로인 스타일의 뒤범벅이 되고, 그 임의적 편차를 해석하는 데 뇌가 낭비됨
• 규약의 목적은 그런 임의적 변형을 없애 정말 필요한 변형에만 집중하게 하는 것임
• 규약은 구현 전에 정해야 함, 워낙 세밀해서 코드를 다 쓴 뒤 끼워 맞추는 것은 거의 불가능함

4.3 기술 흐름에서의 위치

• 기술에는 흥망 주기(파도)가 있고, 그 위 어디에 서 있느냐가 하루의 작업 방식을 좌우함
• 성숙한(후반) 환경에서는 도구·문서·라이브러리가 풍부해 대부분의 시간을 새 기능 작성에 쓸 수 있음
• 초기(전반) 환경에서는 도구가 원시적이라, 언어의 미문서화 기능을 파악하고 라이브러리 코드의 결함을 직접 디버깅하며 벤더의 새 릴리스에 맞춰 코드를 고치는 데 상당한 시간을 씀
  • 단, 초기 기술을 피하라는 뜻은 아님, 혁신적 애플리케이션은 오히려 이런 환경에서 자주 나옴 — 핵심은 위치가 하루의 작업 방식을 정한다는 것임
• 도구가 사고 방식을 좌우하게 두지 말 것 — 언어가 주는 기능에 생각을 가두지 말고, 표현할 생각을 먼저 정한 뒤 언어에 없는 구조는 직접 코딩 규약·표준·클래스 라이브러리를 만들어 보완함 (책은 이를 언어 “안에서”가 아니라 “속으로” 프로그래밍한다고 부름)
  • 예: 초기 Visual Basic엔 UI·업무 로직·DB를 분리할 장치가 없어, 직접 규약을 만들어 분리함으로써 프로젝트를 관리 가능하게 유지함
• 중요한 프로그래밍 원칙 대부분은 특정 언어가 아니라 언어를 쓰는 방식에 달려 있음 (저자가 이 책의 핵심으로 강조)
• 환경이 원시적일수록 이렇게 직접 더한 규약·실천이 오히려 더 큰 도움이 됨, 언어가 적게 줄수록 내가 메우는 몫이 커지기 때문임 (만들기가 더 쉽다는 뜻은 아님)

4.4 주요 구현 실천법 선택

• 구현 준비의 일부는 많은 좋은 실천법 중 무엇을 강조할지 정하는 것임
• 정답인 한 조합은 없음, 페어 프로그래밍과 테스트 우선, 또는 단독 개발과 공식 검사 모두 상황에 따라 잘 통함
• 쓸 수 있는 것보다 실천법이 더 많으므로, 아래 체크리스트로 포함·제외를 의식적으로 결정함

체크리스트: 주요 구현 실천법

코딩

• 사전 설계와 키보드 앞 설계의 비중을 정의했는가?
• 이름, 주석, 레이아웃에 대한 코딩 규약을 정의했는가?
• 오류 처리, 보안, 클래스 인터페이스, 재사용 코드 표준 등 아키텍처가 함의하는 구현 실천법을 정의했는가?
• 기술 흐름에서의 위치를 파악하고 접근 방식을 맞췄는가?

팀워크

• 체크인 전 거쳐야 할 통합 절차를 정의했는가?
• 페어로 작업할지, 개별로 작업할지, 둘을 섞을지 정했는가?

품질 보증

• 코드를 작성하기 전에 테스트 케이스를 먼저 작성할 것인가?
• 먼저든 나중이든 단위 테스트를 작성할 것인가?
• 체크인 전 디버거로 단계별 실행하고 통합 테스트를 할 것인가?
• 서로의 코드를 리뷰하거나 검사할 것인가?

도구

• 버전 관리 도구, 언어·컴파일러 버전을 선택했는가?
• 프레임워크 사용 여부와 비표준 언어 기능 허용 여부를 정했는가?
• 에디터, 리팩터링 도구, 디버거, 테스트 프레임워크 등 다른 도구를 확보했는가?

요점 정리

• 모든 프로그래밍 언어에는 강점과 약점이 있다. 쓰는 언어의 강점과 약점을 알고 있어야 한다.
• 프로그래밍을 시작하기 전에 규약을 정해라. 나중에 코드를 규약에 맞추는 것은 거의 불가능하다.
• 한 프로젝트에서 쓸 수 있는 것보다 많은 구현 실천법이 존재한다. 가장 잘 맞는 것을 의식적으로 선택해라.
• 지금 쓰는 실천법이 언어에 대한 대응인지, 언어에 끌려가는 것인지 자문해라. 언어 “안에서”가 아니라 “속으로” 프로그래밍해라.
• 기술 흐름에서의 위치가 어떤 접근이 효과적이거나 가능한지를 결정한다. 자신의 위치를 파악하고 계획과 기대치를 맞춰라.