소스를 이해하고 이해시키는 일에 대해

체스맨의 이미지

다른 사람이 작성한 소스를 보는 일은 그 소스가 잘 되어있든 그렇지 않든 항상 어렵다. 그러므로 개발자로서 남의 소스를 보며 느끼는 어려움을 그에 대한 맹목적 거부감으로 표출해서는 안된다.

어려움을 거부감으로 표현하기보다는 우선 개발자의 의도를 살피려는 노력이 필요하다. 오프라인으로 대면할 수 있는 개발자라면 상황은 한결 쉬울 것이다. 이러한 노력 없이 거부감 표출로 바로 진입하는 개발자들의 심중을 나는 어렵지 않게 판단할 수 있고, 내가 그 사람을 설득할 수 없다고 판단되면, 나 또한 그 반응에 대한 거부감을 표출할 수 밖에 없다. 특히 내가 좋아하지 않는 사람이라면 바로 그렇게 할 것이다.

소스 가독성이라는 건 부수적인 문제라고 생각한다. 나는 설명할 수 있는 소스를 작성해야 한다고 본다. 개발 의도, 아키텍쳐, 코딩 스타일, 구현 방법에 대해 모두 투명하게 설명할 수 있는 소스는 충분한 가독성을 갖게 되어있다. 다른 사람이 이해하기 쉬운 코드를 작성하기 위해 소스 가독성을 강조하는 글들을 종종 보지만 그것은 본질이 아니다. 다른 사람이 이해하려면 내가 이해시킬 수 있도록 설명할 수 있어야 한다. 그래서 소스를 살펴서 해당 개발자 자신도 적절히 설명할 수 없는 코드라고 판단되고, 어떠한 상황적 특수성도 없었다면 그것은 비난 받아야 한다.

다른 사람이 작성한 소스를 보는 것은 꾸준히 단련해야 하지만, 다양한 오픈 소스 프로젝트들을 다운로드 받아서 그 소스들을 살펴보면 항상 어렵다. 그 어려움을 쉽게 거부하지 않는 개발자가 좋다.

원본글

댓글

superkkt의 이미지

음.. 저만 어려운게 아니였군요.. 그나마 다행인건지 모르겠네요. 혼자 공부하면서 코딩 실력은 조금이나마 늘어난것 같은데 다른 사람의 코드를 보면 버벅거리기 시작하고 분석도 안되고.. 그래도 그것도 계속 해보니 세세한 내용까지는 파악을 못해도 전체적인 흐름은 알겠더군요.

======================
BLOG : http://superkkt.com

======================
BLOG : http://superkkt.com

yaru22의 이미지

제가 요즘 Azureus Source Code 를 다운 받아서 분석을 해보려고 하는데

양이 장난 아니게 많더라고요 ^^;; 뭐 기대했던거지만..

그런데 그런 프로젝트같은거 분석해보려면 그냥

소스에서부터 스크래치로 분석해야되나요?

아니면 프로젝트의 대강적인 흐름을 잡아주는

UML Diagram 이라든지...

Method 들 정리해 놓은 문서라던지...

그런게 있는건지요?

아직 학부 1학년생이라 큰 프로그램은 짜본 경험이 없어서

어디서 어떻게 시작해야할지 막막하네요...

힌트 주시면 감사하겠습니다. ^^

pinebud의 이미지

문서가 없을때 가끔씩은 vertically(?) 소스를 분석을 하는 것도 도움이 됩니다. 흥미가 있는 기능을 하나 찍어서 처음부터 끝까지 함수를 따라내려가 보면 됩니다. 에러 처러같은 것은 무시하고 제일 많이 사용되는 파라메터를 가정하는게 분석이 쉽습니다. 예를 들어 리눅스 네트워크 스택이 궁금하다면 디바이스 인터럽트부터 socket까지 따라가 볼수도 있고 상위 기능에서 제일 쉬워보이는 ping같은 것을 따라가 볼 수도 있겠죠..

A rose is a rose is a rose..

mach의 이미지

소설처럼...

어린 시절 동화책을 읽고, 나이를 들어감에 따라 다양한 책들을 보게됩니다.
때로는 유익한 서적이 있는가 하면, 별로 유익하지 않은 책들도 있습니다.
또한, 유익한 점은 그 양에 의존하는 것은 아닙니다.
대체로는 저자가(?) 그 글의 유익성을 어느정도 보장해 주기도 합니다.
때때로, 출판사가 이를 의미하기도 했습니다.
난이도는 어떤 책은 참으로 어려운 말들로 구성되어있기도 하고, 어떤 책은 너무 평이한 말로 구성되어 양만 많은 경우도 있습니다. 적절한 것이 무엇인가는 독자에게 달려있겠습니다만.

