»
S
I
D
E
B
A
R
«
책은 어떻게 써? (첫 책을 꿈꾸는 개발자를 위한 ‘엉성한’ 집필 요령)
Jul 28th, 2015 by Wegra Lee

최근 한 지인 개발자가 책을 쓰고 싶다며 ‘일반적인 책 집필 방법 좀 알려달라’는 상당히 추상적인 질문을 던졌다.
러프한 질문이라 러프하게 답할 수밖에 없는데..
어쨌든 같은 궁금증을 가진 사람이 또 있을 듯해서 여기에도 옮겨본다.
깊은 고민 없이 휘갈겨서 허점이 많을 테니 양해를.. ㅎㅎ
질문자가 개발자라 개발자가 이해하기 쉽게 작성해 보았다.
뭐, 소프트웨어 제품 만드는 거랑 비슷하고 보시면 될 거 같아요.
  1. 시장을 분석하고(시장 규모, 트랜드, 경쟁 서적, 잠재 독자가 어떤 걸 원하는지)
  2. 컨셉을 잡고(책 주제, 독자층, 차별점)
  3. 설계를 하고(목차 잡기, 자료 조사)
  4. 구현하는 거죠(집필).
시장 분석은
  • 분야 경쟁서가 있다면 아마존 랭킹이나 예스24 판매지수 등으로 시장 크기와 트랜드를 꽤 정량적으로 알 수 있어요.
  • 경쟁서가 없다면 정성적으로 가야겠죠. 업계 기술 트랜드라거나..
컨셉 잡을 때는
  • 분야 1등을 노릴 것이냐, 차별화해서 시장을 가를 것이냐 고민해보시고,
  • 대상 독자가 초 -> 중 -> 고로 갈수록 판매량은 급격하게 떨어지니 참고하시고요.
  • 대표적인 전문서 유형으론 바이블, 레퍼런스, 따라하기, 주제별 심화 내용, 에세이 등이 있습니다.
  • 책 제목, 부제, 홍보 카피, 책 소개 문안(3~5줄 정도)도 꼭 고민해보세요. “나 이런 책을 쓰고 있다”고 남에게 이야기할 수 있을만큼 해주세요. 책의 정체성이 확립되어 이후 단계에서 등대 같은 역할을 해줄 겁니다.
설계 단계에서는
  • (시스템 워크플로 그려보기)
    대상 독자의 수준과 관심사를 고려해서 차근히 단계를 정하고
  • (필요한 모듈을 추출하고 핵심 인터페이스 정하기)
    목차는 장과 절 수준까지는 구체화하는 게 좋습니다
  • (프로토타이핑)
    각 장과 절에서 무슨 이야기를 할 지 3~5줄 내외로 요약해 보세요. 시작 문단과 끝 문단을 적어보는 것도 좋습니다.
구현 단계에서는..
  • 설계 단계에서 비워놓은 것들을 하나씩 채워야죠. ^^ 요건 요령이 너무 많고, 사람마다 현 수준이나 성향이 다양해서 짧게 정리하기엔 무리가 있습니다. case by case라 직접 쓴 원고로 편집자나 주변 글 잘 쓰는 분께 피드백 받는 게 가장 좋을 거에요.
  • 러프하게는 글쓰기 관력 책도 많고, (IT인들이 워낙 번역된 글을 많이 접해서) 역자를 위한 책도 우리글 잘 쓰기에 큰 도움이 됩니다. 개인적으론 일반 글쓰기 책보다 역자용 책이 더 좋더군요.
  • 코딩 잘하는 요령과 비슷한 거죠. <클린 코드>만 해도 550 페이지네요. ㅎㅎ
마지막으로..
집필 초보자라면 초기 단계부터 전문가와 논의를 해야 재집필하거나 노고를 헛되이하는 걸 막을 수 있습니다.
[개앞맵시] 웹 개발자편 공개
Jul 7th, 2015 by Wegra Lee

오랫만에 새로운 맵을 공개한다.

이번 [웹 개발자편]은 웹 프론트엔드쪽으로, 기획자/디자이너(퍼블리셔)/개발자를 대상으로 한다. 서버쪽은 [서버 개발자편]에서 통합해서 다루기 때문에 여기에는 따로 명시하지 않았다.

[개앞맵시]_개발자의_앞길에_맵핵_시전!_-_웹_개발자편

추천 도서와 개선 의견을 듣는 방법을 변경했다.

이메일 쓰기는 아무래도 귀찮으니 마인드맵 서비스 자체의 댓글 기능을 이용하면 된다(얼마전 새로 추가된 기능이다).

경험 삼아 개앞맵시 페북 페이지를 만들었었는데(홍보는 전혀 안 했지만), 그 사이 우리 팀 페이지(오늘도 평화로운 IT2팀)도 생겼고.. 앞으로 어찌 될른지는 모르겠다.

[개앞맵시] 개발자의 앞길에 맵핵 시전!!
Apr 27th, 2015 by Wegra Lee
출판사로 자리를 옮기면서 그렸던 ‘책으로 안내하는 개발자 로드맵’ 초기 버전이 어느 정도 공개할만 해졌다.
동료와 후배 개발자에게 개발자로서 걸어야 할 길을 다양하고 거시적인 관점에서 보여주고, 그 길을 걷기 위해 무엇이 필요한지를 알려주고 싶었다. 아무리 좋은 책이라도 단편적으로 하나씩 툭툭 던져서는 제대로 된 도움을 주기 어렵다. 군데군데 빠진 구멍이 생기고, 그다음에는 무엇이 있는지, 다른 사람들은 무엇을 보고 익혔는지 등 얼핏 생각해도 한계가 많다. 그래서 맥락과 수준에 맞는 가이드, 그때 참고할 만한 좋은 자료를 정성껏 준비해 보았다. 물론 아직 많이x3 부족하다. 솔직히 내가 생각하는 그림의 10%도 충족하지 못하지만, 굳이 모든 게 갖춰지기까지 기다릴 필요는 없을 듯하다.
우선 지금 준비된 맵은 다섯 가지다.
개발자 공통편
소프트웨어 개발자라 하면 일반적으로 거쳐야 하는 공통 주제를 담았다.
기본 이론, 언어, 설계/품질, 도구/인프라, 프로젝트 관리, 교양/에세이로 구성된다.
가장 처음 만들어져서 가장 어설프다. ㅎㅎ
개발자 일상편
일반적인 개발자가 매일같이 겪게 되는 주제를 다룬다. 큰 분류만 보면 ‘공통편’과 다소 중복되기도 하지만, 공통편이 학문적 분류에 가깝다면 일상편은 실행활에 근거한 분류로 보면 된다. 그래서 ‘육아 / 삶 / 취미’와 ‘자녀 교육’까지 챙겼다.
코딩&설계 실무, 테스트/품질, 알고리즘/문제해결, 인프라/도구, 프로젝트 관리, IT에세이/상식, 육아/삶/취미, 자녀 교육
게임 개발자편
게임 개발 직군 중 서버를 제외한 개발자를 위한 맵이다.
기획/디자인, 개발(원리/알고리즘, 그래픽스, 게임 엔진), QA/테스트, 인프라 / 도구로 구성된다.
구성에 도움을 준 진태에게 감사를~ ^^
서버 개발자편
게임/웹/소셜 서비스 등 분야를 막론한 맵이다.
서버 프로그래밍 기초, 프레임워크, 설계/품질, 인프라 구축/가상화, 관계형 데이터, NoSQL, 도구로 구성된다.
스타 저자/역자편
꾸준히 좋은 책을 내주시는 저자/역자 분들과 그분들의 책을 소개한다.
그외..(미완.. coming someday)
전체 맵을 보려면 계정 주소로 바로 들어가도 된다. 종종 들어오다 보면 새로운 맵들이 추가되어 있을 것이다.
모든 맵은 아래 그림과 같은 미니맵을 포함하며, 각 항목의 화살표를 누르면 해당 맵으로 이동한다.
각 책의 제목 옆에 있는 아이콘은 각각 ‘상세 설명’, ‘예스24 링크(종이책)’ 혹은 ‘한빛미디어 링크(전자책)’, ‘상세 이미지’이다. 종종 저자 강의나 데모 동영상, 유용한 팟캐스트도 보게 될 것이다.
우선 여기까지…
앞으로는 사람들의 피드백을 들어가며 차근히 업데이트할 예정이다.

