처음 봤을 때, 그냥 괜찮은 디자인처럼 보였다. 나는 Ctrl+L로 주소창을 열고 URL 주소를 타이핑해서 사이트를 찾아가기 때문에, 저런 인터페이스는 그냥 예쁜 인터페이스에 불과했다. 키보드에 얹은 손을 마우스로 다시 옮기기도 귀찮아서 키보드로 할 수 있는 건 웬만하면 다 키보드로 하는 편이다.
최근 이 인터페이스가 정말 대단하다는 걸 알게 됐다. 아내가 웹 서핑을 하는 것을 옆에서 지켜보다가… 카페 때문에 주로 ‘다음’을 사용하는데, 어떤 사이트건 ‘다음’을 검색어로 넣어서 검색 결과를 클릭해서 이동하더라. (몰랐는데, 구글, 네이버에 ‘다음’ 검색어가 꽤 상위 랭크다.) 혹은 히스토리를 볼 수 있는 주소창 옆에 있는 버튼을 눌러서 ‘www.daum.net’을 찾아 이동한다.
요즘 프로그램 대부분이 업데이트가 있는지 감시하는 로직을 프로그램 코드 안에 심어 놓는다. 사용자들이 사용하는 프로그램을 최신 버전으로 갱신하는건 개발자에게 너무나 중요하기 때문이다. 치명적인 버그를 고친 버전을 업데이트 하지 않아 프로그램에 실망해 떠나기도 하고 프로그램 평판 또한 나빠지기 때문에 최신 버전을 알려주고 다운로드 버튼을 제공하는 게 이제 기본이 됐다.
버그가 수정되거나 새로운 기능이 들어간 업데이트를 알려주는 건 좋은데, 프로그램 실행할 때 업데이트를 하는 게 너무 귀찮다. 빨리 프로그램을 사용해야 하니깐~ 그래서 난 보통 나중에 업데이트 하기 버튼을 누르는데, 최근 페인트 닷넷에서 ‘프로그램을 끌 때 업데이트하기‘란 기막힌 옵션을 봤다. 어휴~ 이 생각을 못했구나.
사용자를 진짜 배려한 업데이트 옵션이다.
크~ CPU를 가정부로 이해한다니! 생각지도 못한 비유. 멋지다. 적절한 비유와 그림을 많이 써서 이해가 잘됐다.
파이프라인부터 하이퍼스레딩까지 CPU를 이해하는데 기초가 되는 내용부터 차근차근 잘 설명해준다. ‘Fetch –> Decode –> Execute –> Write Back’으로 진행되는 기초적인 명령 처리 파이프라인. 한 프로세서 안에서 명령어를 병렬로 실행하는 슈퍼 스칼라(superscalar). 비순차적 명령어 처리(Out-of-order execution, OoOE). 프로그램 카운터(program counter, PC)를 점프시키는 분기가 있을 때, 순서대로 파이프라인에 들어온 명령어들을 버려야 하는 경우가 발생한다. 이런 낭비를 방지하기 위한 분기 예측(branch prediction). 스레드 두 개를 코어 하나에서 실행시키고 버스 2개를 제공해 듀얼 프로세스처럼 사용하게 하는 하이퍼스레딩(Hyper-Threading, HTT). 이거 한동안 안 써서 죽은 기술인 줄 알았는데, 네할렘부터 다시 들어갔음.
코드 리뷰를 하는 이유는 간단하다. 결함을 늦게 발견할수록 수정하는 비용이 증가하기 마련인데, 코드 인스펙션과 리뷰는 결함을 초기에 발견해서 수정하는 비용을 낮추기 때문이다.
‘Four ways to a Practical Code Review 번역‘에서 4가지 코드 리뷰 방법을 잘 설명하고 있다. 이 글을 읽어보니 얼마 되지 않은 코드 리뷰 경험은 다 어깨너머 리뷰(Over-the-shoulder)였다. 확실히 문서에 있는 단점들을 그대로 다 느꼈는데, 가장 큰 단점은 실제 결함이 제대로 수정되었는지 검증하기 어렵고 리뷰 진행이 소스 코드를 짠 사람에 좌우된다는 거다. 짝 프로그래밍(Pair Programming)이 가장 확실한 코드 리뷰가 되겠지만, 너무 많은 선행투자 시간 때문에 엄두를 못 내고 있다. 물론 이런 걸 결정할 권한도 없다. 그래서 가장 현실적인 답은 코드 리뷰를 지원하는 툴을 사용하는 게 아닐까 싶다.
종종 어떤 XPers들은 많은 디자인 활동과 디자인 패턴을 쓸모없다고 한다. 또 어떤 XP 비방자들은 XP를 디자인도 없는 짜보고 고치는(code and fix) 개발방식으로 회귀라고 말한다. 마틴 파울러(Martin Fowler)가 “어휴 둘 다 오해하고 자빠졌네.”라며 교통정리를 한 글이다. 자신을 소심한 XPer라고 말하며 약간 조심스러운 접근도 있지만 하나하나 항목들을 집으면서 XP에 대한 오해를 풀어주고 있다.
일단 XP가 어떤 건지 간략하게 정리하는 게 필요하다. XP가 계획된 디자인이 아니라 진화적 디자인을 지지하는 게 가장 핵심이다. 이렇게 되기 위해서는 뒤로 갈수록 소프트웨어를 변경하는 데 드는 비용이 급격하게 올라가는 걸 완만하게 만드는 게 꼭 필요해진다. 완만하게 만들지 못했다면 계속 진화적으로 디자인해야 하는데 비용이 급격히 증가하니 완전 쫑나는거. 이렇게 완만하게 만드는 게 XP이고 이 완만함을 XP가 사용하는 거다.
“이 줄에 버그가 있다”
“이 포인터가 널이라는 점이 버그이다”
“프로그램이 죽었다. 이것은 버그이다”
- 프로그램은 왜 실패하는가? p26
버그(bug)라는 말을 많이 사용하는데, 위에 인용한 말처럼 원인과 증상을 뭉뜽그려 말하곤 한다. 또, 프로그래머가 무조건 잘못한 일이 대부분인데 그 잘못을 묽게 만들기도 한다.
계산한 값을 메모리에 저장해서 여러 번 같은 값 계산을 피하는 최적화 기법을 메모이제이션(memoization)이라고 한다. 실행 속도와 공간을 바꾸는 가장 기초적인 기법이기도 하다. 실수로 메모리제이션이라고 하기도 하는데 메모이제이션이 정확한 용어이다.
이 용어를 몰랐을 때는 데이터나 값을 미리 복사해 놓거나 계산해 놓은 임시 장소를 뜻하는 캐시(cache)에 저장하는 동작, 즉 캐싱(caching)이란 용어를 쓰곤 했다. 데이터를 미리 계산해서 임시 장소인 메모리에 저장해놓는 동작이라 캐싱이란 용어도 틀린 말은 아니다. 하지만, 딱 가리키는 용어인 메모이제이션이 있으니 이걸 쓰는 게 맞겠지.
메모이제이션을 사용하는 피보나치 수열을 계산하는 코드이다. 역시 예를 들때는 피보나치 수가 최고지.. 암~
// 안전 코드를 제외한 간단한 코드 조각
// 메모리 초기화.
std::vector<int> memo;
const static int NOT_VALID = -1;
const int MEMO_MAX = 10000;
std::fill( memo.begin(), memo.end(), NOT_VALID );
memo.resize( MEMO_MAX );
// 피보나치 초기화
memo[0] = 0;
memo[1] = 1;
int fib( int n )
{
if( memo[n] != NOT_VALID ) return memo[n];
memo[n] = fib(n-1) + fib(n-2); // memoization
return memo[n];
}
한때 망할 ActiveX를 설치하려고 하면 뜨는 노란색의 바(bar) 이름이 뭔지 몰라서 검색할 때 한참 헤맸었다. “인터넷 익스플로러에서 ActiveX 설치하려고 할 때 나오는 노란색 바(bar)가 뭐죠?” 나중에야 이 녀석을 information bar 라고 부른다는 걸 알았다.
참 용어를 모르면 고생이다. 검색할 때도 검색 키워드를 제대로 모르니 제대로 된 답을 찾기가 어렵고 또한 사람과 이야기 할 때 한방에 바로 갈 수 있는 것을 돌아서 가야 한다. 이거 분명히 모아서 정리해놓은 게 있지 싶어서 검색해보니 바로 Controls – MSDN가 걸린다. XP 기준으로 정리한 자료를 찾다가 포기하고 이참에 비스타에서 추가된 컴포넌트 이름을 정리하는 게 좋겠다 싶어서 한번 살펴봤다.
암호 칠때 종종 보는 녀석으로 Balloons 라고 부른다. 치명적인 오류가 났을 때 이런 무시해도 좋게 생긴 컨트롤로 알려주면 안 된다. 좀 친절하게 알려주자 할 때 사용하면 좋을 컨트롤.
predicate 발음듣기 [미] [prédikət]
1. 【문법】 술부, 술어 (cf. SUBJECT)
4. 【컴퓨터】 술어
- 구글 사전
술어[述語]
[논리]논리의 판단·명제에서, 주사(主辭)에 대하여 긍정 또는 부정의 입언(立言)을 하는 개념.
[언어] 같은 말 : 서술어.
- 다음 사전
확실한 기억은 아니지만 아마 이 STL을 공부하면서 이 단어를 처음 접했던 것 같다. 술어라는 단어 또한 익숙하지 않아서 predicate를 찾고 다시 술어라는 단어를 찾아봤던 기억이 난다. 술어의 뜻풀이 또한 어렵게 되어 있어 어떤 뜻인지 바로 알기 어려웠다.
프로그래밍 언어에서 사용하는 predicate는 서술어라기 보다는 논리에서 사용하는 긍정 또는 부정의 입언을 하는 개념으로 사용한다. true / false를 판단할 수 있는 식이나 boolean 값을 리턴하는 함수를 술어(predicate)라고 한다.
CQS는 간단하게 설명하면 멤버 변수를 변경하는 동작과 멤버 변수 값을 반환하는 동작 중 하나의 동작으로만 멤버 함수를 구현하는 원칙이다. 양다리는 금지.
public:
int IncreaseAndReturnCount() { ++m_count; return m_count; }
private:
int m_count;
IncreateAndRetrunCount()는 m_count의 값을 변경하고 m_count의 값을 반환한다. 이렇게 양다리를 걸치는 경우 CQS 원칙을 어기게 된다.