프로그램 소스를 바라볼때도 비슷한 맥락이 있다고 생각합니다.
보지도 않고 유익성을 찾아내기는 어렵지만, 적어도 전집(수권~) 을 읽어본 경험정도를 가져보는 것은 새로운 책/양에 대한 두려움을 접는데 보탬이 된다고 생각합니다.
...
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.

------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.

지리즈의 이미지

소스를 분석하는 것은 긴글의 소설을 읽는 것과 같습니다.
독후감을 쓰기 위해 소설을 읽는 요령과 정확히 같은 방식으로 읽어 내려가야 합니다. 그리고, 독후감을 쓰기 위해서 제일 먼저 해야하는 일은 줄거리를 이해하는 것입니다.

소스에서 줄거리라 함은 바로 그 프로그램이 근본적인 목적입니다.
즉 세세한 꾸밈이나 묘사(코드로 따지면 세부적인 기술구현)은 가감히 시야 밖으로 버리고, 핵심적인 이야기의 전개를 따라가는 요령이 필요하죠.

함수에서 함수로, 또는 파일에서 파일로...

책에서 스토리전개의 주요인물인 주인공이 있듯이,
소스에는 main함수가 있습니다.

우리의 주인공(main함수)가 어떻게 동작하는지를 빨리 파악하고,
이러한 프로그램의 거대한 줄기를 빠르게 이해하는 지 여부에 따라 프로그램의 파악여부는 달려있다고 해도 과언이 아닙니다.
매순간 주인공이 맞나는 많은 등장인물들(여기서는 function이나 코드들)이 이야기에 핵심적인 전개에 영향을 줄 것인지 그들의 첫인상만가지고 빠르게 판단하는 요령이 필요합니다.

보통은 거의 대부분은 예외처리이거나 혹은 구체적인 기능의 구현들입니다. 따라서 대부분 시야밖에 놓아 두어도 줄거리를 이해하는데는 크게 지장이 없습니다.
그리고, 스토리를 따라가다가 이해에 막히는 부분이 생기면,
되돌아가서 다시 확인하는 편이 일반적으로는 경제적 방법입니다.

너무 세세한 것에 억매이다가 보면, 큰 것을 보지 못하죠.
막대한 소스에도 바로 핵심이 되는 줄기는 있기 마련입니다.

그리고, 이 줄기를 휘어잡고, 나머지 살들을 붙여나가는 훈련이 좋은 소스의 이해자 그리고, 역으로 소스의 작성자가 되는 지름길이라고 생각합니다.

프로그래머로서의 제 신념은,
"잘쓰여진 소스보다 훌륭한 주석은 없다"입니다.

추가로 소스 분석하면서 느낀 것은,
"grep만큼 간단하고, 쓰기 편한 좋은 소스 분석도구는 없다"입니다

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

s.choi의 이미지

정확히 제 의견과 일치하네요. :-)
grep 보다는 cscope + vim 을 사용하니까 더 좋더라구요.
그래도, grep 이 더 간단하기는 하겠네요.

체스맨의 이미지

좋은 말씀 감사합니다.

이 글에서 저는 남의 소스를 이해하고 이해시키는 방법론적 측면보다는, 남의 소스를 읽는 자세에 대해 더 초점을 두었습니다.

좋은 툴과 방법론이 있음은 분명하지만, 남의 소스를 분석하는 일이 항상 "어렵다"는 느낌을 주는 것은 "당연"하기 때문에 어렵다는 것은 기정 사실로 두고, 그 느낌을 거부감으로 발전시키지 말았으면 하는 생각에서 글을 적어봤습니다. 주변 사람들과 같이 일을 하면서 다른 사람이 제 소스를 보며, 또한 제가 다른 사람의 소스를 보며 실수했던 부분을 반성해보고 싶었습니다.

요즘들어 자기의 생각을 피력하고 관철시키는 부분이 코딩하는 일보다 훨씬 어렵다는 것을 실감하는 터라서요...

아... 그리고 저는 "가독성" 보다는 "설명 가능"을 더 강조하고 싶습니다. ;)

