프로그래밍 수련법을 퇴근길 지하철에서 휘리릭 훑어보았다. 책에 대한 전체적인 감상은 프로그래밍에 대한 전방위적인 기초를 짜임새있는 구성으로 녹여 놓인 좋은 책이란 것. 전산학 전공자가 아닌 개발자라면, 되려 파고 들어 읽어보면 짧은 시간에 이론적 기반을 튼실히 할 수 있을 것이다. 하지만, 전공자면서 개발을 업으로 삼고 있는 경우라면 반대로 정독하기는 지루한 책이다.

조만간 코드 인스펙션(Inspection)*을 해야 하는데 눈에 띄는 글귀를 우선적으로 뽑은 후에... 나름의 기억의 끈을 붙여놓고 인스펙션을 위한 체크리스트로 활용해보고자 한다. 후일 각각의 지침을 얼마나 활용했는가로 유용했는지 돌아볼 수 있을 것이다.

먼저 목록부터 선별**


아래는 자가 해석 + 기억의 끈:

1. 유효범위(Scope)***가 커지면 이름도 널리 쓰일 수 있게... 이 얼마나 FFF하고, 아름다운 규칙인가.
2. 매직넘버를 쓰면 입력이 없이 결과를 연산해내는 모듈이 만들어진다. 매직넘버를 알고 있는 사람이 다 사라진 유지보수 환경이라면...@@ 왠만하면 입력을 받게 해(Parameterization) 선언적 처리가 가능한 상황이 좋지 않겠는가? 요즘처럼 변화무쌍한 시대에... 준비를 해둬야지. 이런 코드가 Testable 하기도 하고...
3. 나쁜 코드에 대한 설명(주석)은 결국 변명이 아닐까. 변명이라.. 캬~ 내가 지었지만, 아주 적절한 표현이다.(안티 인정..^^)
5. 브레이스({) 열고 닫기 먼저 해두는 코딩법처럼, 긴 호흡으로 자원반환(close() 류)을 잊지 않도록 습관화 하자.
6. DOS 프로그램에서 징하게 많이 본 메시지이기도 한데... 시스템 연동이나 비동기 처리, 하나의 서비스에서 여러 개의 프로세스를 연속적으로 부르는 경우, 응답성이나 ACID를 보장하기 위해 고민해야 하는 문제이기도 하다.
7. 테스터의 도전 과제가 아닐까? Testable하게 짜라. 어쩌면... 하드웨어나 OS를 구성하는 시스템 소프트웨어에 천착한 매직넘버가 장구한 세월을 숙성하면 알 수 없는 오류를 양산하는 것이 아닐까?
8. 테스트 작성 가이드 만들 때 참조할만한 내용
9. 요즘 프레임워크 개발에 참여하다 보니 '프레임워크에선 어디에 캐시를 쓸 수 있을까' 하는데 생각이 미치고, 스프링 테스트 모듈에서 캐시를 사용하여 테스트 수행 속도 향상을 가져온 사례가 떠오른다.
10. Code spring-wise!


* 허걱, 티스토리 편집기에서도 Ctrl+B 단축키가 먹는구나. 나만 몰랐나... @@
** 증정 받은 책이라 고마움을 표시할 겸, 각 글귀가 쓰인 쪽수를 기록한다.
*** 유효범위라 정말 마음에 드는 번역어 선택이다.