[업데이트] 회사에 묶인 몸이라 눈치 때문에 우리 회사 책만으로 구성했는데, 사장님이 ‘다른 회사 책도 넣는 게 좋지 않나?’며 지나가심.. 조만간 봉인 해제 예정!!

시중에 아무리 좋은 책이 나와도 지금처럼 단편적으로 하나씩 툭툭 던져서는 제대로 된 도움을 주기 어렵다. 군데군데 빠진 구멍이 생기고, 그다음에는 무엇이 있는지, 다른 사람들은 무엇을 보고 익혔는지 등 얼핏 생각해도 한계가 많다.

내가 출판사로 자리를 옮기려 고민할 때 그렸던 ‘책으로 안내하는 개발자 로드맵’은 이런 상황을 보완하는 아이디어다. 수많은 선배 저자의 힘을 빌리면 동료와 후배 개발자에게 개발자로서 걸어야 할 길을 다양하고 거시적인 관점에서 보여주고, 그 길을 걷기 위해 무엇이 필요한지를 알려줄 수 있을 것 같았다.

그래서 맥락과 수준에 맞는 가이드, 그때 참고할 만한 좋은 자료를 정성껏 준비해 보았다. 아직 많이 부족하다. 솔직히 내가 생각하는 그림의 10%도 충족하지 못하지만, 굳이 모든 게 갖춰지기까지 기다릴 필요는 없을 듯하다.

그리하야 공개하는 개앞맵시!!

개앞맵시

(급하게 그림 선사해주신 킵고잉 님께 감사를~ ^^)

당장 준비된 맵은 다섯 가지다. 형태는 마인드맵. 이상적인 형태는 아니지만 쉽게 활용할 수 있는 도구 중 가장 적합했다.

  • 개발자 공통편
    ‘소프트웨어 개발자가 갖춰야 할 공통 역량’이라는 주제로 맵을 만들었다.
    [기본 이론], [언어], [설계/품질], [인프라/도구], [프로젝트 관리], [교양/에세이]로 구성된다.
    가장 처음 만들어져서 가장 어설프다. ㅎㅎ
  • 개발자 일상편
    일반적인 개발자가 매일같이 겪게 되는 주제를 다룬다. 큰 분류만 보면 ‘공통편’과 다소 중복되기도 하지만, 공통편이 학문적 분류에 가깝다면 일상편은 실행활에 근거한 분류로 보면 된다. 그래서 ‘육아/삶/취미’와 ‘자녀 교육’까지 챙겼다.
    [코딩&설계 실무], [테스트/품질], [알고리즘/문제해결], [인프라/도구], [프로젝트 관리], [IT에세이/상식], [육아/삶/취미], [자녀 교육]으로 구성된다.
  • 게임 개발자편
    게임 개발 직군 중 서버를 제외한 개발자를 위한 맵이다.
    [기획/디자인], [개발(원리/알고리즘, 그래픽스, 게임 엔진)], [QA/테스트], [인프라/도구]로 구성된다.
    구성에 도움을 준 진태에게 감사를~ ^^
  • 서버 개발자편
    게임/웹/소셜 서비스 등 분야를 막론한 맵이다.
    [서버 프로그래밍 기초], [프레임워크], [설계/품질], [인프라 구축/가상화], [관계형 데이터], [NoSQL], [도구]로 구성된다.
  • 스타 저자/역자편
    꾸준히 좋은 책을 내주시는 저자/역자 분들과 그분들의 책을 소개한다.
  • 그외..
    미완.. coming someday

[전체 맵]도 볼 수 있다. 종종 들어오다 보면 새로운 맵이 추가되어 있을 것이다.

모든 맵은 아래 그림과 같은 미니맵을 포함하며, 각 항목의 화살표를 누르면 해당 맵으로 이동한다.

Cursor_및__개앞맵시__개발자_일상편_개발자의_앞길에_맵핵_시전___2015_04__-_MindMeister_Mind_Map

각 책의 제목 옆에 있는 아이콘은 각각 ‘상세 설명’, ‘예스24 링크(종이책)’ 혹은 ‘한빛미디어 링크(전자책)’, ‘상세 이미지’이다. 종종 저자 강의나 데모 동영상, 유용한 팟캐스트도 보게 될 것이다.

Cursor_및__개앞맵시__개발자의_앞길에_맵핵_시전__-_게임_개발자편_-_MindMeister_Mind_Map

우선 여기까지…

앞으로는 사람들의 피드백을 들어가며 차근히 업데이트할 예정이다. 어떤 관점의 맵이 필요한지, 만들어 놓은 맵에서 보강할 점은 무엇인지에 대한 이야기를 많이 들었으면 좋겠다.

구글 코리아 채용 정보
Aug 27th, 2014 by Wegra Lee

요즘 구글 코리아에서 소프트웨어 엔지니어를 잔뜩 뽑고 있단다.

당장도 그렇지만.. 후에 구글 지원을 고민하는 사람에게도 도움이 될테니 따로 포스팅해놓았다.

[회사 미션]

  • 세계의 모든 정보를 조직해서 모두에게 뿌린다. (organize the world’s information and make it universal.)

[조직 구성]

  • 구성도: http://bit.ly/1lekD9q
    • ‘다른 회사는 모르겠지만, 구글 그림은 와 닿는다.’ by 구글 엔지니어
  • 팀 크기 평균: 3.5명
    • 프로덕트 매니저 등 비 개발 인원도 거의 다 백그라운드 Computer Science다.

