- 모듈화의 규칙 : 깔끔한 인터페이스와 함께 간단한 부분을 작성하라.
- 복잡한 소프트웨어를 작성해낼 수 있는 유일한 길은 전체적인 복잡도를 낮추는 방법뿐이다.
- 깔끔한 인터페이스로 구성된 간단한 모듈로부터 프로그램을 만들어 간다면, 많은 부분은 지역적으로 이해할 수 있다.
- 어떤 모듈을 수정하더라도 전체가 같이 망가지는 일은 없도록 한다.
- 명료함의 규칙 : 명료함은 영리함보다 중요하다.
- 프로그램을 설계할 때는 프로그램을 실행하는 컴퓨터보다 소스 코드를 읽고 유지보수 할 사람이 더 중요하다.
- 성능을 약간 개선하려고 복잡하고 난해한 코드를 택하는 것은 정말 멍청한 거래이다.
- 복잡한 코드는 버그들이 은신하기 딱 알맞기도 하지만 나중에 유지보수를 해야 하는 사람들이 그 복잡함에 좌절하지도 모르기 때문이다.
- 조합의 규칙 : 다른 프로그램과 결합될 수 있도록 프로그램을 설계하라.
- 프로그램이 다른 프로그램과 통신하지 못한다면 지나치게 복잡한 프로그램이 되는 것을 막을 수 없다.
- 단순한 텍스트 기반의 데이터로 입/출력하는 프로그램을 작성하는 방법이 좋다. 이러한 포맷은 스트림 지향적이고 장치와 독립적이다.
- 텍스트 스트림을 파싱해야 하는 오버헤드는 있겠지만, 그렇게만 된다면 일반적인 툴도 또한 연결해서 사용할 수 있으므로 활용도는 높아진다.
- 분리의 규칙 : 메커니즘과 정책을 분리하라. 인터페이스와 엔진을 분리하라.
- 엔진과 인터페이스를 분리하는 방법을 찾아야 함을 뜻한다.
- 프론트엔드와 백엔드 프로세스로 나누고, 이들 사이를 특별한 프로토콜을 사용해서 통신하게 하는 방법도 있다.
- 프론트엔드는 정책을, 백엔드는 메커니즘을 담당하게 된다.
- 전체적인 복잡도는 한 프로세스에서 모든 과정을 처리하는 방법보다 줄어든다.
- 버그도 많이 줄일 수 있고, 비용도 줄일 수 있을 것이다.
- 단순함의 규칙 : 단순함을 최우선 가치로 두고 설계하라. 어쩔 수 없을 때에만 복잡함을 더하라.
- 프로그램을 상호작용하는 작음 프로그램들로 쪼개는 것을 말한다.
- 이러한 재귀적 방법을 통해 거추장스럽게 치장하거나 쓸데없이 요란하게 디자인된 것을 바로 잡을 수 있다.
- 절약의 규칙 : 다른 일들을 하지 않는다는 가정 하에서만 큰 프로그램을 작성하라.
- 코드크기와 내부적 복잡도가 커지게 되면 그만큼 유지 보수가 어렵다.
- 투명성의 규칙 : 프로그램을 검사하고 디버깅하기 좋도록 투명하게 작성하라.
- 투명하다고 하는 것은 프로그램을 보고 한눈에 무슨 일을 어떻게 하는지 파악할 수 있다는 뜻이다.
- 발견가능성이란 프로그램이 모니터링 기능을 가지고 있어서 내부 상태를 보여 줄 수 있음을 뜻한다.
- 프로그램이 생각대로 올바르게 돌아가는 것을 보여주고, 다른 프로그램에서 사용하기 쉽도록 인터페이스를 단순하게 만드는 것이다.
- 강건함의 규칙 : 강건함은 투명성과 단순함으로부터 나온다.
- 보통의 상태뿐 아니라 설계자의 가정에 어긋나는 상황에서도 잘 수행된다는 것을 뜻한다.
- 프로그램이 대책 없는 마구잡이식 입력을 견디게 만드는 것도 중요하다.
- 소프트웨어가 '투명하다'면, 대강 프로그램이 어떻게 돌아가는지를 알 수 있다.
- 프로그램의 돌아가는 모양이 인간의 머리로 충분히 납득할 수 있게 짜여졌다면 '단순하다'고 말할 수 있다.
- 표현의 규칙 : 모든 지식을 데이터로 감싸게 하라. 프로그램 로직은 그만큼 간결해진다.
- 프로그램 복잡도와 자료구조 복잡도 사이에서 고민해야 한다면 후자를 선택해야 한다.
- 디자인을 전개할 때 복잡함을 데이터로 미룰 수 없는지를 항상 찾아봐야 한다.
- 데이터는 모든 것을 좌우한다. 적절한 자료구조를 선택하고 설계하면 알고리즘은 스스로 자명함을 보여준다.
- 프로그램 중심에는 알고리즘이 아니라 자료 구조가 있다.
- 예외적 상황 최소화의 법칙 : 인터페이스 디자인에서는 뜻밖의 것을 최소화하라.
- 사용하기 쉬운 프로그램이란 사용하려고 할 때 뭔가 새로운 것을 배우지 않아도 되는 프로그램이다.
- 전통에 귀를 기울여서 전통을 배우는 시간을 절약할 수 있도록 도와줘야 한다.
- 무언의 법칙 : 프로그램은 중요한 메시지만 출력해야 한다.
- 잘 설계된 프로그램은 사용자의 관심과 주의를 소중하게 여겨서 되도록 꼭 필요한 경우에만 시선을 끈다.
- 중요한 정보들이 프로그램 내부의 동작을 장황하게 설명하는 메시지들 사이에 묻혀버리게 해선 안된다.
- 정정의 규칙 : 에러를 수습할 수 있으면 그렇게 하라. 하지만 실패할 수 밖에 없다면, 되도록 빨리 단념하라.
- "받아들임에 있어 자유롭고, 보냄에 있어 신중하라." - 잘못된 입력이 있어도 다른 프로그램들과 함께 말끔하게 동작할 수 있는 프로그램을 만들어야 한다.
- 경제성의 규칙 : 프로그래머의 시간은 컴퓨터의 시간보다 소중하다.
- 기계들에게 프로그래밍의 저수준 작업의 처리 방법을 알려준다.
- 자동화의 규칙 : 손으로 코딩하지 않도록 하라. 프로그램을 만드는 프로그램을 만들어라.
- 코드 생성기는 에러를 발생하기 쉬운 부분을 자동화하기 위해 많이 사용된다.(파서와 랙서 생성기)
- 작성해야 하는 프로그램의 명세가 간결해질수록, 그것을 올바르게 설계할 가능성이 높아진다.
- 최적화의 규칙 : 먼저 프로토타입을 만들어라. 최적화 이전에 돌아가는 버전을 만들어라.
- "기능의 90%를 구현하고 잘 돌아가는 편이 100%를 구현했지만 동작하지 않는 것보다 낫다."
- 프로토타입을 먼저 하는 것이 최적화 범위를 고민하는 데 시간을 뺏기지 않고 고통을 털 수 있다.
- 병목지점을 찾지 않고 최적화를 감행하는 것은 설계를 망치는 길이다.
- 힘든 디버깅에 필요한 시간보다 리소스들이 허락하는 범위 내에서의 최적화가 훨씬 이득이 된다.
- "우선 돌아가도록 만들어라. 이후에 빨리 돌아가게 만들어라."
- "실행되게 하라. 그리고 올바르게 돌아가도록 만들라. 그 다음에는 빨리 실행하도록 만들어라."
- 원래의 설계에 충실하도록 최적화하지 않은 구현을 한 후 가장 높은 성능을 이끌어낼 수 있는 부분을 찾아야 한다.
- 다양성의 규칙 : "왕도"는 없다.
- 가장 훌륭한 소프트웨어일지라도 원래 설계자가 고안했던 범위 안에서 돌아가게 마련이다.
- 확장성의 규칙 : 미래를 위한 설계를 하라. 그 때는 곧 들이닥칠 것이다.
- 호환성을 위해 데이터 포맷과 코드에 여분을 두도록 해라.
- 프로토콜이나 파일 포맷을 설계할 때에는 반드시 스스로 확장 가능하도록 만들어야 한다.
- 새로운 기능을 쉽게 추가할 수 있는 구조로 만들어야 한다.
결론
UNIX는 KISS 이론을 위한 최상의 환경이다.
Keep It Simple, Stupid!
UNIX적 전통을 똑바로 실천하려면 마음을 가다듬고 조심스레 즐겨라. 기꺼이 탐구할 자세를 가져라.
참고자료
- Art of UNIX Programming - 1장
이 글은 스프링노트에서 작성되었습니다.
