노트롭 파이크의 프로그래밍 5규칙
Rob Pike's 5 Rules of Programming
설계#performance · 연결된 개념 6개
쉽게 말하면
롭 파이크의 5규칙은 '어디가 느린지 짐작하지 말고 재 보고, 멋 부리지 말고 단순하게 짜고, 데이터 구조를 잘 고르라'는 이야기예요. 주소록을 이름순으로 정리해 두면 찾는 방법은 따로 고민할 필요가 없는 것처럼요.
비유가 깨지는 곳 단순한 알고리즘을 쓰라는 건 n이 대개 작아서예요. n이 자주 커진다는 걸 알게 되면 그때는 더 나은 알고리즘이 맞고, 튜닝도 측정해서 한 부분이 나머지를 압도할 때만 해요.
벨 연구소(Bell Labs)에서 Unix·Plan 9 작업에 참여했고 Go를 공동 설계한 롭 파이크가 정리한 다섯 가지 프로그래밍 규칙. 앞의 둘은 측정, 가운데 둘은 단순함, 마지막은 데이터 구조에 관한 이야기다.
- 프로그램이 어디서 시간을 쓸지는 알 수 없다. 병목은 의외의 곳에서 생기니 증명하기 전에는 속도 해킹을 넣지 않는다
- 측정하라. 측정 전에는 튜닝하지 말고, 측정한 뒤에도 한 부분이 나머지를 압도할 때만 한다
- 멋진 알고리즘은 n이 작을 때 느리고, n은 대개 작다. 상수 항이 크기 때문이다. n이 자주 커진다는 걸 알기 전까지는 멋 부리지 않는다
- 멋진 알고리즘은 단순한 것보다 버그가 많고 구현하기 어렵다. 단순한 알고리즘과 단순한 자료구조를 쓴다
- 데이터가 지배한다. 올바른 자료구조를 고르고 잘 정리하면 알고리즘은 거의 저절로 드러난다
- 1·2번은 크누스의 섣부른 최적화 격언을 다시 말한 것이다
- 켄 톰슨(Ken Thompson)은 3·4번을 "의심스러우면 무식하게 풀어라"로 줄였고, 둘 다 KISS 원칙의 한 예다
- 5번은 프레드 브룩스(Fred Brooks)가 『맨먼스 미신』(The Mythical Man-Month)에서 먼저 한 말로, "똑똑한 객체를 쓰는 멍청한 코드를 써라"로 줄여 부르기도 한다. 『리팩터링』의 "프로그램의 진짜 힘은 데이터 구조에서 나온다"(필드 옮기기)와 같은 이야기다
자료구조 선택이 실제로 얼마나 차이를 만드는지는 빅오 표기법, 해시 테이블을 보면 실감할 수 있다.
출처: Notes on Programming in C 롭 파이크 · Rob Pike's 5 Rules of Programming
연결된 개념
이 노트를 가리키는 문서
뜻이 가까운 노트
- 소프트웨어 공학의 법칙들
소프트웨어 시스템과 팀, 의사결정에 반복해서 나타나는 경험칙들을 모아 부르는 말. 법칙이라고 부르지만 대부분 증명된 정리가 아니라 관찰과 격언이다. 판단할 때 떠올릴 이름표로 쓴다. 따로 노트를 둔 것은 링크로, 나머지는 한 줄로 적었다.
- 심플 디자인
켄트 벡이 XP(Extreme Programming)에서 제시한 단순한 설계의 네 가지 규칙. 우선순위 순으로 ① 모든 테스트를 통과하고 ② 의도를 드러내고 ③ 중복이 없고 ④ 요소가 가장 적다. 마틴 파울러가 이렇게 정리한 형태가 널리 쓰인다.
- 코드 냄새
당장 버그는 아니지만 이해나 변경 비용을 높이는 구조적 신호. 리팩터링을 언제 시작하고 멈출지에 정확한 공식은 없어서, 냄새라는 어휘로 직관을 공유한다.
- 러버덕 디버깅
문제를 남에게(혹은 고무 오리에게) 말로 설명하다 보면 스스로 답을 찾게 되는 디버깅 방법.
- 집단 코드 소유
코드의 주인을 개인으로 두지 않고 팀 전체가 코드베이스 전체를 소유해, 누구나 필요한 곳을 고칠 수 있게 하는 XP 실천법.