http://www.yes24.com/24/goods/19285525


가끔 개발 프로세스에 대해서 찾아본다. 폭포수 개발 방법론과 애자일. 공공 시스템 SI 같은 큰 프로젝트를 경험하지 못해서인지 폭포수 개발 방법을 직접 경험하지는 못했다. 충분한 자원을 가지고 절차에 따라서 개발 프로세스를 진행한다면 맞는 방법이라고 생각하지만, 작은 프로젝트에, 주로 개발 진척을 관리하기 위해 실제 자원을 분배하지도 않고 문서를 작성하라거나 기타 산출물을 작성하라는 프로세스만을 경험하면서 개발 프로세스자체를 믿지 못하고 있다.

작은 팀으로 일하는 것을 좋아하고, 서로간에 소통이 중요하다 생각하기 때문에 스크럼 개발 방법론은 좋아 보인다. 물론 철학을 가지고 접근하는 것도 좋게 생각된다. 제품 백로그와 비전을 연결지어 설명하고, Self organized하며 비전문화 팀을 목표로 하는 것도 눈에 들어온다. 기회가 된다면 경험해 보고 싶은 개발 방법론이다.

반응형

'책들' 카테고리의 다른 글

[독서] 대한민국 독서혁명  (0) 2018.03.09
[독서] 이오덕 우리글 바로쓰기 1  (0) 2018.02.22
[독서] 찰스 핸디의 포트폴리오 인생  (0) 2018.01.16
[독서] 혼자회의  (0) 2017.12.10
[독서] 3001 최후의 오디세이  (0) 2017.11.01

"눈은 두개인데 왜 하나로 보이지?"라는 이쁜 딸의 질문을 받고, 엉뚱하게도 다른 생각을 해봅니다. 어떤 진화를 거쳐서 사람 눈이 두개뿐인지 이유는 모릅니다. 그런데 "효율"과 "현실적인 타협"이 그중 하나로 생각됩니다. 주위를 더 경계하기 위해 보다 많은 눈과 넓은 시야를 가지는 것은 생존에 도움이 될지 모릅니다. (이것은 반박하기 어려운 사실) 하지만 더 많은 눈에서 들어온 정보를 실시간으로 처리하기 위해서는 보다 많은 에너지가 필요할테지만, 이 에너지를 "현실"의 몸이 제공하는데는 한계가 있을 겁니다. 즉, 눈이 두개인 이유는 "현실"적인 몸이 제공 가능한 에너지 범위안에서 거리 감각을 가지면서도 가능한 넓은 시야를 가지기 위해 "현실적인 타협"을 한 결과라는 생각입니다.


꿈꾸는 듯한 말만을 하는 사람들이 있습니다. 문서는 모두 준비되어야 하고, 고객의 요구는 모두 들어줘야 하며, 한번 release한 code에는 bug가 없어야 하지 않겠냐는 것입니다. 말만 보자면 틀리진 않겠죠. 설계 단계에서 충분한 문서를 작성하고, 설계를 기준으로 코드를 작성하며, 코드를 배포 전에 충분한 시험을 해서 치명적인 bug는 없어야 하겠지요. 맞는 말입니다. 더구나 낮은 지위에 있는 엔지니어라면 이런 "틀리지 않은" 지시를 반박하기 어렵습니다. 마음속으로도 반박할 수 없어서, 뒤돌아서며 "맞는 말이잖아"라고 스스로 말해 보기도 합니다. 틀리지 않지만 정말 맞을까 하는 뭔가 찝찝한 기분.


사람의 눈이 두개인 이유를 다시 생각해 봅니다. 두 눈을 사용하는 것에 비해, 많은 눈을 가지는 것은 넓은 시야를 갖게 하며, 위험에 대비할 수 있다는 면에서는 맞는 것이라 할 수 있겠습니다. 그러나 실제로는 너무 많은 에너지를 사용해서 다른 곳에 에너지를 사용하지 못하게 한다는 면에서는 "맞지 않은" 것이기도 합니다. 


그들은 우리와는 다른 "현실"에서 살고 있는 것이며, 한정된 리소스만을 가지는 현실에 있는 우리 입장에서는 결코 그들의 인식이 "맞는"말을 하는 것이 아닌 것입니다. 

반응형

'소소한 생각들' 카테고리의 다른 글

메모 프로그램들  (0) 2022.04.03
[차이나는 클라스] 인생수업 05 - 20221024  (0) 2021.11.21
이세돌과 알파고  (0) 2018.04.11
미야자키 하야오의 끝나지 않은 이야기  (0) 2018.03.26
[영화] 부라더  (0) 2017.12.31

Code Tells You How, Comments Tell You Why


18 Dec 2006


"코드 주석에 대한 철학"이라는 이전 포스트에서 말했듯이, 최고의 코드 주석이란 사용할 필요가 없는 코드 주석(이하 주석)이다.. 다시 한번 강조해서 말하자면, 주석 없이도 이해가 가능한 간단한 코드를 작성하도록 노력해야 한다. 코드로는 쉽게 이해하기 어려운 곳에만 주석을 추가하도록 한다.


