당연하게도, 유지해야할 문맥의 크기가 작으면 작을수록 우리는 더욱 유연해질 수 있다.
지금 그대의 편집기에 열려져 있는 파일의 개수가 몇개인지 확인해보라. 4개가 넘어가는가? 너무 많다. 2~3개 정도로 유지할 것을 추천한다.
한번에 한 Task만 처리할 수 있게 최소한의 파일만 열어놓도록 하자. 그렇지 않으면 이것도 해야하고 저것도 해야하고.. 자꾸 새로운 시각정보들이 여러분의 뇌에게 잦은 cs를 발생시켜 업무 효율이 떨어질 것이다. 하나의 Task가 끝났으면 Cmd-Shift-W로 열린 모든 파일을 닫아버리자.
요즘 컴퓨터는 무척 뛰어나서 초당 cs가 4,000번씩 발생하더라도 서버 로드가 0.3이 채 안된다. 그러나 당신의 뇌는 기껏해야 초당 100회도 견뎌내지 못한다 (근거는 없습니다. 죄송 -_-). 유지해야할 문맥을 최소한으로 줄이는 것이 상책이다.
사람이 컴퓨터보다 뛰어난 능력이 있다면 추상화 능력이다. 프로세싱 능력이 떨어지는 대신 최소한의 정보만을 가지고 어떤 의미를 도출하는 추상화 능력 말이다. 인간이 잘못된 추상화 과정을 많이 저지르긴 하지만 (편견, 오해 등등) 누구나 특정 수준 이상의 추상화 능력을 발휘하며 살아간다. 아마 인간의 프로세싱 속도가 떨어지는 것을 커버하기 위해 설계된 부분이 아닐까!
내가 생각하기에 인간이 돌리는 thread stack size는 별로 깊지 않은 듯 하다.
한동안 문맥변환 비용을 어떻게 줄여야 하나.. 고민에 고민을 거듭했던 적이 있다. 오랫동안 고민했음에도 불구하고 딱히 만족스런 결과를 얻지 못했다. 왜냐하면 문맥변환에는 빌어먹을 '의지력'이 필요하므로 자동화할 수 없고 결국 예측할 수도 없기 때문이다. 결국 유지해야하는 Context를 줄였다.
머리속에 유지해야하는 Context를 줄일 수 없다면?
데이터의 값을 저장하지 말고, 레퍼런스만 저장하면 된다. 그렇다고 레퍼런스 변수들을 문맥 클래스에 줄줄 선언해놓으면 문맥을 들여다 볼때마다 변수명이 보여서 그대의 정신을 마비시킬지도 모른다. 그러니, 적절히 Set이나 Map에 넣어놓도록 하자. 요즘 세상은 인덱싱 능력이 뛰어난 툴들이 너무나도 많다. 단, 도구들을 사용하기로 결심했다면 완전히 신뢰하도록 하자. 신뢰하지 않으면 peek/check 비용이 높아져서 결국 생산성이 떨어지기 때문이다.
끝.