»
S
I
D
E
B
A
R
«
Bad Team Culture – As Many Tasks As Possible in Parallel
Oct 30th, 2009 by Wegra Lee

Bad Team Culture 시리즈.. 두 번째..

As Many Tasks As Possible in Parallel (AMTAPP) 는 문장 그대로 가능한 많은 태스크들을 동시에 진행시키는 프로젝트 관리 방식을 말한다. 훌륭한 프로젝트 관리 가이드와는 전면으로 배치되는 정책으로, 특히 Kanban [1][2] 에서는 철저히 경계하고 있다.

이 방식은 현재 내가 속한 팀뿐 아니라 우리 회사의 전형적인 프로젝트 관리 방식이다. 프로젝트가 이렇게 진행될 수 밖에 없는 원인을 몇 년간의 경험을 토대로 유추해 보았다.

  1. 프로젝트는 거의 완벽히 블랙 박스에 가려진체 진행된다. 외부인이 실시간으로 과제의 정확한 진행 상태를 확인할 길이 없다. 물론 내부 팀원들에게도 마찬가지다. 프로젝트 투명성에 대한 글은 [3] 를 참조하기 바란다.
  2. 프로젝트 생존을 위한 사내 경쟁이 심하다.
    1. 따라서 더 적은 자원으로 더 많은 것을 할 수 있다고 해야지만 프로젝트가 생존할 수 있다. 다른 팀 역시 마찬가지 상황이므로, 서로 자신의 역량 이상으로 최대한 부풀려 홍보한다. 1번 – 프로젝트 투명성 부족 문제로, 과제가 마무리 되거나 팀에서 알아서 중간 결과를 보여주기 전에는 꾸며진 보고 자료만이 프로젝트 평가를 위한 근거의 전부이다. 중간 결과 발표 시에도 잘 되는 시나리오 중심으로만 보여주므로 역시 정확한 상황은 알 수 없다.
    2. ‘나중에 할 것이다’ 보다는 ‘이미 진행 중이다’ 가 더 그럴싸하게 들린다.
  3. Big bang 릴리즈 방식을 취한다. Incremental release (iterative development) 에 대한 경험과 인식이 부족하다. 충분히 안정화된 제품은 릴리즈 이전에는 결코 접해볼 수 없다. 오히려 패치 없이도 쓸만한 릴리즈를 하는 것 자체가 희귀한 경험에 해당한다.
  4. 소프트웨어 프로젝트의 납기 지연은 당연한 것이라 받아들이다. 2-1 역량 이상으로 부풀려 이야기하기의 좋은 방어책이 된다. 납기를 중요시 하지만 납기에 늦었다 해서 프로젝트가 당장 부러지는 일은 드물다. 그간 투자한 것도 있으니 계속해서 가능성을 보여주기만 하면 프로젝트는 생존할 수 있다.
  5. 메니저들은 보통 개발 실무를 하지 않는다. 실제 일할 사람 수가 줄어드는 효과를 내는데.. 우리팀의 경우 약 1/5 정도가 개발 실무를 하지 않고 있는 것으로 보인다.

그 외에도 나열하면 끝이 없겠으나.. 간략히 두 가지로 요약해보면.. 역량 이상의 일을 따냈고, 그래도 다 하고 있음을 강조해야 해야 한다. 결과적으로, 일할 사람 수보다 당장 해야할 태스크 수가 더 많은 상황에 처한다. 하나의 태스크에 둘 이상이 달라붙는 것은 사치스러운 짓이다.

그럼 AMTAPP 방식의 폐단은 무엇일까?

가장 큰 문제로 개발자 간의 의사소통이 단절을 뽑겠다. 내가 하는 일과 옆의 팀원이 하는 일은 관계가 거의 없다. 풀어야할 문제가 다르고 서로 코드를 봐줄 일도 없다. 어려움에 봉착해도 상의할 사람도 없고, 일부러건 몰라서건 대충 만들어 놓아도 당작 동작만 하면 아무도 알지 못한다. 겉으로 잘 드러나지 않는 품질이야 어떻든, 동작만 하면 관리자는 만족해한다. 또한 노하우가 공유되지 않아, 못하는 사람은 계속 못하고, 잘하는 사람의 발전도 더디다.