이렇게 함으로써 청중을 의식하고 코드를 작성할 수 있다. 1985년에 발간된 고전인 "Structure and Interpretation of Computer Programs"의 서문에서도 이를 올바르게 지적하고 있다.


프로그램은 사람들이 읽을 수 있도록 작성되어야 하며, 단지 부수적으로 기계가 실행할 수 있어야 한다.


Knuth는 그의 1984년 고전적 에세이인 LiterateProgramming(pdf)에서 유사한 의견을 다루고 있다.


프로그램 작성에 대한 우리의 전통적인 태도를 바꾸어 보자 : 우리의 주된 목표가 컴퓨터가 무엇을 할 것인지를 지시하는 것이 아니라, 컴퓨터가 어떻게 동작하기를 원하는지를 인간에게 설명하는 것에 집중해 보자.


"literate programming"를 실천하는 사람은 수필가라고 할 수 있는데, 그들의 주된 관심사는 상세한 설명과 문체의 탁월함이다. 이런 저자는 유의어 사전을 항상 손에 쥐고, 매우 신중하게 변수의 의미를 설명할 수 있는 변수명을 고른다. 저자는 서로를 보강하는 공식적이고 비공식적 방법을 섞어 가면서, 인간이 이해하기 가장 좋은 순서로 개념을 소개함으로써 알기 쉬운 프로그램을 작성하기 위해서 노력한다.


당신 코드의 첫번째 소비자는 다른 프로그래머이고, 컴파일러는 그 다음이라고 생각하고 코드를 작성한다면, 부가적인 코드 주석의 필요성은 크게 줄어들 것이다. "using comments as a crutch"는 매우 훌륭한 설명이다.


이것은 몇년간 양산에 적용된 자금이 풍부한, 폐쇠형 source 시스템에서 가져온 코드의 snippet이다.

float _x = abs(x - deviceInfo->position.x) / scale;
int directionCode;
if (0 < _x & x != deviceInfo->position.x) {
    if (0 > x - deviceInfo->position.x) {
        directionCode = 0x04 /*left*/;
    } else if (0 < x - deviceInfo->position.x) {
        directionCode = 0x02 /*right*/;
    }
}

아래 코드는 위와 동일하지만, 버그를 수정하고 보다 읽기 쉽게 바꾼 것이다.

static const int DIRECTIONCODE_RIGHT = 0x02;
static const int DIRECTIONCODE_LEFT = 0x04;
static const int DIRECTIONCODE_NONE = 0x00;

int oldX = deviceInfo->position.x;
int directionCode = (x > oldX)? DIRECTIONCODE_RIGHT
                  : (x < oldX)? DIRECTIONCODE_LEFT
                  : DIRECTIONCODE_NONE;

주석이 많다고 더 읽기 쉬운 코드는 아니다. 위 예에서는 그렇지 않았다. 위 코드에서의 주석은 - 당신이 이미 알아차렸더라도 - 코드를 보다 복잡하게 할 뿐이다. 때로는 적은 주석이 보다 읽기 쉬운 코드를 만든다. 특히 주석 대신 의미 있는 심볼명을 사용한다면 말이다.


주석을 사용하지 않도록 개정하고 단순화할 수 있는 거의 무한한 기회가 있지만, 주석 없이 코드만으로 설명하는데는 한계가 있다.


코드가 아무리 간단하고, 간결하고, 명확하더라도, 코드가 완전히 스스로 문서를 대체할 수는 없다. 코드만으로 주석을 대체할 수는 없다. Jef Raskin의 말을 들어보자.


코드는 프로그램이 왜 작성되었는지, 이 방법 혹은 저 방법을 선택한 논리적 이유는 무엇인지는 설명할 수 없다. 코드는 여러 가지 대안 중에서 특정 방법이 선택된 이유를 설명할 수 없다. 예를 들면,

/* A binary search turned out to be slower than the Boyer-Moore algorithm for the data sets of interest, thus we have used the more complex, but faster method even though this problem does not at first seem amenable to a string search technique. */

어떤 개발자에게는 완벽하게 명백한 것이라도, 맥락을 모르는 다른 개발자에게는 전혀 이해하기 어려울 수 있다. 다음과 같은 주석에 대한 조언을 생각해 보자.


아마 아래와 같은 코드는 쉽게 잘 알것이다.


$string = join('',reverse(split('',$string)));


문장을 역전시키는 것. 하지만 아래와 같은 문구(주석)를 Perl에 넣는 것이 어려울까?


# Reverse the string

사실 전혀 어렵지 않다. 코드는 어떻게(How) 프로그램 동작하는지를 설명하고, 주석은 왜(Why) 동작하는지를 설명하도록 하면 된다. 이를 헷갈리지 않으면 된다.


Written by Jeff Atwood

Indoor enthusiast. Co-founder of Stack Overflow and Discourse. Disclaimer: I have no idea what I'm talking about. Find me here: http://twitter.com/codinghorror




원본 링크 : https://blog.codinghorror.com/code-tells-you-how-comments-tell-you-why/


* 다소 의역한 부분도 있으므로 정확하지 않을 수 있습니다. 원본 번역에 문제를 알려 주시면 내리도록 하겠습니다.

반응형

'번역' 카테고리의 다른 글

[번역] Python Success Stories  (0) 2018.01.23

+ Recent posts