Principle of Least Astonishment
· 연결된 개념 11개
최소 놀람의 원칙은 수도꼭지를 빨간 쪽으로 돌리면 뜨거운 물이 나와야 한다는 것과 같아요. 이름과 관례만 보고 짐작한 대로 움직여야, 쓰는 사람이 매번 확인하지 않아도 실수가 없죠.
비유가 깨지는 곳 수도꼭지는 색으로 약속하지만 코드에선 이름이 곧 약속이에요. delete()가 실제론 보관만 하거나 get으로 시작하는 함수가 상태를 바꾸면 놀라니, 이름을 고치거나 동작을 이름에 맞춰요.
함수·API(Application Programming Interface)·UI(User Interface)는 사용자와 다른 개발자를 가장 덜 놀라게 하는 방식으로 동작해야 한다는 원칙. 이름과 관례에서 예측한 대로 움직여야 한다.
delete()가 실제로는 보관 처리만 한다면 설계 결함이다. 이름을 바꾸거나 동작을 이름에 맞춘다(함수 선언 바꾸기)get으로 시작하는 함수가 상태를 바꾸면 놀란다. 질의와 명령을 나누면 놀람이 준다(명령-질의 분리)출처: Laws of Software Engineering: Principle of Least Astonishment
존 야블론스키가 사용자 경험(User Experience, UX) 디자인에 자주 쓰이는 심리학 원리를 정리한 책. 법칙마다 기원, 핵심 내용, 실제 사례를 짧게 다루고, 마지막 장에서 이 원리들이 사람을 조종하는 데 쓰일 수 있다는 윤리 문제를 짚는다. 같은 내용을 저자의 사이트 lawsofux.com에서도 볼 수 있다.
켄트 벡이 XP(Extreme Programming)에서 제시한 단순한 설계의 네 가지 규칙. 우선순위 순으로 ① 모든 테스트를 통과하고 ② 의도를 드러내고 ③ 중복이 없고 ④ 요소가 가장 적다. 마틴 파울러가 이렇게 정리한 형태가 널리 쓰인다.
고수준 모듈(업무 규칙)이 저수준 모듈(데이터베이스(DB), HTTP(Hypertext Transfer Protocol) 클라이언트 같은 세부 구현)에 직접 의존하지 않고, 둘 다 추상화에 의존해야 한다는 원칙. 의존 방향이 "업무 → 세부"에서 "세부 → 추상화 ← 업무"로 뒤집힌다.
객체지향 설계를 위한 다섯 가지 원칙의 머리글자. 로버트 C. 마틴(Robert C. Martin)이 정리했고 마이클 페더스(Michael Feathers)가 SOLID라는 약어를 붙였다.
2001년 개발자들이 발표한 선언. 절차보다 사람, 문서보다 작동하는 소프트웨어, 계약보다 협력, 계획보다 변화 대응을 더 가치 있게 여긴다.