다음으로는 집중력 저하를 들겠다. 소프트웨어는 순전히 개발자의 사고에 의해 만들어지는지라, 소프트웨어 개발직은 다른 무엇과 비교해서도 고도의 집중력을 가장 요하는  직업 중 하나이다. 불행히도 신은 사람의 두뇌를 멀티 태스킹용으로 설계하지 않았다. 동시에 두 가지 이상을 생각하는 것은 어림도 없고, 심지어 하나 하나 번갈아 처리하는 능력 역시 상당히 떨어진다. 일을 바꿔 집중력 끌어 올리기까지는 수분에서 십수분 이상이 필요하다 – 정확한 수치를 Peopleware [4] 에서 본 듯 하나, 지금은찾아보기  귀찮다 :-)

하이라이트는 다른 사람들의 태스크를 만들어내는 태스크를 할당받은 사람들이다. 이들이 일을 열심히 할 수록 다른 팀원들 수십명의 일거리가 눈더미 처럼 불어나 버린다. 코딩하고 결함 잡기도 벅찬 와중에, 문서 고쳐라, 새로운 툴체인 적용해라, 디렉토리 구조 바꿔라, 여기 새 이디엄이 있으니 적용해라, 방금 나온 따끈따끈한 바이너리 당장 테스트해서 보고해라, 보고용 자료 좀 준비해와라, 이것 보고 커맨트 좀 달라 등등 수많은 요청이 쏟아진다. 프로젝트를 이런 식으로 이끌면서 품질은 개발자의 자존심이니 하는 이야기가 나오면 울컥하지 않을 수 없다.


References

  1. Kanban (wikipedia)
  2. One day in Kanban land
  3. Project Transparency (프로젝트 투명성)
  4. Peopleware by Tom DeMarco and Timothy Lister
Bad Team Culture – Deadline-Driven Development
Oct 29th, 2009 by Wegra Lee

꾀 오래 전부터 재미삼아 정리해보던 주제인데.. 오늘은 실사례를 하나 들어보려 한다.

최근 팀 내에 돌아다니는 메일을 보면 모든 일정이 deadline 부터 역으로 만들어진다.

위로부터 하달되는 메일들의 전형적인 흐름은 ‘릴리즈 날짜가 언제이고, A/B/C 를 포함시키기로 하였는데, B 를 하려면 최소 n 일은 필요하니 오늘중으로 x, y, z 를 꼭!!! 끝내라’ 이다. ‘할 수 있겠나?’ 라는 질문은 한 마디도 없다. 무조건 하지 않으면 deadline 을 맞출 수 없게되고.. 그건은 절대 용납할 수 없기 때문이다. 지금까지 단 한 번도 deadline 을 제대로 지켜본 적은 없다는 사실은 철저히 무시되고 있다.

물론 이것이 팀의 생산성과 개발자들의 현재 업무 부하량이 잘 반영된 합리적인 요청이라면 아무 문제가 없다. 이런 요청이 한 사람으로부터 일괄되게 하달된다면 역시 양호한 편이라 생각한다. 지금 자판을 두드리는 이유는? 당연히 우리 팀은 이와 거리가 멀음을 의미한다. 멀어도 너무 멀다.

정량적인 생산성 측정은 전혀 시도조차 해본 적 없고, 개발자들의 현 업무량도 전혀 알 수 없다. 요청도 여러 사람에 의해 산발적으로 하달된다. 최우선으로 처리해달라는 요청이 심할 땐 하루에도 몇 번씩 날아오니, 개발자들은 자신의 하루 일과를 스케줄링하는 것 조차 쉽지 않다.

또한 ‘이번 릴리즈는 목표는 토요일 저녁이다’, ’릴리즈가 저녁 x 시쯤 될 예정이니 개발자들은 퇴근하지 말고 대기하라’와 같은 메일도 자주 접하고 있다. ‘늦은 저녁(혹은 주말)까지 일을 시켜서 미안하다’ 라는 사과의 말은 전혀 없다. 야근과 주말 근무를 당연하게 생각하는 것인지, 모두 똑같이 일하고 있으니 미안할 게 없다는 뜻인지, 프로젝트 성공을 위해선 개인 생활을 희생하는 것이 프로답다고 생각하는 것인지.. 이심전심으로 다 통할 거라고 생각하는지.. 도통 알 수가 없다.

