참고

5장 내용은 http://www.hanbit.co.kr/web/example/1594/progimagine_chapter5.pdf 에

인상 깊은 단락

페이지 표기는 이북 기준

p193

‘가상화의 시대’ 단락

충분히 무르익은 기술은 눈에 보이지 않게 된다는 아서 클라크(Arthur C. Clarke)의 말처럼 컴퓨터의 물리적 존재는 점점 우리의 눈앞에서 사라지고 있다.

p219

‘서비스 중심 아키텍처(SOA)에 대한 소고(小考)’ 단락

현대인의 지식보고인 위키피디어에서 SOA의 사전적 의미를 찾아보면 설명의 첫 문장은 SOA가 아무런 실체적 의미가 없다는 사실을 그대로 드러내고 있다. “There is no widely-agreed upon definition of service-oriented architecture other than its literal translation that it is an architecture that relies on service-orientation as its fundamental design principle. (그것의 근본적인 디자인 원리가 서비스를 중심으로 하고 있다는 문자그대로의 의미를 제외하면 서비스 중심 아키텍처의 정의에 대한 일반적인 합의는 존재하지 않는다.)”

p223

SOA에 대한 BT 경영진의 의지가 어느 정도로 확고한가 하면 그들은 회사 내부의 컴퓨터 시스템이 SOA의 방식에 맞도록 구현되면 연말 보너스를 미리 앞당겨서 주고, 만약 SOA에 어긋나는 방식으로 구현되면 연말 보너스를 삭감할 정도다.

p225

SOA에서 말하는 원리는 60, 70년대에 복잡하게 얽힌 소프트웨어 프로그램의 구조를 중복을 피하며 이해하기 쉽고, 관리하기 편하게 만들고자 노력하던 사상과 거의 동일한 맥락을 가지고 있다. 그래서 SOA를 비판하는 사람 중에는 서비스 중심 아키텍처가 1968년에 래리 콘스탄틴(Larry Constantine) 등이 주장했던 모듈러 프로그래밍, 혹은 80년대 주목을 끌었던 이벤트 중심 디자인(event oriented design)의 재판이라고 말하기도 한다.

p282

‘인기 프로그래밍 언어 50’ 단락

이 글을 읽는 사람 중에서 비주얼베이식을 사용하는 사람이 있다면 미안한 이야기가 되겠지만, 프로그래머 사이에서 비주얼베이식은 엄밀한 의미에서 프로그래밍 언어로 간주되지 않는다. 그렇기 때문에 비주얼베이식이 꾸준히 상위권에 머무르고 있는 현상은 다소 의외다. 미국에서 대학원을 다니던 시절에 잠깐 용돈을 벌기 위해서 심리학과 교수의 ‘인터뷰 자료 수집 프로그램’을 비주얼베이식으로 작성해준 적이 있는데, 내가 만들어 놓은 프로그램을 보고 심리학과 학생이 비슷한 프로그램을 금방 작성했던 것이 기억난다.

p385

‘유닛테스트의 즐거움’ 단락

시간이 부족하다는 변명과 유닛테스트라는 개념에 대한 혼동은 확실히 취향의 문제가 아니라 수준의 문제이다.

p388

작성하는 것은 실제 기능을 구현하는 것보다 더 재미있었다. 일단 맛을 들이고 나면 정말 그렇다. 유닛테스트 작성하는 것이 습관이 된 사람들은 유닛테스트의 옷을 입지 않은 벌거숭이 코드를 작성하는 것이 불안하게 느껴진다. 유닛테스트에 중독이 되었기 때문이다. 하지만 그것은 건강하고 유용한 중독이다. 이 달콤한 중독의 맛을 아직 모르는 사람은 안타깝게도 프로그래밍의 맛을 반밖에 모르는 사람이다.

p420

‘객체지향, 유닛테스트, 리팩토링, 그리고 소프트웨어의 총체적인 인식’ 단락

나는 이것을 (테스트 코드를 작성하는 것을) 단점이라고 보지 않는다. 나는 리팩토링을 수행하는 과정이 아니더라도 좋은 테스트를 작성하는 것이 나의 프로그래밍 속도를 놀라울 정도로 향상시키는 것을 발견했다. 이 사실은 나를 놀라게 만들었고, 대다수 프로그래머의 직관에 어긋나는 것이 사실이다.

p448

‘버그 이야기’ 단락

양산하는 것은 피할 수 없는 운명이다. 오죽했으면 멀티 쓰레드 코드에서 발생하는 버그에 시달리던 TheServerSide의 편집인인 디온 알메어(Dion Almaer)는 “소프트웨어가 정상적으로 작동하는 것은 순전히 우연의 소치이다"라고 말했을 정도이다.

p485

‘코드의 웃음을 빼앗아가는 리펑토링(Refuctoring)’ 단락

한편 팀의 분위기가 개방적이고, 사람들끼리 선의의 경쟁을 펼치며, 지적인 욕구로 팽배한 곳에서는 고먼의 공식이 정반대로 적용된다. 어느 사람이 작성한 코드를 다른 사람이 쉽게 이해할 수 있으면 그 사람의 실력은 그만큼 인정을 받고, 반대의 경우는 ‘직업 안정도’가 높아지기는커녕 사람들의 불만을 불러일으키는 것이다.

‘유지보수가 어려운 코드를 만드는법’ 책의 내용과 연관지어서 생각해보면 좋을듯..