짧은문구 Note

소프트웨어 시스템을 디자인하는 작업은 끊임없는 선택을 요구합니다.
그리고 프로그램 디자인에 있어서
-마치 인생에서도 그렇듯이 - 선택이란 참으로 어려운 작업입니다.

천재적인 코더는 보통 어린 나이에 나타나는 반면에, 천재적인 디자이너는 오랜 시간에 거쳐서 숙성되어야만
만들어진다.

디자인을 목적으로 한 라이브러리들은 미리 규졍된 라이브러리 자체의 제한 조건을 가지기보다는, 사용자가 만든 
디자인이 디자인 스스로의 제한 조건을 가지도록 만들어 주어야 한다.

때때로, 해결 방법을 전혀 찾을 수 없기 때문이 아니라, 해결책처럼 보이는 방법이 너무 많아서 문제가 된다.

클래스를 디자인하면서 발견해내지 못한 채 묻혀 버린 제약 사항들은 아무 설명 없이 코드 속에 묻혀 있는
마법상수만큼이나 치명적인 요소가 됩니다.

"서두른 낙관론은 만악의 근원이다" 하지만 "뒤늦은 비관론은 아무런 쓸모가 없다"
실행시간에 차지하는 거대한 메모리 양을 보고 비관론에 빠져버리느냐 마느냐는, 전체 프로젝트의 성패를 가리는
큰 차이점이 될수 있다.

인체를 구성하는 원자들은 이미 몇 개의 별을 걸쳐서 왔을 것이고, 수백만 개에 이르는 생물의 일부였다. 
인간이 죽고 나면 그 원소들은 흩어져서 다른 곳에서 새로운 목적으로 재활용의 길을 밟는다. 
윤회(輪廻)는 거스를 수 없는 자연계의 순환 고리다.
내가 작성한 코드도 이미 수많은 사람의 손에 걸쳐서 왔을터......,

 실전 프로젝트에서는 때때로 얼마나 비용을 저렴하게, 효과적으로 배포하느냐, 최종 사용자 들이 얼마나
쉽게 애플리케이션을 설치할 수 있느냐 그리고 추후 업데이트를 얼마나 쉽게 할수 있느냐 등의 문제가 중요하다

컨트롤(Control)을 배울 때는 원리를 이해하기보다는 구현 결과를 활용하는 방법에 치중하는 것이 나을수도 있다.

 프로그래밍을 하면서 핵심은 어떻게(HOW)코딩할 것인지 보다 어디에(WHERE)코딩할 것인가가 더 중요할때가
있습니다.구조의 흐름을 따라야하며, 원하는 결과를 얻으려면 어디에 코딩해야 할지를 아는 것이 매우 중요합니다.

 아키텍처에 모든 것을 표현하려 해서는 안된다. 빈틈없는 정교함보다 심오한 간결성(deep simplicity)이 
요구됩니다.