그간 여러 차례에 걸쳐 검증된 프로세스와 툴 등을 소개하고 마인드 변화를 촉구해보기도 하였으나 이러저런 이유들도 팀의 이런 개발 문화는 꿈쩍도 안하고 있다. 새로운 것을 시도하기엔 deadline 이 너무 촉박해서일지.. 단순히 게을러서인지.. 배우는 재미를 잊어버렸을 만큼 심신이 지쳐버린 것인지.. 개개인의 속내야 알 수 없지만, 이들이 모여 실패를 거듭하면서도 뒤는 커녕 옆도 돌아보지 않고 코앞의 목표만 향해 달리는 보수적인 집단을 만들어 냈다.

Deadline-Driven Development (DDD) 의 전형적인 모습을 내가 속한 팀에서 보고 있으니 답답한 마음이 이루 말할 수 없다.


References

  1. Origin of DDD
  2. More refined (but still in draft) version of DDD
Recommended Steps for Refactoring
Oct 29th, 2009 by Wegra Lee

최근 다른 사람이 작성한 소스를 리뷰하면서 리팩토링할 일이 있었다. 깊이 있는 리팩토링까지는 해보지 못했으나, 남의 코드 리팩토링은 오랫만이라 간단히 노하우를 정리해본다.

정체를 알 수 없는 임의의 소스 덩어리를 받게 된다면, 대략 아래와 같은 순서로 리팩토링하는 것이 효율적이다.

1. Make duplications

리팩토링의 첫 단계에서는 중복 코드를 생산해낸다. 헐~! 이게 뭔 소린가? 중복 코드를 만드는 데는 조건이 있다. 로직의 상당 부분이 동일 혹은 유사해야 한다.

코드를 살펴보면, 결국 똑같은 혹은 유사한 일을 하면서 따로 노는 모습을 심심치 않게 발견할 수 있다. 각 파트별 담당 개발자가 선호하는 방식이 달라서일 수도 있고, 같은 개발자더라도 나중에 더 나은 API를 찾거나 더 간소한 알고리즘이 떠올랐을 수도 있다. 혹은 전에 짰던 부분과 흡사하다는 걸 떠올리지 못한체 처음부터 다시 짤 경우도 같은 결과가 나타난다.

코드가 척 보기에도 너무 다르다면 눈썰미가 본좌급이거나 운이 좋아야 발견할 수 있다. 따라서 누구나 기계적으로 할 수 있는 방법을 알아보자. 바로 이미 유사한 코드를 찾아서, 동일한 로직으로 만들 수 있는지 보는 것이다. 시장에는 중복 코드를 찾아주는 툴들이 이미 많이 나와있다. 이들 중 더 발전된 것은 유사 코드를 찾아주기도 한다. Java 라면 PMD 나 CheckStyle 같은 툴을 기본으로 사용하고 있으리라 믿는다. 이들 툴의 여러 기능중 duplicated code 검출 기능도 있으니 이를 활용하자. C/C++ 의 경우 언어 한계상 지원 툴이 상당히 빈약한데.. 다행히 위의 PMD 가 C++ 역시 지원해준다. 사용법은 여기를 참조하기 바라며.. 본인도 이를 이용해 작업을 진행하였다. 버그는 좀 보이지만, 간단히 사용하기에는 부족하지 않다.

결과: 같은 일을 처리하는 코드는 모두 동일하게 작성되었다.

2. Remove duplications

다음 단계가 바로 1단계에서 만들어 놓은 (혹은 그 전부터 존재하던) 중복 코드 제거이다. 코드가 중복되어 있다면 리팩토링도 중복으로 해야하고, 각각의 리팩토링 과정을 완전히 동일하게 하기는 상당히 말처럼 쉽지 않다. 중복 코드를 개별적으로 수정하면, 중복된 코드라는 것 자체를 인지하기 어려워진다. 각 코드 블럭의 리팩토링 순간 사이에 시간적 격차가 있으므로, 같은 로직을 보더라도 다르게 리팩토링할 가능성이 생긴다(기계가 아닌 사람인지라). 논리적으로 똑같이 하려해도 human error 가 발생할 여지도 다분하다.

중복 코드 식별 역시 ‘다행히도’ 사람이 하기엔 너무나 벅찬 일이다. 그래서 툴이 필요한데, 1단계에서 사용한 툴들이 바로 그들이다.

결과: 모든 코드는 unique 하다.

(곧 별도의 글을 통해 중복 코드 제거를 위한 몇 가지 패턴은 선보이도록 하겠다.)

