단순함을 쉽게 만들기 (2011)

단순함은 요소가 서로 얽히지 않은 상태이고, 쉬움은 접근성·익숙함·개인의 역량에 따라 달라짐 — 기술을 선택할 때는 작성 편의보다 실행하고 유지보수할 소프트웨어의 구조를 평가해야 함 인간이 동시에 이해할 수 있는 요소는 제한적이므로 복잡성은 이해·변경·디버깅 능력을 제한함 — 테스트와 타입 검사는 안전망이지만 프로그램을 이해하는 일을 대신하지 못함 상태·객체·상속·조건 분기처럼 익숙한 도구도 독립적일 수 있는 개념들을 결합함 — 값·함수·데이터·독립적으로 연결 가능한 다형성·큐·선언적 처리로 같은 수준의 시스템을 더 단순하게 만들 수 있음 모듈화나 캡슐화만으로는 단순해지지 않음 — 작은 추상화와 하위 구성요소를 만들고, 무엇을·누가·어떻게·언제·어디서·왜 수행하는지를 분리해야 함 단순함에는 초기에 생각하고 분리하는 작업과 지속적인 주의가 필요함 — 구성요소 수가 늘더라도 얽힘이 줄면 변경의 독립성과 유연성을 확보할 수 있음 단순함과 쉬움은 다른 기준임 “단순함은 신뢰성의 전제조건”이라는 Dijkstra의 명제처럼, 좋은 시스템을 만들려면 단순한 시스템을 만들어야 함 단순함(simple) 의 어원은 하나의 접힘·꼬임을 뜻하며, 복잡함(complex)은 여러 요소가 함께 꼬이거나 접힌 상태를 뜻함 소프트웨어에서는 하나의 역할·작업·목표·개념·문제 차원에 집중하고, 다른 요소와 뒤섞이지 않는지를 살펴야 함 구성요소가 하나뿐이거나 인터페이스의 연산이 하나뿐이어야 한다는 뜻은 아님 중요한 것은 개수가 아니라 얽힘의 유무이므로, 단순함은 구조를 살펴 판단할 수 있는 객관적 기준임 쉬움(easy) 은 가까움으로 이해할 수 있으며, 무엇에 가까운지에 따라 세 가지로 나뉨 도구를 바로 얻거나 설치해 사용할 수 있는 접근성임 이미 알고 있는 지식과 기술에 가까운 익숙함임 자신의 이해 능력으로 감당할 수 있는 정도임 쉬움의 어원을 ‘가까이 놓임’과 연결하는 마지막 단계는 추정적이며, 어려움(hard)의 어원이 반대로 ‘멀리 있음’을 뜻하는 것은 아님 쉬움은 상대적이므로 반드시 ‘누구에게 쉬운가’를 물어야 함 독일어를 모른다고 독일어 자체를 읽을 수 없는 언어라 할 수 없듯, 낯선 코드를 읽지 못하는 것과 그 구조가 복잡한 것은 별개임 익숙한 것만 요구하면 기존 지식과 크게 다른 것을 배울 수 없음 익숙함을 단순함이라고 부르면 소프트웨어의 객관적 품질을 논의하기 어려워짐 작성 도구보다 그 도구가 만드는 결과물을 평가해야 함 언어 구...