Coral Library Project : http://coral.kldp.net
Orion Project : http://home.megapass.net/~heesc22/

Orion Project : http://orionids.org

creativeidler의 이미지

코드를 읽는데 가장 중요한 것은 '필요'가 아닐까 싶습니다. 그 소스를 내가 어떤 목적을 가지고 바꿔야 한다면 바꿔야 하는 부분을 빨리 찾아내서 그 부분을 이해하는 것, 그것이 가장 빠르게 소스에 다가가는 방법이겠죠. 이런 목적의식 없이 그냥 코드를 읽으면 재미도 없고 잘 이해도 안되죠. 거의 시간낭비가 될 가능성이...

그리고 설명가능성과 가독성은 다른 개념이지만 달성하려면 결국 같은 길을 가야 하는 게 아닌가 싶습니다. "의도가 드러나게 코딩하라"를 지키면 자연스럽게 acountability도 확보되고 readablility도 확보됩니다. 리팩토링이란 것도 결국 중복을 제거하는 것과 의도를 드러내는 것, 두 가지죠.

체스맨의 이미지

목적의식이 중요하다는데 동의합니다. 어떤 한 부분만 파고들어 빨리 파악해 냈다면 이미 그 소스를 이해하는 것은 시간 문제이기 때문이죠.

실제로 일을 하면서 있던 일입니다. "소스를 분석한다"라는 목적으로 소스를 분석하는 사람을 보았는데 적지 않은 시간을 보냈음에도 불구하고 자기가 무엇을 했고 얻었는지 잘 알지 못했습니다. 그래서 간단한 기능을 추가해보자 하고 거기에 관련된 설명에 들어간 후로 길지 않은 시간 내에 그것을 달성했고 무언가를 알게 된 느낌과 함께, 소스 분석 상태는 한결 좋아졌습니다.

그 다음, 설명 가능성과 가독성이 닭이냐 달걀이냐는 문제일 수도 있지요.

저도 별개의 문제는 아니라고 생각하기 때문에, 설명 가능하면 가독성은 따라온다는 생각입니다. 그러나, 가독성에 집착하여 코드를 보기 좋게 꾸미는 수많은 편집규약, 헝가리 표기, 어느 상황에서 공란을 어디에 얼만큼 쓸것인지, 포인터의 별표는 타입의 앞에 붙일지 뒤에 붙일지, 이런 제약까지 세세하게 규정하고 강요하는 것은 그야말로 '가독성'이라는 문자 그대로에 집착한 나머지 본질을 망각하는 상태라고 생각하거든요.

그래서 설명 가능성이라 하면, 거기엔 얼마든지 집착해도 별다른 해악이 없을 것 같고 (물론 개발이 느려지는 것은 있겠습니다.), 가독성은 자연히 따라올 것으로 예상되기에, 설명 가능성에 더 무게를 두고 싶습니다.

Coral Library Project : http://coral.kldp.net
Orion Project : http://home.megapass.net/~heesc22/

Orion Project : http://orionids.org

creativeidler의 이미지

가독성에 대해 한 마디만 더 하자면, 우리나라 말 가독성과 영어의 readablility에 약간의 의미 차이가 있는 것 같습니다. 일반적으로 가독성이라는 말은 문자 크기라든지 자간, 행간 등 형식적인 가독성의 의미를 강하게 띱니다만 영어로 readablility라고 하면 읽기 쉬운 것을 넘어서서 이해하기 쉽다는 의미까지 띠기도 합니다. 코드의 readablility가 높다는 말은 단순히 컨벤션 잘 지킨다는 정도를 넘어서서 코드의 품질이 높아서 쉽게 이해할 수 있다는 뜻이 되죠. 충분히 짧은 메소드 길이, 적절한 이름 짓기, 낮은 complexity 등의 조건이 맞아야 하는 거죠. 결국 readability라는 개념은 accountability를 포함한다고 할 수도 있습니다.

Ron Jeffries는 프로그래머가 지향해야할 코드에 대해 이렇게 이야기합니다.
Clean code that works.

여기서 clean이란 readability를 위한 것입니다. 생각해보면 우리가 지향해야할 최종적인 가치는 코드를 빨리 이해할 수 있는 것입니다. accountability 역시 readability를 위한 수단적 가치라고 볼 수도 있는 것이구요.