3. Remove unused code (variable, code block, method, class, etc)

사용되지 않는 코드는 분석 중 논리 흐름을 방해하며, 자칫 의미 없는 코드를 리팩토링하며 시간을 낭비하게 된다.

대부분 범용 언어는 툴이 잘 지원해주고 있으나, 검출 범위와 사용성은 편차가 좀 있는 편이니 자신의 환경에 접목 가능한 툴들을 한 번 쯤 조사해보는 것을 추천한다.

결과: 모든 코드는 의미를 갖는다.

4. Reformat and rename

코드의 기초 가독성을 높이는 작업이다. 맞춤법에 맞게 코드를 수정하고(reformating), 의미가 명확히 통하는 용어를 사용하게 한다(renaming). Renaming 의 대상은 변수명, (내부) 메서드/클래스명 등이다.

결과: 코드는 의미가 명확한 단위 요소로 구성된다.

5. Refine logic (including extract/inline method)

코드의 논리 흐름을 가다듬는 단계이다. 작문에 비유해보자. 쉬운 용어들을 사용하더라도 산만하거나 애매모호한 글에선 핵심을 찾기 어렵다. 반면 논리 정연한 글은 하고자 하는 바를 쉽게 이해할 수 있다. 따라서 그 논리에 결점이 있다면 바로 파악하여 수정할 수 있고, 논리를 수정하거나, 설명을 보강하는데도 용이하다.

이 과정에서는  이어진 긴 문장을 의미가 분명한 적절한 단위로 나누거나, 큰 문단을 통채로 하나의 추상적 문장으로 교체(extract method)하고, if/else/switch 등으로 복잡해진 흐름을 같은 의미의 더 간결한 논리로 수정하는 등의 작업이 이루어진다. 최종 목표는 주석 없이도 글을 읽듯이 코드를 술술 읽을 수 있도록 하는 것이다.

결과: 코드를 자연스럽게 읽을 수 있다.

Refactoring Home Page 에 가면 수많은 리팩토링 기법들을 찾을 수 있다. 관리자인 Martin Fowler 도 양해를 구하고 있듯이, 설명과 관리에 그리 많은 신경을 쓰고 있진 않지만, 틈틈히 살펴보면 제법 도움이 될 것이다. 내 나름의 기법과 함께 위의 각 단계에서 많이 쓰임직한 것들을 묶어서 정리해보는 것도 재미있을 듯하니, 나중에 시간이 나면 한 번 시도해봐야겠다.

Grand Central Dispatch ported on FreeBSD
Oct 14th, 2009 by Wegra Lee

Grand Central Dispatch 가 벌써 타 OS 에 포팅되었다. 대상은, OS X 와 가장 가까운 친척인 FreeBSD. FreeBSD 는 CLang 도입에도 적극적이고.. 여러모로 Apple 과 친한 사이로 보인다.

하지만 마이너 OS 인 FreeBSD 보다는, 리눅스 진영이 이를 받아들이느냐가 훨씬 큰 관심사다.  OS X 이 데스크탑/서버 분야에서는 그리 대중적이지 못하고, iPhone/iPod touch를 필두로 세를 확장 중인 모바일 시장은 GCD 의 잇점을 제대로 살리기에는 아직 몇 년이 더 필요하다. 뿐만 아니라, 최근 Gartner 의 전망치에서도 보듯, 모바일에서도 iPhone 은 몇 년 내에 Linux 기반인 Android 에 점유율 역전을 당할 가능성이 높다.

아래는 FreeBSD 의 분기 진행상황 리포트에서 발췌해온 내용이다. 내용에서도 나와있지만 배포본에서는 당장은 볼 수 없고.. 8.1 버전 정도가 나오면 접해볼 수 있을 듯 하다.

Grand Central Dispatch – FreeBSD port

URL: http://libdispatch.macosforge.org/

Contact: Robert Watson <rwatson@FreeBSD.org>
Contact: Stacey Son <sson@FreeBSD.org>
Contact: libdispatch mailing list <libdispatch-dev@lists.macosforge.org>

We have ported libdispatch, Apple’s Grand Central Dispatch event and concurrency framework to FreeBSD:

  • Added new kqueue primitives required to support GCD, such as EVFILT_USER and EV_TRIGGER
  • Created autoconf and automake build framework for libdispatch
  • Modified libdispatch to use POSIX semaphores instead of Mach semaphores
  • Adapted libdispatch to use portable POSIX time routines