[문화]

  • 데이터 기반 수평적 토론
  • 핵심 가치(사용자에게 어떤 가치를 주는가?)는 협상 대상이 아니다.
    • 특정 이해관계자, 일정 등 때문에 꼭 필요한 기능이 빠지거나 엉뚱한 기능이 들어가지 않는다.
  • 구글 내의 모든 인프라 소스는 오픈되어 있다. (설계 문서도 마찬가지)
  • 필요하면 직접 고치고 기능도 추가할 수 있다.
  • 강력한 리뷰 문화.
    • 디자인, 코드, 배포 프로세스 등 모두 관련자들이 리뷰한다.
    • 리뷰어가 동의하지 않으면 런칭 불가.
  • 테스트에서 프로덕션 배포까지 소프트웨어 엔지니어가 수행한다.
  • 개발 인프라 거의 무제한
    • 테스트에 컴퓨터 10,000대가 필요하다? 그냥 쓰면 된다.
  • 시간 관리는 본인이 알아서..
  • 개발자가 꿈꾸는 회사지만, 절대 널널하진 않다.

[원하는 인재상]

  • 지식과 경험 (주로 컴퓨터 과학과 구글 인프라)
  • 수행력
  • 기술 리더십/영향력
  • 조직 영향력

[이력서]

  • 잘하는 분야 중심으로..
  • 과제 기간/수 보다는 무엇을 배웠는지..
  • 학력, 영어 점수, 경력 기간 따위.. ㅎ
  • 최소 10번은 사람들의 리뷰를 거쳐 다듬어라.
  • 제출
    • 소프트웨어 엔지니어는 아마 여기인듯..
    • 그 외에는 여기서 알아서 찾으면 될듯..

[면접]

  • 전화 인터뷰에서 구글 닥스로 실제로 코딩한다.
  • 온사이트 인터뷰
    • 면접 절차 중 가장 많이 떨어지는 곳 (남 앞에서 칠판에 코딩하는 게 쉽지 않다)
    • 모의 인터뷰 영상
  • 영어 점수는 안 보지만, 실제 커뮤니케이션 가능해야..
    • 온사이트 인터뷰시 외국인이 인터뷰어로 들어갈 수 있다.
    • 당분간 구글 코리아의 모든 프로젝트는 글로벌 프로젝트다.
  • 2010년인가.. 지원에서 입사까지 평균 51일 걸렸음
    • [팁] 인터뷰 날짜 잡을 때, 자신이 준비할 기간을 고려해 잡아라.

[재지원]

  • 1년 이후에 하는 게 좋다.
    • 1년 전에는 기존 (떨어졌던) 면접 점수가 함께 고려된다.
    • 1년이 지나면 기존 점수는 사라진다.
  • 기 제출한 이력서를 갱신하려면 무시하고 새로 지원한다.

대강 이 정도로 정리해봤습니다.

IT 트랜드 따라잡기
Mar 6th, 2014 by Wegra Lee

최신 IT 트랜드를 쫓아가고 싶은 이들을 위한 팁을 몇 가지 정리해 보았다.

통계 서비스

각종 통계/추이 정보를 제공하는 서비스들이다. 일부는 특정 시점의 스냅샷만 보여주지만, 일부는 실시간으로 살아 있는 정보를 제공하고 검색 기능도 갖추고 있다. 후자는 링크를 잘 기억해 두었다가 궁금한 것이 생길 때마다 찾아보면 큰 도움이 될 것이다.

  • TIOBE Index
    • 많이 사용되는 개발 언어의 순위와 추이를 보여준다.
  • Ohloh
    • 많이 사용되는 개발 언어의 순위와 추이를 보여준다.
    • 원하는 언어만 선택하여 비교할 수 있다.
  • LangPop 차트
    • 많이 사용되는 개발 언어의 순위와 추이를 보여준다.
    • StackOverflow 질문과 GitHub 프로젝트 정보를 기반으로 한다.
  • Indeed.com
    • 미국의 구인/구직 사이트이다.
    • 기업체가 요구하는 언어/플랫폼/기술의 순위를 볼 수 있다.
  • 구글 트랜드
    • 지정한 키워드를 포함하는 뉴스 수의 추이를 보여준다.
    • 복수 키워드를 입력하여 서로 간에 비교할 수 있다.
  • StackOverflow 태그 통계
    • 사이트에 올라온 질문에 사용된 태그(tag)들의 빈도, 즉 해당 태그를 포함한 질문의 수를 일/주/월/연별로 통계 내어 보여준다.

피드(feed) 서비스

가입 혹은 궁금한 키워드를 등록해두기만 하면 이슈가 생겼을 때 알아서 정보를 제공해주는 서비스들이다.

  • 데브멘토
    • 강좌/세미나/행사 정보를 제공한다.
    • RSS 혹은 (회원 가입 시) 이메일로 받아볼 수 있다.
  • Google Alerts
    • 관심 키워드를 등록하면, 구글이 해당 키워드를 포함하는 최신 뉴스/블로그 등의 정보를 요약해서 이메일로 보내준다.
  • SlideShare
    • 프리젠테이션 자료 공유 사이트이다.
    • 회원 가입 후,
      이메일 설정에서 ‘With featured and other useful content tailored for me’ 항목 선택
      자신의 likes, follows 정보에 기반하여 추론하는 듯
    • 회원 가입 후, 이메일 설정에서 ‘With featured and other useful content tailored for me’ 항목을 선택하면 주기적으로 관심 분야의 최신 프리젠테이션을 이메일로 보내준다.
    • (자신의 likes, follows 정보를 기초로 추론하는 듯하다.)

모바일 앱

관심사별로 좋은 뉴스를 추려주는 모바일 앱들이 많다. 앱 설치 후 Technology, Programming, Agile 등 IT 관련 섹션을 선택해주면 끝! 출퇴근 길에 짬짬히 체크하면 따끈따끈한 정보를 얻을 수 있다.

  • Zite
    • 내가 주로 이용하는 앱이다.
    • 방금 Flipboard에 6천만 달러에 팔렸다는 기사가…
  • Flipboard
    • 아이패드 초기 시절의 킬러 앱 중 하나였다. (요즘은 모르겠다.)

위의 두 앱은 iOS와 Android를 모두 지원한다. 이 외에도 좋은 뉴스 서비스 앱이 많을테니 취향에 맞는 것을 선택해 사용하길 바란다.

관련 기사

최신 기사 중 재미난 것 하나를 소개하겠다.

‘메타프로그래밍’이란?
Feb 27th, 2014 by Wegra Lee

메타?

나중에 더해져서 다른 개념을 보강 혹은 완성하는 것
A concept which is an abstraction from another concept, used to complete or add to the latter.

메타 데이터?