하지만 불행히도 우리나라 말의 가독성은 영어의 readability의 이런 어감과 범위를 제대로 전달하고 있지 못합니다. 한자어 자체의 문제라기보다 이제까지 좁은 범위로 널리 쓰여온 단어이기 때문에 그런 것이죠. 하지만 실상 우리 프로그래머들에게 필요한 것은 좁은 의미의 가독성이 아니라 readability이기 때문에 프로그래머들끼리는 앞으로라도 가독성을 좀 넓은 의미로 사용했으면 하는 바램입니다.

체스맨의 이미지

예, creativeidler 님 말씀대로 생각하는 것이 옳을 것 같습니다. 우리나라 말로 번역된 readability 는 문자 그대로 이해되어지기 쉽습니다. 읽기 쉽게 예쁘게 꾸미라는 의미는 아닌데 거기에 집착하는 경우가 실무 관리자급의 의견에도 있었습니다.

오히려 가독성보다 설명 가능, 이해 가능 등의 의미를 포함하는 단어로 대체되는 것도 좋을 것 같은데요...

Coral Library Project : http://coral.kldp.net
Orion Project : http://home.megapass.net/~heesc22/

Orion Project : http://orionids.org

ㅡ,.ㅡ;;의 이미지

다른사람의 소스를 보는건 아무런 불만이 없는데...

그것처럼 짜라고 하는것이 매우힘듭니다.

아무리 손님이원한다해서 미용사가 머리 쥐파먹은듯이 깍을수 없듯이말이죠.

----------------------------------------------------------------------------
C Library Development Project


----------------------------------------------------------------------------

violino의 이미지

남의 소스 받아서 분석하고 프로젝트 시작하는 것 정말 힘들어합니다.
중간에 남이 하던 프로젝트를 이어받으면 어쩔 수 없지만,
어떻게 돌아가는지는 알았는데, 그 소스가 너무 건드리기 힘들 정도일땐
아예 다시 작성하기도 합니다.
코딩을 하면서 코멘트를 다는 것도 항상 강조하는 것이지만
잘 지켜지지 않는 것중에 하나지요.
이에 관련해서는 최근에 boss 가 포워드해준 링크가 괜찮아서 남깁니다.

http://www.ibm.com/developerworks/linux/library/l-clear-code/?ca=dgr-FClnxw01linuxcodetips

vio:

terzeron의 이미지

개인적으로 최근에 다른 사람이 개발한 것을 인수인계받는 일이 잦았는데, 데이터와 컨트롤의 플로우가 어떻게 되는지를 파악하는 것에 중점을 두게 되더군요.

소스코드만 넘겨받는 것이 아니라 개발 의도를 충분히 설명하고 있는 문서도 함께 넘겨받아서 그걸 이해하고 큰 줄거리를 파악하고 데이터 플로우(와 컨트롤 플로우)를 따라가면 그 시스템을 내 것으로 만들 수 있다고 생각합니다. 위에서 체스맨님께서 언급하신 것처럼 원 개발자와 대화를 나눌 수 있는 상황이라면 서로 이야기를 많이 주고받음으로써 상대의 의도를 파악하는 것이 가장 중요합니다.

물론 이런 성격의 시스템만 존재하는 건 아니고, 좀 더 범용적이고 복잡한 시스템도 있습니다. 예를 들면, OS라든가 DBMS같은 플랫폼이 되는 시스템이 여기에 해당됩니다. 이런 기반 시스템의 경우에는 데이터 플로우나 컨트롤 플로우가 단선적이지 않고, 여러 곳에서 입력이 들어오고 여러 형태로 출력(결과물)이 만들어지게 되는데, 장님 코끼리 만지듯 시스템을 이해하게 될 가능성이 큽니다. 이런 경우에도 소스코드 전체를 리뷰할 수 있다면 좋겠지만, 보통 개인이 거대 시스템을 속속들이 파악하는 것은 힘들고 시간이 많이 걸리는 일이라서 흔한 상황은 아닐 겁니다. 다만, 가장 시급하고 중요한 흐름만을 분리해내서 그걸 체득하도록 노력할 따름이죠.

편리한 도구가 약간 도와줄 뿐이지, 나머지는 시간과 노력만이 해법이라고 생각합니다.

오호라의 이미지

함수단위로 INPUT과 OUTPUT을 중점으로 봅니다.

일일이 소스보면 눈과 가슴만 아픕니다...

Hello World.

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.