Jordan Hubbard has also prepared a blocks-aware clang compiler package for FreeBSD. When compiled with clang, libdispatch provides blocks-based, as well as function-based callbacks.

The port was presented at the FreeBSD Developer Summit in Cambridge, UK in September, and slides are online on the devsummit wiki page. A FreeBSD port is now available in the Ports Collection. After FreeBSD 8.0-RELEASE has shipped, the new kqueue primitives will be MFC’d so that libdispatch works out of the box on FreeBSD 8.1-RELEASE.

Open tasks:

  1. Complete porting of libdispatch test suite to FreeBSD.
  2. Investigate pthread work queue implementation for FreeBSD.
  3. Evaluate performance impact of some machine-dependent and OS-dependent optimizations present in the Mac OS X version of libdispatch to decide if they should be done for other platforms and OS’s.
  4. Explore whether FreeBSD base operating system tools would benefit from being modified to use libdispatch.
Google Wave on iPhone/Android
Oct 14th, 2009 by Wegra Lee

Google Wave 가 벌써부터 iPhone/Android 에서 돌고 있단다. (Google Wave’s Little Secret: It Already Works On The iPhone)

역시 구글!!! 아래는 돌고 있는 모습(왼쪽부터 App Mode, Safari 에서 직접 접속시).. 완성도도 높은 듯.. ^^

계정 신청한 것 묵묵부답인데.. 빨리 초대를 해주거나 서비스가 정식 오픈 되었으면 좋겠다.

eyeOS on iPhone/iPod touch
Oct 14th, 2009 by Wegra Lee

eyeOS is a sort of Web-based cloud OS. Once you make an account and log in, you can see a desktop environment inside your browser. It looks like the following.

Yesterday, I suddenly wondered how it’ll look like on the Safari on my iPod touch. So I logged in, and it turned out they had customized its interface for iPhone already. As you can see through the below images, it’s just an browsing application heavily based on list-style interface. Not that amazing at all. I gave them 7 out of 10, because they are at least considering mobile users. I’ll be fantastic if it can provide the Palm WebOS-like interface.

Main Menu Files Folder News Reader RSS

iPhone App Design Trends
Oct 12th, 2009 by Wegra Lee

여기 깔끔 상콤한 iPhone App 디자인들을 보시라~

초기에 아이폰의 기본 UI & 가이드를 따라 만들던 천편일률적 디자인, 혹은 기존 다 모바일 어플의 단순 포팅에서 확실히 진화된 모습을 보이고 있다. 이제 기본 UI Control 들만 가지고 만든 것들은 오히려 구식 어플들로 보일 지경이다.

몇 가지 이미지만 가져와본다. (일부는 직접 추가.. 어플 이름은 마우스를 올려놓으면 나옮. 그리고.. 그림은 AppShopper 에서 가져왔다.)

개인적으론 이 앱들의 디자인도 좋아한다.

Developer Capacities – Comment or not comment
Oct 7th, 2009 by Wegra Lee

(특히) 팀으로써 소프트웨어를 개발하다보면 주석을 잘 달라는 이야기를 자주 듣는다. 하지만 반대로 주석이 필요없는 코드를 짜라는 이야기 역시 심심치 않게 들려온다. 얼핏 생각하기엔 서로 모순되는 주장 같기도 한 두 가이드들에 대해  정확히 이해해보고, 또 좋은 주석을 달기 위한 팁과 고려 사항들까지 일부 정리해보도록 하겠다.

주석의 역사

이야기를 시작하기 전에 주석에는 어떤 종류가 있는지부터 명확히 해야 하는데, 주석의 역사에서 시작하는 것이 자연스러울듯 하다.

놀랍게도(?) 태초의 소프트웨어 코드에는 주석이란 개념이 아얘 없었다. 그도 그럴 것이 종이카드에 0011000 구멍 뚫어서 프로그램하던 시절에 주석을 삽입한다는 것은 사치일뿐 아니라 기술적인 도적이었다. ^^ 이 시절 펜으로 종이 위에 이것저것 적어놓던 것이 주석의 시작이라고 보면 된다. (사실 이 부분은 직접 경험해보진 않아서 추측성임)