다른 데이터를 기술하는 데이터

metadata

책이라는 ‘실체를 훼손하지 않고’ ‘언제건’ 정보를 ‘더하거나 수정’할 수 있다.
‘실체에 접근하지 않고도’ 메타 데이터만으로 대상을 다룰 수 있다.
예> 분류, 검색, 정렬 등

메타 프로그래밍?

프로그래밍에 메타 정보를 활용하는 것!
즉, 프로그램 본체 작성 후에 새로운 기능을 추가하거나 다른 용도로 사용할 수 있게 정보를 제공할 수 있다.

활용 예>

* 자바 어노테이션 (참고 – JUnit 4, 60초만에 익히기)
* AOP(Aspect-oriented programming): 로깅, 동기화, 권한 확인 등
* C++ 템플릿 메타프로그래밍
* Ruby: 런타임에 객체 인스턴스에 새로운 메서드 추가

장점

부차적인 요소 혹은 변경될 소지가 있는 요소를 메타 정보로 추출하여 핵심 로직만 남겨둘 수 있다.
따라서 소스 코드의 가속성과 프로그램의 유연성이 높아진다.

단점

자칫 전체 로직의 연결 고리 일부가 사라져서 프로그램을 이해하기 어렵게 만들 수 있다.

단일 책임 원칙: 그 단순함과 복잡함
Feb 10th, 2014 by Wegra Lee

(원문) SRP: Simplicity and Complexity

Effective Unit Testing의7.1.2절에서 인용한 블로그 글이다.

단일 책임 원칙: 그 단순함과 복잡함

단순한 것이 차차 복잡해지는 것이 아니다. 오히려 그 반대다. – 알랜 퍼리스(Alan Perlis)

SOLID 원칙 중 하나인 “단일 책임 원칙(SRP, The Single Responsibility Principle)”은 내가 가장 좋아하는 객체지향 설계 원칙 중 하나다. 나는 이로부터 단순함과 복잡함을 동시에 발견할 수 있었다. 이 원칙을 알게 된 게 수 년 전이고, 직접 관련 글을 써본 지도 일 년이 넘었다. 하지만 이를 실무에 적용하기란 여전히 쉽지만은 않다. 수년간 여러 개발자에 이 원칙을 전파하면서 흥미로운 사실을 발견했다. 모두가 이 원칙의 의미는 이해하고 있지만, 막상 코딩할 때에는 까맣게 잊어버리거나 적용하는 법을 몰라 헤매는 것이다. 그래서 이 문제를 바라보는 나의 관점과 지금껏 겪어왔던 경험을 이야기해보려 한다.

외적 측면 (참고: 책에서는 ‘외면’이라 번역함)

모든 클래스와 메서드는 단 하나의 역할만 수행해야 한다.

이것은 내가 “외적 측면”이라 부르는 것으로, 이름이 중요한 상황이다.

외적 측면은 새로운 코드를 작성할 때 주로 고려된다. 무엇을 하는 코드인지 생각해본 후, 클래스나 메서드를 작성하고, 새 코드가 하는 일을 잘 표현하는 이름을 지어준다. 코드를 읽을 때도 외적 측면이 작용한다. 이름만 봐도 클래스나 메서드가 무슨 일을 하는지 바로 알 수 있어야 한다.

여기까지 이해하는 데 아무런 무리가 없으리라 믿는다.

그렇다면 이처럼 이해하기 쉬운데도, 사람들은 왜 이를 잘 지키지 않을까? 왜 적절한 클래스와 메서드를 찾으려 수천 줄의 코드 속에서 헤매고 있는 걸까? 그럴싸한 이유가 몇 개 떠오른다. 아마도 우리는 작명에 소질이 없나 보다. 혹은 너무 일반적이거나 광의적인 이름을 써서 너무 많은 일을 한꺼번에 처리하고 있을지도 모른다. 그것도 아니면 그냥 신경 쓰지 않는 것일 지도.

내적 측면 (참고: 책에서는 ‘내면’이라 번역함)

클래스와 메서드를 수정해야 하는 이유는 오직 하나뿐이어야 한다.

이는 내가 “내적 측면”이라 칭하는 것으로, 단일 책임 원칙의 또 하나의 (자주 잊히는) 측면이다.

내적 측면은 기존 코드를 변경하거나 새로운 코드를 집어넣으려 할 때 고려된다. 다시 말해, 각 클래스와 메서드가 무슨 일을 하는지 파악해야 하는 상황이다. 이때 분석해야 할 코드량이 예상보다 훨씬 많아 좌절할 때가 많은데, 주원인은 클래스나 메서드가 원래 해야 할 일보다 훨씬 많은 것을 처리하고 있기 때문이다.

하지만 외적 측면보다 내적 측면에 집중하면 단일 책임 원칙을 적용하기가 한결 쉬워진다. 즉, 역할에만 신경 쓰지 말고, 클래스나 메서드를 변경해야 할 이유가 몇 가지나 되는가를 항시 고민하자.

그렇다면, 언제 어디서 일이 틀어지는 것일까?

노트: 대게 개발자가 TDD와 리팩토링을 하지 않는 조직일수록 단일 책임 원칙에 어긋나는 사례가 많다.

생각해보자. 경험상 단일 책임 원칙에 어긋나는 사례 대부분은 시스템 인터페이스에 가까운 클래스와 메서드에서 발견되었다. 예를 들면, 웹 애플리케이션의 거대한 컨트롤러나 액션 클래스, 스윙 애플리케이션의 거대 이벤트 핸들러, 이벤트 기반 시스템에서 메시지 처리를 담당하는 거대한 메서드 등이 있다.

이는 시스템 인터페이스에 가까운 클래스와 메서드는 더 광범위하고 일반적인 역할을 담당하기 때문이다. 이런 메서드는 수많은 비즈니스 규칙이나 복잡한 워크플로우를 관장하는 경우가 제법 많다.

거래 정보를 담은 거대한 XML 파일을 입력받는 시스템을 상상해보자. 그리고 이를 처리하는 첫 메서드는 TradeService 클래스의 “processTrade(tradeXML)”라고 해보자. 이 메서드의 역할이 무엇인가? 바로 거래를 처리하는 것이다. 그렇다면 이름은 적절한가? 이 시스템은 입력받은 거래(trade)를 처리(process)하길 원하니 첫 메서드의 이름으로 processTrade는 적절해 보인다.

다른 예를 보자. 인터넷 쇼핑 사이트에서 고객이 상품 몇 개를 장바구니에 담고, 지불 정보를 입력하고, “주문” 버튼을 클릭했다. 그렇다면 뒷단에서는 주문 발주를 위해 대략 placeOrder(order) 정도의 메서드를 호출할 것이다. 나쁘지 않다.

생각 발전시키기

일반적으로, 시스템 인터페이스에 가까운 코드일수록 더 폭넓고 일반적인 역할을 담당하는 경향이 있다. 반면, 시스템 인터페이스에서 멀어질수록 더 좁고 특수한 역할을 담당하게 된다.

