Software Creativity 2.0

그날 그날 기분에 따라 쉽게 환호하고 쉽게 무시하기도 하는 성격이긴 하지만,

Software Creativity 2.0

아휴 버릴 게 없다. 버릴 게 없어. 

Effective Java 1판 이후로 이렇게 임팩트 넘치는 책을 읽어본 적이 없다. 

저자의 의도를 떠나서, 이 책을 읽다보면 여러가지 side effect (긍정적인) 도 얻을 수 있다. 내가 얻은 가장 큰 이점은 이 책의 내용들 중 일부분이 내가 프로그래밍할 때 피하지 못하고 견뎌내기만 해야했었던 많은 부정적인 느낌들을 말끔하게 패치해줬다는 데에 있다. 

이렇게 진지한 측면을 포함하고 있으면서도, 책을 읽는 중간중간 웃고 울고.. 

이 책을 구매토록 인도해주신 gEEkInsIdE님의 포스팅에게 무한한 감사를. 

인용구 몇개 건질 수 있지 않을까 하며 이 포스트를 여신 분들을 위해 레퍼런스 아티클 몇개와 인용구 몇개를 준비한다. 

비자아적 프로그래밍 (ego-less programming) 십계명

 우수한 설계자는 하향식이 아니라 편의적으로 설계한다 하지만 설계자가 아닌 사람은 설계 과정에서 창의적이고 편의적으로 넘나드는 사고의 흐름을 이해하지 못한다. 그래서 우리는 설계를 하향식으로 위조해서 기술한다. 문서를 읽는 사람에게 설계를 이해시키는 유일한 방법이기 때문이다. 

 문제는 고 파루틴 문제가 있고 저 파루틴 문제가 있다. 해법은 고 파루틴 해법이 잇고 저 파루틴 해법이 있다. 사람은 고 파루틴 사람이 있고 저 파루틴 사람이 있다. 마지막으로, 프로젝트도 고 파루틴 프로젝트가 있고 저 파루틴 프로젝트가 있다. 

"내 말은 정형주의가 우리의 가능성을 제한한다는 뜻이다. 우리는 정형 기법을 넘어서 조직 안에서 그리고 소프트웨어 설계 안에서 서로 소통하는 방법을 익혀야 한다. 불분명하고, 부정확하고, 정형화가 불가능한 접근 방식, 즉 우리가 일상적으로 활용하는 접근 방식에 관심을 기울일 때가 왔다." 

Better Is The Enemy of the Good Enough

흔히 복잡성과 모호성을 능숙하게 처리하는 인물은 약자로 여겨지는 반면 흑백논리를 강하게 펼치는 인물은 강자로 여겨진다는 사실이 흥미롭다고 테트락은 지적한다. 물론 그는 오히려 반대라고 주장한다. 

내가 아는 한 프로젝트가 성공하는 방법은 단 하나다. 능력 있는 팀장과 팀원을 확보해서 문제를 정확히 이해하게 만든다. 문제를 명세할 필요는 없다. 별도로 시나리오를 작성할 필요도 없다. 문제를 해결할 당사자들이 요구사항을 정확히 이해하면 그만이다. - Frosch 1969 

다시 말하겠다. 중요하니 집중하기 바란다. 상위 CASE 도구 대다수는 표현 활동을 도와주는 도구일 뿐 표현을 생성하는 지적 활동을 도와주는 도구가 아니다. 두 가지는 전혀 다른 활동이다. 하나는 문제를 이해하고 설계를 수행하는 활동으로, 상당히 지적이다. 다른 하나는 도표를 그리고 명세와 설계를 저장하는 활동으로, 대체로 사무적이다. 

학계 사람들에게는 흥미를 추구하는 태도가 윤리다. 업계 사람들에게는 유용성을 추구하는 태도가 윤리다. 

그리스인은 작성할 문서를 최소로 줄이고, 로마인은 최대로 늘이며, 야만인은 문서를 안 만든다는 사실에 자부심을 느낀다.

흡족하다.