컴파일러(사실 전처리기)가 주석을 인식하기 시작한 것은 당연히 소스 코드를 디지털화시킨 이후이다. 이마저도 처음엔 지금과 같은 형태는 아니었다. 초창기 언어들은 주로 line by line 으로 해석되었기 때문에 주석 역시 single-line 형태가 먼저 등장했다. 복잡한 인터페이스 설명이나 알고리즘 설명 같은 것보다는 영역/블록 구분과 간단한 커맨트 중심이어서 그리 불편하지 않았다. 그 후 등장한 multi-line 주석은 편집 편의성 증대를 위한 욕구 해결 정도여서 전혀 신선하지도 혁신적이지도 않았다.

Java가 등장하면서 (최초인지는 모름) API 문서 생성 ‘표준’ 툴(Javadoc)을 SDK 가 내장하기 시작하였고, 이는 주석의 개념을 한 단개 발전(not 혁신)시키는 계기가 되었다. Javadoc 의 특징이라면 ‘스펙 기술용 주석‘과 ‘구현 설명용 주석‘을 명백히 구분하기 시작한 것이다. 물론 그 전부터 주석을 구분해 사용하고는 있었지만, 언어의 표준적인 방식으로 도입했다는 것이 큰 의미가 있다.

이를 계기로 주석에 대한 인식은 한층 개선하였고, 그 후 등장하는 대부분의 언어들도 같은 어프로치를 취하게 되었다. 하지만 아직까지 컴파일러는 스펙/구현 가리지 않고 모든 주석을 무시하였고, 스펙을 얻어내려면 별도의 툴을 돌려야만 하였다. 이는 ‘스펙 기술’ 이라는 오늘날에 있어 아주 중대한 개념을 ‘주석’ 이라는 사소한 범주에 함께 묶는 한계에서 아직 벗어나지 못했음을 의미한다.

이에 대한 개선은 최근 Noop 언어 프로젝트를 통해 가시화되고 있다. Noop 의 여러 특징 중 ‘Executable documentation that’s never out-of-date’ 는 주석을 프로그래밍 언어 스펙에 포함시키고 컴파일러가 컴파일 워닝/에러와 같은 수준에서 직접 핸들링한다는 의미이다. 형식적으로는 거의 변화가 없지만, 주석의 위상은 거의 코드 수준까지 격상되게 된다.

나아가 annotation 이라는 개념이 추가된다. Annotation 을 주석으로 한데 묶는데는 의 아해할 사람들이 있을 수 있겠으나, 수행 코드가 아니라는 점에서 주석의 범주에 속한다. 더구나 annotation 의 한글 해석 자체가 ‘주석( 달기)’이다. ^^ (Noop 에서 annotation 을 어떻게 처리할 지는 명시적인 언급은 없다.)

주석의 중요성이 점차 커지는 것은 소프트웨어 산업의 변화 과정을 봤을 때 아주 자연스러운 결과이다. 개인이 다룰 수 있던 작은 소프트웨어에서, 이제는 수백 수천명이 수년에 걸쳐 만들고, 완전히 없어지기까지 또 수년이 더 필요한 수준까지 변화하였기 때문에, 공간과 시간을 초월한 개발자간의 커뮤니케이션이 그만큼 중요해진 것이다.

주석의 분류

이쯤에서 현재 우리가 주석이라 부를 수 있는 것들에는 어떠한 것들이 있는지 다시 정리해보자.

  • 문서화 주석 – API 명세(specification) 기술을 주목적으로 하며, 해당 소프트웨어를 black box 로 바라보는 제3의 개발자와의 커뮤니케이션을 담당한다.
  • Annotation 주석 – 코드를 처리하는 툴들에게 특정 지시를 내리는 주석으로, 이를 인식할 수 있는 툴에게만 의미가 있다. 툴의 목적에 따라 다양한 용도로 응용될 수 있다.
    또한 팀원간에 정해진 약속으로 사용하기도 좋다. 대표적인 사례로는 @todo @fixme 같은 것이 있다.
  • 구현 주석 – 내부 구현에 대한 주석으로 여타의 툴들에서는 완전히 무시된다. 이해하기 어려운 코드에 대한 설명, 추가로 해야할 일, 코드 수정 시 주의점 등, 코드 레벨에서 직접 봐야하는 개발자들 간의 디테일하고, 종종 자질구레한 커뮤니케이션을 담당한다.