앞의 두 예에서, processTrade와 placeOrder 메서드는 단 하나의 역할만 수행한다고 주장할 수 있다. 전자는 입력받은 거래를 처리하고 후자는 고객의 주문을 발주한다. 그래서 단일 책임 원칙의 외적 측만을 고려하는 개발자라면 거리낌 없이 관련된 코드 모두를 그 메서드 안에 욱여넣을 것이다.

문제는 거래 처리와 주문 발주가 심히 복잡한 작업이라는 데 있다. 복잡한 과정을 거쳐야 하고, 수많은 비즈니스 규칙과 요구사항을 만족하게 하기 위한 수백 수천 줄의 코드를 작성해야 할 것이다. 그러니 이 많은 코드를 한 메서드에 욱여넣는 것은 단일 책임 원칙을 명백히 위반할 뿐 아니라, 어리석기까지 한 일이다.

단일 책임 원칙을 만족하는 코드를 만들려면, 변경 사유가 오직 하나뿐이어야 한다. 이는 다음과 같이 발전된 생각을 이끌어내 준다.

일반적으로, 시스템 인터페이스에 가까운 클래스일수록 더 많은 것을 위임(delegation)한다. 반면, 시스템 인터페이스에서 멀리 떨어진 클래스일수록 위임할 것이 적어진다.

전통적인 자바 웹 애플리케이션의 컨트롤러가 좋은 예다. 사용자 인터페이스와 가까운 컨트롤러는 폭넓은 역할을 담당하며 비즈니스 로직은 모두 다른 객체에 위임한다. 컨트롤러는 단순히 흐름만 제어할 뿐이다. 정 반대로, 매우 특수하고 제한된 역할만 수행하는 DAO(Data Access Object)는 일거리를 다른 클래스에 위임하는 경우가 거의 없다. 그 중간에 위치하는 서비스는 자신의 비즈니스 로직을 처리하지만, 종종 다른 협력 객체에 작업을 위임하기도 한다. 서비스는 컨트롤러보다는 좁고 DAO보다는 광범위한 역할을 처리하는 게 보통이다. 어쨌든, 각 클래스와 메서드는 단일 역할만을 담당한다.

다르게 질문하기

다른 개발자에게 맨토링해주거나 함께 짝(pair) 프로그래밍을 하며 한 메서드 안의 코드량이나 클래스 안의 메서드 수를 가지고 논쟁을 벌일 때가 많다. 단일 책임 원칙의 외적 측면만을 근거로 내세운다면 코드가 하는 일이 너무 많다는 걸 잘 인정하지 못하는 개발자가 많을 것이다. 그래서 내적 측면이 중요하다는 걸 깨달았다. 이제는 메서드나 클래스가 맡은 역할이 몇 개인가를 묻는 대신, 수정해야 하는 이유가 몇 가지나 되느냐고 묻기 시작했다.

Effective Unit Testing 번역서 출간
Feb 6th, 2014 by Wegra Lee

Effective Unit Testing : 클린 코드와 좋은 설계를 이끄는 단위 테스트

두 번째 번역서..

사실, 출간된 지는 몇 달 지났다.

첫 번역서인 JUnit in Action은 다양한 개발 환경에서 JUnit 기반 프레임워크를 활용하는 방법을 보여주는 활용서 성격이 강했다.

반면, 이번 책은 품질 향상을 넘어 설계 개선이라는 테스트를 통해 얻을 수 있는 한 차원 높은 가치를 잘 설명하고 있다.

그래서 전문 테스터보다는 개발자를 꿈꾸는 모든 이들이 한 번쯤 꼭 봐둘 만한 책이다.

평소 저자와 같은 사상을 가지고 있었고 고민도 많이 했던 분야인 만큼,

책의 단순 오류뿐 아니라 관련 논쟁까지도 기꺼이 수용할 용의가 있다. (연락은 ‘wegra.eut at G메일’로..)

지속적 통합(Continuous Integration) 구성 사례
Jun 7th, 2011 by Wegra Lee

이번엔 지속적 통합 사례를 하나 정리해보겠다. (지속적 통합의 개념 설명은 이곳에..)

Components and Basic Workflows

이번에 구성해본 지속적 통합(CI) 환경의 구성 요소는 다음과 같다.

  • CI (Continuous Integration) 툴: IBM Rational Team Concert (RTC)
  • 소스 관리: IBM Rational Team Concert
  • 빌드 스크립트: Apache Ant
  • (참조) Apache Maven

비록 RTC라는 상용 툴을 사용하고는 있지만, 이 글에서 다루는 대부분의 내용은 개념적인 것이라, 다른 툴(예: Hudson, TeamCity, CruiseControl)을 사용할 때도 그대로 적용/응용할 수 있다.

전체 시스템을 그림으로 나타내면 대략 다음과 같다.

ci

RTC 서버의 다양한 기능 중, 여기에서는 소스 관리와 빌드 관리, 그리고 웹 UI 정도이다. 거시적인 작업 흐름은 다음과 같다.

  1. 개발자가 변경 내용(change-set)을 소스 저장소에 전달한다.
  2. RTC 서버의 빌드 모듈이 이를 인식해 적당한 빌드 엔진에 할당한다.
  3. 빌드 엔진은 소스 저장소로부터 빌드에 필요한 데이터를 내려 받아 Ant 빌드 스크립트를 수행한다.
  4. Ant 빌드 스크립트는 빌드를 수행하고 산출물을 개발 서버 및 API 서버에 배포한다.
  5. 빌드 엔진은 빌드 결과 및 과정은 빌드 서버에 알리고, 서버는 개발자 PC에 푸시한다.

개발자나 프로젝트 관련자들은 이런 모든 과정/결과를 언제든 전용 Eclipse UI나 Web UI를 통해 확인할 수 있다.

또한, 어떤 빌드 엔진을 사용할 지, 어떤 스크립트를 사용한 지 등은 모두 configuration 가능하다.

Project Directory Layout

여러 팀, 다양한 과제에 걸쳐 일을 효율적으로 진행하려면 프로젝트 구성부터 일관적으로 유지하는 것이 좋다.

Ant는 비록 산업 표준 빌드 툴이지만, 프로젝트 구성에 대한 표준 규약은 제공하지 않는다. 때문에 담당자 취향만큼이나 다양한 구성이 존재하며, 그 구성을 정하고 관리하는데에만 상당한 고뇌와 노력이 소요된다. 그리고 재활용도 쉽지 않다. 바로 이 문제를 타파하고자 나온 오픈소스 프로젝트로 Maven이란 것이 존재한다. Maven 개발자들은 프로젝트의 구성에 관련된 모범 사례(best practice)들을 집대성하고자 하였다. 무분별한 컨피규레이션 허용보다는 잘 정의된 모범 사례를 따른는 것을 원칙으로 삼은 것이다(Convention over Configuration). 물론 그 결과가 이상적으로 완벽하진 않지만, 상당수의 프로젝트에 적용하는데 큰 무리가 없을 것이다.

