josephjang

The Java Programming Language, 4th Edition, by Ken Arnold, James Gosling, David Holmes

Java를 처음 쓰기 시작한 것은 대학교 시절의 숙제나 프로젝트들을 통해서였다. 기억이 나지 않는 과목에서 applet을 만든 (아마도 지금까지도, 앞으로도 applet에 대한 유일한) 경험, Software Engineering 과목에서의 UML로 모델링하고 그것을 구현하는 프로젝트 (도메인은 Parking Lot이었던 걸로 기억한다), Software Project 과목에서의 웹 애플리케이션 경험을 제외하고는 Java를 사용해 본 것이 전무하다.  사실, Java 부문이 워낙 넓고 배울 내용이 방대하기 때문에, 그동안 습득해야할 기술 목록에서 고의적으로 빼놓은 상태였으며, 그동안 Java에 대한 나의 인상은 성능에 대한 미신과 높은 수준의 추상화에 대한 부러움 같은 것들이 섞여있었다고 볼 수 있다. 그러던 중, 작년 2월 경 입사한 회사 ‘첫눈’에서 시작한 프로젝트에 참여하게 되었고, 초기 셋업 과정에서 Java를 사용하기로 결정되었기 때문에 (당시까지는 나는 C++ 프로그래머였다), Java 프로그래머로서의 이력을 시작하게 되었다.

Java에 대한 경험은 있긴 하나 일천한, 어설픈 초보의 상태에서 가장 필요한 것은 언어와 표준 라이브러리에 대한 정확한 지식들이다. Head First Java가 Java 입문서로는 상당히 유명하지만, 내게 ‘입문’이 필요한 상태는 아니라고 생각했고, 입문서는 표준 명세를 대체할만한 엄격한 언어 정의를 포함하고 있지 않기 때문에 선택 목록에서 제외되었고, 역시 유명한 Thinking in Java 4th Edition의 경우에는 Java 5.0을 반영하는 새 판이 나올거라는 소식은 알고 있었으나, 당시에 출판되지 않았던 상태라고 생각하고 있었기 때문에 (지금 보면, 2006년 2월 10일에 출판된 것으로 보인다.), Java 프로그래밍 언어에 관한 가장 권위있는 저자들이 쓴 이 책을 선택하게 되었다.

책의 내용은 크게 문법과 표준 라이브러리의 두가지 부분으로 나뉘는데, Java 5.0의 문법을 대부분 커버하고 있으나, 표준 라이브러리는 핵심적인 부분(Collection과 Stream)에 집중하고 있다. 따라서, Java의 표준 라이브러리에 대해서 책을 통해서 공부하고 싶다면, 다른 책을 보아야할 것이다.

평이하게 쓰여졌으며, 중요한 부분에는 항상 예제를 덧붙여서 설명하고 있어서, 그 문법이나 라이브러리가 어떠한 용법을 가지고 있는지도 알 수 있기 때문에, 어느 정도는 잘 쓰여진 책이라고 평할 수 있을 것 같다. 어느 정도 Java에 대해 알고 있는 상태에서 그 예제를 설명하는 부분을 보면 상당히 지루하기 때문에, skimming할 것을 권장한다. 책의 성격상 상대적으로 덜 중요한 내용들에 대한 설명들도 많이 들어가기 때문에 입문서로서는 이 책은 약간 무거울 것 같다. (살짝 본 것 뿐이지만, 입문서로는 Java 언어의 중요한 사항들만 쉽게 설명하고 있는 Head First Java를 추천한다.) 특히, Stream과 Collection을 다 읽고 난 후 ‘기타’ 성격에 해당하는 라이브러리 부분을 읽을 때는 너무 지루해져서, 다른 책 (Effective Java)을 읽고 나서야, 다시 이 책을 잡을 수 있었다.

한편, 기대했던대로 문법의 각 요소들에 대한 정확한 semantic과 이 책이 커버하고 있는 라이브러리 부분에 대해서는 완전하게 설명하고 있기 때문에, Java 프로그래밍 언어에 대한 지식에 어느 정도 자신감이 생겼다. 당연히 옆에다 두고 Java 문법 레퍼런스로도 사용할 수 있다. 라이브러리를 레퍼런스 해야할 경우에는, (Java 개발자라면 누구나 알다시피) 사실 Sun의 문서화가 너무나 잘되어있으므로, 그것을 참조하는 것이 효율적이고 더 정확할 것이다.

전체적으로 Java의 The C++ Programming Language라고 해도 손색은 없을 것 같다. The Java Programming Language는 serious한 Java 개발자라면 반드시 읽고 넘어가야할 책이다.

2004년 즈음에 The Joel Test를 처음 알게되고 나서부터 daily build의 중요성을 깨닫게되었다. 만들어진 지 무려 6년이 넘은 테스트지만, 여전히 현실은 암울하다. 다음은 현재 일하고 있는 팀의 Joel Test 결과.

1. Do you use source control? yes.
2. Can you make a build in one step? yes.
3. Do you make daily builds? yes.
4. Do you have a bug database? no.
5. Do you fix bugs before writing new code? no.
6. Do you have an up-to-date schedule? no. (barely)
7. Do you have a spec? no. (barely)
8. Do programmers have quiet working conditions? yes. (could be no)
9. Do you use the best tools money can buy? no.
10. Do you have testers? no.
11. Do new candidates write code during their interview? no.
12. Do you do hallway usability testing? no.

—

4 points

그나마 2번과 3번 항목은 비공식적으로 혼자서 작업해놓은 결과다. 그 전엔 2점이었단 얘기.

강문식 군이랑 얘기하다보니, ‘지금 Joel Test를 보니 찌질하다’는 평을 해주었다. 특히 Team Room 환경에서 근무하고 있는 그가 보기에 ‘quiet working condition’은 그렇게 보일 수 밖에. 내가 보기에도 Agile method를 적용하고 있는 환경 하에서는 몇가지 항목들이 상치될 수도 있을 것 같다. 또한 우리 팀처럼 시스템 프로그래밍 계열의 프로덕트를 만들고 있는 경우에는 ‘Usability testing’ 같은 것들은 불필요하거나 중요하지 않을 수도 있다고 생각된다. 게다가, 10점 얻기도 너무나 힘든 현실을 보면, Joel Test 자체가 찌질하다고 얘기하고 싶어지는 점도 있다. 하지만, Joel Test의 항목 하나하나를 살펴보면 여전히 중요하교 유효한 것들이다. 찌질하다고 얘기할 수 있으려면, 기본은 하고나서의 이야기다. 한번이라도, 내가 처음으로 daily build를 만들지 않아도 되는 팀에 가보고 싶다.

2005년 즈음의 ‘책 판매량으로 보는 기술 산업 동향‘이라는 글을 기억하고 있을지 모르겠다. 갑자기 생각나서 검색해보니, Tim O’Reilly가 쓴 2006년의 ‘Programming Language Trends‘라는 글을 찾을 수 있었다.