이처럼 현재까지는 크게 3 가지의 대표적인 주석이 있으며, 소프트웨어 산업이 변화하면서 앞으로도 기존 주석이 변화/갈라지거나 새로운 형태의 주석이 추가될 것이다.

상세한 주석 vs. 주석이 필요 없는 코드

“상세한 주석이 좋다.” – 주로 문서화 주석에 해당하는 지침이다. 제공하는 소프트웨어 모듈의 동작 명세는 가능한 모든 케이스에 대해 명확하게 설명해 주는 것이 좋다.

“주석이 필요 없도록 코딩하라.” – 주로 구현 주석에 해당하는 지침이다. 구현 주석이 있다는 것은 코드만으론 의미 전달이 불충분하다는 반증이므로, 가능한 코드를 명확히 작성하여 구현 주석 없이 읽고 이해할 수 있게 하는 것이 좋다.

보통은 위와 같이 받아들이면 되지만, 반대의 경우도 얼마든지 있다.

문서화 주석이 최소화 되도록 코딩하라.” – 이는 문서화 주석을 생략하라는 의미보다, ‘문서화 주석에서 군더더기 설명이 필요 없도록 API 를 명확하게 만들라’ 정도로 이해해야 한다. 문서 없이 API 만 봤을 때 오해의 소지가 있다거나, 다양한 예외 상황이 존재하거나, 한 API 를 너무 다목적으로 사용할 수 있다거나, pre/post 조건을 주렁주렁 달고 있는 API 들은 이 가이드를 제대로 지키지 못한 예들이다.

“상세한 구현 주석이 좋다” – 어쩔 수 없이 구현 주석이 필요할 시에는 명확하고 상세한 설명을 달라는 의미이다. 최적화를 위해 어쩔 수 없이 복잡한 코드를 작성했다거나, 컨트롤 밖에 있는 외부 종속성 때문에 비효율적인 구조를 가져갈 수 밖에 없었다거나, 일정 등의 이유로 임시 코드를 넣어놨거나 일부 기능을 구현해놓지 않은 상황에서는 상세한 주석을 달아주어야 한다. (이 주석을 보게될 사람이 자신뿐이라는 가정은 절대 하지 말라.)

좋은 주석 작성을 위한 팁

좋은 주석 작성 팁까지 집대성 해놓으면 최고의 글이 되겠지만.. 이 글의 범주에서는 제외하도록 하겠다. (다른 누군가 집대성 해주시거나, 이미 잘 되어 있는 좋은 링크들을 보내주시면 해피할텐데 ㅎ)

  • 문서화 주석 작성에 대한 가이드는 표준화 단체에서 공개하고 있는 것이 많이 있다. 적어도 문서화가 잘 된 유명 플랫폼/라이브러리 등은 찾을 수 있다. 자신의 도메인과 가장 유사한 가이드를 찾아 적용해보는 것은 좋은 시작이 될 것이다. (e.g. Requirements for Writing Java API Specifications)
  • Annotation 주석 활용 – 같은 목적의 주석들에 동일 키워드를 사용하는 방법으로, annotation 이 정식으로 지원되지 않더라도 전혀 문제는 없다. 가장 추상화된 @todo (더 해야할 일) 부터 시작해서 @fixme (명백한 결함), @review (리뷰 커맨트), @pending (미결사항), @thread (스레드 안정성 보장 필요), @dependon (특정 기능/이슈 종속적 – 해당 기능/이슈 해결 후 일괄 검토 요구) 등 상황에 따라 적절히 응용하면 최소한의 주석으로 커뮤니케이션 효과를 극대화시킬 수 있다.
  • Aspect 를 고려한 코드 영역 구분 – 코드를 작성하다 보면 로그 작성, 접근 권한 체크, 멀티 스레딩을 위한 락 처리, 에러 처리, 부하 조정, 캐시 사용 등등 비즈니스 로직과 직접적으로 관련되지 않은 로직들로 코드가 지저분해지기 쉽다. 이 문제를 다루기 위해 Aspect Oriented 언어를 사용하는 방법도 있지만, 여건이 되지 않는 경우엔 어쩔 수 없이 모든 로직을 한데 몰아 두어야 한다. 이럴 때에는 아쉬운데로 부가적인 로직 처리 블럭과 비즈니스 로직 블럭을 구분해주는 안을 적용해볼 수 있다. 동일 룰이 코드 전반에 일괄적으로 적용되어 있다면, 코드를 보는 사람들은 목적에 맞는 코드 블럭만 정확히 찾아 검토할 수 있다.
    영역 구분을 위한 구현 주석이 필요할 수도 있지만, 그 외 구현 주석의 필요성을 감소시켜주는 효과가 있다.
  • 예외 처리 코드 주의 – 한 눈에 들어올 간단한 로직도 과도한 예외 처리가 가미되면 금새 난해한 코드로 둔갑한다. (필요악이라 할 수 있는 예외에 대한 다양하고 심도있는 관점은 C++ Exceptions: Pros and Cons 을 참조하기 바란다.) 가장 선행되어야 하는 노력은 물론 ‘불필요한 예외가 발생하지 않도록 설계’하는 것이고, 꼭 필요한 예외에 대해서 일반 로직과 명확히 구분되는 형태로 처리해주는 것이 좋다. 예를 들어 예외 발생 여부 확인을 위해 전용 매크로를 정의해 ‘if’ 절을 사용을 피하는 것도 한 방법이다. ‘if’ 절은 일반 로직에서도 등장하기 때문에 로직을 따라가다 rollback 하여 다시 시작하게 만든다.
  • 읽을 수 있는 코드 작성 – 당연하지만 너무 일반적인 가이드이다. 수많은 종속 팁들이 있을 수 있지만 너무 길어질듯 하여 생략한다. (Developer Capacities – Writing Program 참조)