어쨌든, 본 예제에서는 Ant를 사용하지만 Maven의 이상과 결과를 상당부분 따르고 참조할 것이다. 물론 Ant이기 때문에 언제든 어렵지 않게 수정 가능하다.

그래서 내가 구성한 기본 구성은 다음과 같다.

  • src/main/java – 제품 소스 코드
  • src/main/resources – 제품에 포함될 리소스
  • src/main/config – 제품 설정 정보
  • src/main/webapp – 웹 애플리케이션 소스
  • src/test/java – 테스트 소스 코드
  • src/test/resources – 테스트에 필요한 리소스
  • lib/main – 제품 수행에 필요한 라이브러리
  • lib/test – 테스트에 필요한 라이브러리 (junit, mokito  등)
  • tools – 팀내 공용 툴 (예: FindBugs, CheckStyle, Code Pro Analytix 등)
  • build.xml – Ant 빌드 스크립트
  • build.properties – Ant 빌드 스크립트용 커스텀 프로퍼티 파일
  • build-jazz.xml – RTC/Jazz용 빌드 스크립트(build.xml을 확장함)
  • LICENSE.txt – 제품 라이선스 정보
  • README.txt – readme 파일

참조함 Maven의 표준 디렉터리 구성과 크게 다르지 않다. 간소화를 위해, 크게 필요 없다고 생각되는 filters, assembly, site, NOTICE.txt 를 제거하였고, lib과 tools가 추가되었다.

lib이 추가된 이유는 Maven이 종속성 자동 관리 기능이 포함된데 비해 Ant는 직접 필요할 라이브러리를 관리해야 하기 때문이며, tools 는 개발팀 내 함께 쓰는 유용한 도구와 그 설정 정보를 공유하기 위함이다.

빌드 스크립트는 총 3개의 파일로 구성된다. build.xml 은 메인 빌드 스크립트이며, build.properties에는 그 중 사용자 정의 속성을 담아, 상황에 맞게 설정하여 빌드할 수 있게 하였다. 마지막의 build-jazz.xml 은 build.xml을 확장(import)하여 RTC/Jazz에 종속된 기능을 추가로 수행하기 위해 추가하였다. 즉, build-jazz.xml를 제외한 두 파일은 RTC/Jazz와 완전히 독립적이어서 어떤 환경에서건 그대로 재활용할 수 있다.

스크립트의 속 내용은 조금 후에 살펴보기로 하고, 빌드 과정에서 생성되는 디렉터리 레이아웃에 대해서 먼저 살펴보자.

  • target/classes – 제품 소스를 컴파일한 클래스 파일들 & 리소스
  • target/test-classes – 테스트 소스를 컴파일한 클래스 파일들 & 리소스
  • target/reports/unit-test – 단위 테스트 결과 리포트 (XML 포맷)
  • target/reports/unit-test/html – 단위 테스트 결과 리포트 (HTML 포맷)
  • target/reports/integration-test – 통합 테스트 결과 리포트 (XML 포맷)
  • target/reports/integration-test/html – 통합 테스트 결과 리포트 (HTML 포맷)
  • target/reports/findbugs – FindBugs 수행 결과 보고서
  • target/reports/checkstyle – CheckStyle 수행 결과 보고서
  • target – 빌드 산출물 루트 겸, package 된 제품 바이너리 등 최종 산출물

특별한 설명은 필요 없으리라 본다. 그렇다면 이제 Ant 빌드 스크립트의 내용과 빌드 단계에 대해 알아보기로 하자.

Ant Build Script and Build Lifecycle

Ant 빌드 스크립트는 빌드 타깃(target)과 타깃간 종속성(선행 타깃 정의)과 타깃에서 실행해야할 실제 작업을 정의한다. 빌드 라이프사이클 역시 Maven의 그것을 기반으로 간소화한 후 약간 보강하였다. 다음은 build.xml에 정의된 타깃들을 라이프사이클에 따라 설명한 것이다.

  1. compile – 제품 소스 코드를 컴파일한다.
  2. test-compile – 테스트 코드를 컴파일한다.
  3. unit-test – 단위 테스트를 수행한다.
  4. package – 제품 컴파일 결과를 배포 형태로 패키징한다.
  5. integration-test – 통합 테스트를 수행한다.
  6. code-analysis – 정적 코드 분석을 수행한다. (FindBugs, CheckStyle)
  7. deploy – 패키징한 결과를 개발 서버 및 API 서버로 배포한다.

몇 가지만 살펴보겠다.

먼저, code-analysis가 Maven에 없는 새로 추가된 단계이다. 이 단계에서는 FindBugs, CheckStyle 등의 정적 코드 분석 툴을 이용하여 제품 소스 코드의 잠재적 결함과 코딩 규약 부합 여부를 검사한다. code-analysis 단계 외에는, 실패 시 다음 단계를 계속 진행할 수 없다.

unit-test 단계에서는 수행시간이 짧은 단위 테스트들을 실행한다. 통합 테스트 케이스와 시간이 오래 걸리는 테스트 등은 뒷쪽의 integration-test 단계에서 수행시킨다.

마지막 deploy 단계에서는 완성된 바이너리를 개발 서버로, 최신 API 문서를 API 서버로 배포한다.

변경 가능한 사용자 속성으로는 다음과 같은 것들이 있다.

  • product.name  - 제품명
  • product.version – 제품 버전
  • main.class – 실행 클래스명: jar 파일의 Manifest 파일에 추가됨
  • compile.deprecation – javac 컴파일 옵션
  • compile.debug – javac 컴파일 옵션
  • compile.optimize – javac 컴파일 옵션
  • compile.source – javac 컴파일 옵션
  • compile.target – javac 컴파일 옵션
  • proxy.host – 프락시 주소 (프락시 안에 갖힌 네트워크에서 수행될 때)
  • proxy.port – 프락시 포트 (프락시 안에 갖힌 네트워크에서 수행될 때)
  • deploy.binary.host – 패키징된 바이너리를 배포할 호스트 주소
  • deploy.binary.user – 호스트 로그인 계정
  • deploy.binary.passwd – 호스트 로그인 패스워드
  • deploy.binary.keyfile – 호스트 로그인에 필요한 key 파일 위치 (xxx.pem)
  • deploy.binary.dir – 바이너리를 복사해 넣을 호스트 내의 디렉터리 경로
  • deploy.api.host – 최신 API를 배포할 호스트 주소
  • deploy.api.user – 호스트 로그인 계정
  • deploy.api.passwd – 호스트 로그인 패스워드
  • deploy.api.keyfile – 호스트 로그인에 필요한 key 파일 위치 (xxx.pem)
  • deploy.api.dir – 바이너리를 복사해 넣을 호스트 내의 디렉터리 경로 (웹 서버 혹은 파일 서버)

보는 바와 같이 소스 코드 디렉터리 구조, 산출물 파일 이름과 같은 정보는 따로 설정할 수 없도록 제안하고 있다. 이유는 초반에 언급한 Maven의 설계 원칙(Convention over Configuration)을 좀 더 강요하기 위함이다.

물론 build.xml의 내용을 보면 관련 정보를 속성으로 제공하여, 꼭 필요한 경우 쉽게 변경할 수 있다.

마지막으로 build-jazz.xml 파일을 살펴보자.

이 파일은 build.xml 을 확장하여 RTC/Jazz 빌드 서버에서 사용할 특화 타깃을 정의하고 있다. RTC/Jazz 빌드 기능에 특화된 만큼, 이 스크립트를 개발자 IDE에서 실행하려 하면 필요한 파일이 없다면서 에러를 발생시킬 것이다. 물론 몇 가지 설치/설정으로 가능케할 수 있지만, 별다른 이점은 없으니 Jazz 빌드 서버에 맡기기로 하자.

기본적으로는 다음의 네 가지 타깃이 제공된다.

  • package-jazz – build.xml의 package 단계까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다. 단위 테스트 보고서와 패키징된 바이너리가 이에 포함된다.
  • integration-test-jazz – build.xml의 integration-test 단계까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다. 위 결과에 통합 테스트 결과가 추가된다.
  • code-analysis-jazz – build.xml의 code-analysis 단계까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다. 위 결과에 정적 코드 분석 보고서가 차가된다.
  • deploy-jazz – 최종 단계인 deploy까지 수행한 후, 산출물과 보고서를 RTC/Jazz에 등록한다.

특별히 위와 같은 네 단계만 정의한 이유는 잠시 후 Build Definitions 절에서 확인할 수 있다. 그 전에 정적 코드 분석(static code analysis) 단계에서 무엇을 하는지 살짝 알아보고 가기로 하자.

Static Code Analysis

앞서 살펴본바와 같이, unit-test와 package 단계 사이에 code-analysis 라는 단계가 추가되었다. 이는 Maven에도 정의되어 있지 않은 단계이다. 이 단계에서는 제품의 소스 코드를 분석하여 잠재적인 결함과, 코딩 규약 준수 여부를 확인한다.

쉽게 활용할 수 있는 오픈 소스 툴들로는 FindBugs와 CheckStyle, PMD 등이 있다. (기능면에서 CodePro Analytix가 가장 마음에 드나, 아쉽게도 Ant용 task를 제공하지 않아 여기서는 제외하였다.)

FindBugs는 버그 패턴 위주로 거의 100% 적중률로 문제를 분석해주며, CheckStyle과 PMD는 그 외에도 코딩 규약, 유사 코드 검색 등 다양한 기능을 제공한다. CheckStyle과 PMD 는 기능면에서 상당히 겹치기 때무에 둘 다 사용할 필요는 없다. 나는 PMD를 더 선호하였지만, 최근에 업그레이드가 이루어지지 않고 있어 CheckStyle로 선회하였다.

참고로, 이들 툴을 지속적 통합 프로세스의 일부로 등록해놓는 것은 좋은 생각이긴 하지만 IDE에 통합하여 개발자들이 수시로 확인해보는 것에 비할 바가 못된다. 다행히 CodePro Analytix를 포함하여 위의 모든 툴들은 Eclipse 플러그인을 제공하고 있다.

관련하여 Java 코딩 규약 관리 방법 역시 참고가 될 것이다.

Build Definitions

빌드 정의(Build Definition)는 빌드에 필요한 각종 정보와 수행 조건 등을 담는다. 예를 들어, 빌드에 사용할 파일(build-jazz.xml)명, 타깃, 빌드 스케줄 등이 그것으로, 프로젝트 특성에 맞는 다양한 전략을 수립할 수 있다. 상세 내용은 본 글의 주제와 크게 관련 없으니  지나치도록 하겠다.

어쨌든 Jazz의 빌드 서버는 이 정의를 바탕으로 빌드 엔진에 빌드를 요청한다. 아래의 그림은 내가 구축하기 원하는 빌드 전략이다.

schedule

그리고 위의 전략을 구현하기 위해 다음과 같은 네 가지의 빌드 정의를 작성하였다.

  1. Continuous: 변경 사항에 대한 빠른 피드백을 목적으로, 컴파일/단위 테스트/패키징 성공 여부까지 확인한다.
    1. 빌드 주기: 매 5분
    2. 빌드 타깃: package-jazz
  2. Integration: 더 많은 시간이 소요되며 다양한 테스트를 수행하는 통합 테스트까지 수행한다.
    1. 빌드 주기: 매 1시간
    2. 빌드 타깃: integration-test-jazz
  3. Nightly: 일별 snapshot을 만들어, 매일 아침 baseline을 생성한다.
    1. 빌드 주기: 월~토요일 3:00 AM
    2. 빌드 타깃: code-analysis-jazz
  4. Weekly: 주간 변경 내용을 종합 검증하여 baseline을 생성하고, 개발 서버에 배포한다.
    1. 빌드 주기: 매주 일요일 3:00 AM
    2. 빌드 타깃: deploy-jazz

Jazz 빌드 서버는 위의 네 가지 빌드 정의에 기반해, 자동으로 빌드/테스트/배포를 수행하며, 그 결과를 개발자에게 알려주게 된다.

Summary

이상으로 빌드 시스템의 거시적인 구성부터 빌드 단계 정의, 빌드 정의를 통한 지속적 빌드 전략 수립까지 구성해 보았다.

다소 이론적인 면에 집중하여 설명하였지만, 상세 내용으로 들어가면 내용이 너무 길고 장황해지니 양해 바란다.

(관련 Ant 빌드 스크립트는 약간 다듬어서 추후 업데이트하겠음)

Java 코딩 규약 관리 방법
May 30th, 2011 by Wegra Lee

오랫만에 글을 적는 계기는, 얼마전 팀에 배포된 100페이지짜리 자바 코딩 가이드라인 때문이다.

나는 이미 약 9년 전에 나만의 코딩 가이드라인 문서를 만들어 다수 프로젝트에 적용했었다. 당시엔 나름 자부심을 주는 산출물 중 하나였지만, 얼마 지나지 않아 이것은 구시대적 산물이 되었음을 깨닫게 되었다.

코딩 규약 자체는 분명 필요하다. 이것이 없는 조직은 아직 굉장히 미숙한 개발 문화를 갖고 있을 확률이 높다. 문제는 이를 정적인 문서(워드나 파워포인트 형태)로 작성/관리한다는데 있다. 문서 방식의 대표적인 한계는 이러하다.

  • 내용이 풍부해질 수록 배우고 실무에 적용하기 어려워진다.
  • 언어 명세에 추가되는 새로운 문법에 빠르게 대응하지 못한다.
  • 항목 A의 예제 코드가 항목 B를 따르지 못하는 경우가 흔히 발생한다.
  • 몇몇 예제만으로 실 제품의 수십만/수백만 라인의 다양한 코드와 매칭시키게 하기에는 한계가 있다.