결론

주석을 주석으로만 취급하는 시대는 끝났다(끝내야 한다^^). 하지만 아직도 대부분의 개발자들 주석에 대한 인식은 가볍기만 하고, 진정한 가치와 중요성을  제대로 교육/훈련시키는 모습은 찾아보기 쉽지 않다.

이제부터라도 주석과 관련한 명확한 개념 정리와, 용도별 좋은 주석 작성을 위한 가이드를 정리해 소프트웨어 입문 초기부터 익히고 생활화할 수 있도록 지도해야 한다. 지금과 같은 소셜 개발 시대에서 훌륭한 개발자가 되려면 시공간을 넘나드는 4차원적인 커뮤니케이션 능력도 갖춰야 한다.

SCRUM in Under 10 Minutes
Oct 5th, 2009 by Wegra Lee

스크럼의 기본을 짧은 시간 안에 아주 잘 명쾌하게 설명하고 있는 자료 중 하나이다.
전통적인 방식에만 익숙해 있던 사람들에겐 이것만으론 스크럼의 정신과 진정한 가치를 깨닫게 하기엔 턱없이 부족하겠지만, 애자일에 관심이 있고 또 어느 정도 스크럼을 접해본 사람들에겐 개념 정리에 도움이 될 것이다.

Leader vs. Manager
Oct 5th, 2009 by Wegra Lee

내가 생각하는 리더와 관리자의 차이이다.

리더

  1. 팀원들을 올바른 길로 이끌어 과제를 성공하게 만든다.
  2. 팀원들이 겪고 있는 난제를 파악하여 해결해준다.
  3. 모든 일에 솔선수범하여 팀원들이 자신을 보고 배울수 있게 한다.
  4. 일하는 방식, 일 분배 등에 있어 항시 팀원의 역량 향상을 고려한다.
  5. 가능한 일정과 그 이유를 개발자에게 묻고, 더 빨리/효율적으로 끝낼 수 있는 방법이 있을지 함께 상의한다.

관리자

  1. 과제를 성공시키기 위해 팀원들을 조직/관리한다.
  2. 팀원들에게 일을 분배하고 해결토록 한다.
  3. 관리자가 하는 일과 팀원이 하는 일을 구분짓는다.
  4. 필요한 일에 가장 적합한 역량을 보유한 팀원에게 해당 일을 맡긴다.
    (개인의 역량 향상은 개인의 몫이다.)
  5. 촉박한 일정을 주고 기간내에 끝내라고 압박한다.

또 무엇이 있을까.. 생각날 때마다 천천히 업데이트 해야겠다.

하루 빨리 관리자가 줄고 리더가 많아진 세상에서 개발자들이 일할 수 있는 세상이 왔으면 좋겠다. 그를 위해선 현재의 개발자들이 관리자가 아닌 리더로써의 자신을 만들어가겠다는 마음 가짐을 잊지 말고 성취를 위한 노력을 게을리 하지 말아야 한다.

»  Substance: WordPress   »  Style: Ahren Ahimsa