과거 시절에는 저런 한계를 안고서라도 문서가 필요했지만, 더이상은 아니다. 개발 도구들이 이미 충분히, 아니 비교할 수 없을 만큼 성숙되어 있기 때문이다.

Eclipse의 Code Formatter

가장 대표적인 자바 IDE 중 하나인 Eclipse를 보자. Eclipse의 Preferences > Java > Code Style 메뉴를 보면 다음의 메뉴들을 볼 수 있다.

  • Clean Up: 불필요한 코드나, 명백히 잘못된 코드 설정
  • Code Templates: 정형화된 코드 파일/클래스/메서드 등의 템플릿 설정
  • Formatter: 코드 포맷 설정
  • Organize Imports: import 문 구성 규칙 설정

위의 기능들은 개발 중 언제나 간단한 메뉴 조작이나 단축키로 바로바로 적용할 수 있다. 즉, 새로 합류한 팀원이 아무리 대충 짜놓은 코드라도, 즉시 베테랑 선임 개발자가 짠 코드처럼 바꿀 수 있다는 것이다. (기본 로직이나 단어 선택 등은 논외)

C/C++ 언어의 유사 툴을 사용해본 사람이라면 시큰둥할 수도 있다. 하지만 직접 저 메뉴들을 찾아들어가 잠시만 살펴본다면 그 막강한 표현력에 혀를 내두르고, 실제 프로젝트에 적용해보면 그 정확성에 감탄을 금치 못할 것이다.

더욱이 편집한 설정을 import/export 할 수 있으니, 기본 설정이 맘에 들지 않는다면 수정하여 팀 전체가 쉽게 공유할 수 있다. 소스 컨트롤 툴에 저장/관리한다면 금상첨화일 것이다.

하지만 코딩 규약은 단순 문법만 다루는 것은 아니다. 잠재적 결함을 예방하기 위한 올바른 코딩 패턴과 개발자들아 자수 실수하는 잘못된 패턴에 대한 예방 차원의 항목도 다수 포함된다. 위의 설정만으론 분명 부족함이 있다. 이에 대한 해결책으로는 두 가지 툴을 추천한다.

FindBugs

FindBugs라는 이름에서부터 너무도 명백하게 자신의 용도를 광고중인 이 툴은, 자바 코드에서 문제의 소지가 있는 다양한 버그 패턴을 찾고 그 이유를 설명해준다. 자신이 짠 코드에서 직접 짚어준다는 점에서 초간단 예제 몇 개만 달랑 던져주는 문서와는 천지차이다.

IDE와 통합은 기본이고 무료다. 또한 이 툴이 헛짚은 경우는 아직까지 겪어보지 못했을 정도의 정확성을 뽑낸다. 물론 ‘우리의 사용 환경에서는 절대 이런 일이 발생할 수 없어’라며 무시할 수는 있지만, 사용 환경이 언제까지건 변함 없고, 그 코드가 다른 프로젝트에 가져다 쓰일 확률이 zero 라고 확신하지 않는다면, 툴이 제안하는 예방 조치를 따라두는 것이 나쁠 것 없다.

CodePro Analytix

과거에는 PMDCheckStyle을 추천하며 CodePro Analytix는 소개 정도만 시켜주었는데, 이제는 상황이 바뀌었다. 구글이 이 툴을 사더니 무료로 뿌려버린 것이다. 더이상 상용 툴을 아쉬워하면 꿩 대신 닥으로 PMD나 CheckStyle을 사용할 필요가 없어졌다. 물론 이 둘을 무시하는 것은 아니지만, 개인적으로는 CodePro Analytix를 훨씬 높게 평가한다.

유사 코드 찾기종속성 분석 등 다른 기능도 많지만, 이번 주제와 밀접한 관련이 있는 기능은 바로 코드 검사 기능이다. CodePro Analytix는 Effective Java, Security, Internal API 등등 업계에서 많이 통용되고 있는 다수의 가이드라인에 맞는 수백가지의 검사 규칙을 제공한다. 각 규칙들은 세밀한 설정도 가능하고, 원하는 항목만 조합하여 팀만의 룰셋을 정의할 수도 있다. 이렇게 정한 규칙은 당연히 import/export 하여 공유할 수 있다.

Eclipse에 설치하려면 다음 주소를 참고하자.

http://code.google.com/intl/ko-KR/javadevtools/download-codepro.html

CheckStyle

CodePro Analytix로 천하통일할 수 있을 줄 알았으나, 확인 결과 CodePro는 Ant 태스크나 Maven 플러그인을 제공하지 않아, 지속적 통합 시스템에 넣기에 적합하지 않다. 하여 PMD와 CheckStyle 중 하나를 여전히 추천하지 않을 수 없는 상황이다. 둘 중 하나를 고르자면, 나는 CheckStyle을 추천한다. 이유는 간단하다. PMD가 2009년 이후 업데이트가 이뤄지지 않고 있는데 반해, CheckStyle은 지속적으로 업데이트 중이기 때문이다.

툴의 기능은 CodePro Analytix와 유사하나 지속적 통합 시스템에 바로 적용할 수 있도록 Ant 태스크와 Maven 플로그인을 제공한다. 물론 Eclipse와 같은 IDE용 플러그인 품질도 뛰어나 개발자 편의성도 좋다.

Summary

지금까지 살펴본 바와 같이, 자바 코딩 규약에 대해서는 이미 훌륭한 툴들이 갖추어져 있다. 문서로 힘들게 정리하고 교육하는 것보다는 이들을 활용하는 것이 백배는 효율적이다. 그 이유는 이들 툴 모두는 다음과 같은 장점을 제공한다.

  • IDE와 밀접히 통합되어 있어, 개발자들이 자신의 코드를 대상으로 언제든 쉽게 적용할 수 있다.
  • 무료이다.
  • 설정 편집 및 import/export 기능으로 팀원간 공유가 쉽다.
  • 강력하고 정확하다 (C/C++ 툴들과 비교를 거부한다).
  • Ant 태스크(FindBugs, CodePro) 혹은 명령행 수행 기능(Eclipse Code Formatter)을 제공하여 원한다면 지속적 빌드(continuous integration/build) 환경에 통합할 수 있다.

이 글을 읽는 사람이 자바 개발팀에 속해 있고 팀 내에 코딩 규약이 없거나 문서로만 관리되고 있다면, 지금이라도 늦지 않았으니 새로운 세상을 경험해보길 바란다.

»  Substance: WordPress   »  Style: Ahren Ahimsa