Good Source Code

FrontPage|FindPage|TitleIndex|RecentChanges| UserPreferences P RSS
DeleteMe KentBeck 페이지에서 ExtractPage했습니다. 일단은 주석에 관한 내용이지만 이런 페이지이름으로 "좋은 소스코드란 어떤 것인가?"라는 가 주어질 수 있을까 해서... 그나저나 좋은 페이지이름이 떠오르지 않았어요.
TestDrivenDevelopmentByExample에서는 "The goal is clean code that works"라는 말이 나옵니다. CleanCode라는 이름은 어떨까요? --아무개
Wiki:GoodCode도 있습니다. --무신


고수는 주석이 필요없는 코드를 만든다 ?

KentBeck, RonJeffries, WardCunningham 같은 고수들은 제가 가진 고수에 대한 통념을 바꿔놓았습니다. 저는 이제 이렇게 믿습니다: "고수는 주석이 필요없는 코드를 만든다."

저는 제가 살아온 햇수보다도 오래 개발을 한 사람들이 나의 상식을 깨는 발언을 하면 우선은 몇 달 간 화두로 삼고 실험해보고 고민해 볼 가치가 있다고 생각합니다.

Pragmatic Programmers의 앤드류 헌트(Andrew Hunt)의 말을 인용하겠습니다.
{{|
"요즘 프로그래머들은 주석을 많이 다는 것이 좋다고 배웁니다. 주석문이 많을 수록 더 좋은 코드라고 생각하는 것이죠. 하지만 그들은 도대체 왜 코드가 주석문을 "필요로 하는지" 배우지 못합니다. 나쁜 코드는 많은 주석문을 요구합니다."
|}}
정확히 말하자면, 나쁜 코드로 동일 수준의 이해도를 얻기 위해서는 좋은 코드보다 더 많은 주석문을 필요로 한다는 말이 되겠죠.

Rob Pike의 글(http://bit.csc.lsu.edu/tutorial/ten-commandments/pikestyle.html )을 읽어보세요. 제 논지는, 주석이 필요없는 코드를 만드는 것은 오히려 어려울 수 있고, 이것을 위해 노력할 때가 그렇지 않을 때보다 더 가독성이 높은 코드가 나올 수 있다는 것입니다. 주석을 무조건 쓰지 말자는 것은 아닙니다. see also [http]주석 줄이기, [http]Why I don't read code comments, Wiki:MethodCommenting , 토론최소주의

이미 OriginalWiki에 잘 정리되어있는 수백인년의 경험과 토론을 여기서 되풀이해야할 필요는 없을 것 같습니다.


PuzzletChung는 위 말의 뜻을 굳이 이렇게 해석하겠습니다: "주석이 하는 기능은 오히려 함수명, 변수명, 루틴의 흐름 등에서 배어나와야 한다." ...써놓고 보니 그말이 그말인 것 같군요. -_- SeeAlso Wiki:SelfDocumentingCode.

코드의 사회성과 역사성

주석이 필요없는 코드는 없습니다. 지금 사람의 자연언어에다가 토를 단 것은 김창준씨가 아닙니까? :) 하물며 컴퓨터를 위한 프로그램 언어로 짜여진 프로그램코드에 주석이 필요없을 수 있다는 것은 상상하기 힘듭니다. 먼저 코드의 앞부분에는 목적이 들어가야 합니다. 코드가 스스로 목적을 표현할 수 있다면... 그럴 수 있다고 한다 치더라도 주석은 여전히 코드를 읽고 이해하는 데 도움을 준다고 봅니다.

여기서 집합적 주체로서의 코드를 논함은 서양적 사고방식에서는 힘들다고 봅니다. 코드는 대상이지 주체가 아니라고 보는 것이 서양철학입니다. 제가 코드에 통시적이고 사회적인 코드라고 이야기하는 것은 혹 서양 과학철학 위주로 학습받아 온 우리들이 코드를 이전에 만들어 놓은 대상으로만 취급하는 것을 경계하기 위함입니다. 우리가 옛날 바이블을 읽을 때 글쓴이와 같이 호흡하는 것과 마찬가지로 코드에 지금 현재 우주에 반응하고 있는 개인의 소유물로서의 또는 대상이 되는 코드는 없습니다. 바이블이 역사속의 사회적인 산물이듯이 코드 또한 그러합니다. 누가 감히 이 코드는 오로지 나의 머리속에서 그리고 완전히 세상에 없던 새로운 것이라고 말할 수 있겠습니까? 고수는 코드에 사회성을 부여합니다. 그것이 주석이고 디자인패턴입니다.

사회성에 대하여 -
누군가(사회적 조직(기업이던 오픈소스 조직이든간에) 또는 그 참여자가) 무엇을 위하여(사회 또는 그 구성원으로서의 개인을 위하여) 무엇인가로(역사적 산물로서의 컴퓨터와 지식을 가지고) 프로그램을 짭니다. 그 프로그램 결과물은 만들어진 순간(잘 된것이던 잘못된 것이던) 자신의 것이 아닙니다. 물론 MS는 엄청나게 화내겠지만... 사실이 그러합니다. 이는 역사적이고 사회적인 산물입니다. 그 기원에서 그렇고(무엇을 기반으로 프로그램이 나옵니까? 또 무엇을 위해..) 그 목적에서 그 과정에서도 마찬가지입니다. 논지는 그 개인이 좀 더 역사적 산물을 체화할수록 그리고 사회적 조직에 함께 할 수록(물론 방법론으로서의 재미있는 PairProgramming을 포함하여) 더 좋은 코드를 만들어 낼 가능성이 높다는 사실입니다. 리눅스가 그리고 자바가 성장하는 모습은 경이롭습니다. 이에 영향받은 MS가 이의 장점을 모방하여 닷넷전략을 내놓았지만, 사회적 지지를 받지 못하여 앞날이 어둡다고 생각하는 것은 나에게 국한된 것일까요 ?

역사성에 대하여 -
저의 소스코드는 사회적 산물임과 동시에 역사적 산물입니다. 인류역사에 기댄 바 크지만, 개인의 역사도 무시할 수 없지요. 지금 키보드를 열심히 두드려 실제로 코드를 만들어 내는 개별적 인간을 누가 무시할 수 있을 것인가요? 제가 가장 영향을 많이 받은 책은 마이크로소프트에서 나온 『버그는 없다』라는 프로그램 책이었습니다. 그 글의 논지는 KentBeck의 테스트 우위론과 유사합니다. 제가 코드를 제대로 쓴다면 이는 그 책에서 또는 김창준님의 글을 보고 노력한 바에 힘입은 것을 무시할 수 없습니다. 전적으로 제가 한 것은 하기로 결정한 저의 의지뿐(흠 어쩌면 가장 중요한데...)입니다. 저는 개인적으로 개발에 COPY하는 방법을 많이 사용합니다. 옛날에 누군가 만들어 놓은 것을 쓰는 게지요. 최근에는 아파치의 자카르타 한글홈페이지를 만들고 있습니다. 내용은 복사하고 언어라는 껍데기만 바꾸는 훌륭한 방법이라고 생각합니다. 얼마전 세계제일의 한국기업 모...공업에서 프로젝트를 하였습니다. 훌륭한 컨설턴트와 개발자들이 많이 참가하였습니다. 모두들 자신의 훌륭한 모듈과 방법론들을 사용하더군요! 제가 속한 조직이 최하의 지식과 경험을 가지고 있었습니다. 저는 그 회사를 잘아는 숙련자들과 장시간의 토론을 즐겼습니다. 그리고 그들의 엑셀 VBA를 복사하여 VB프로그램으로 변경시켜 주었지요.결과는 수천억의 전체 프로젝트가 실패했지만 저의 프로그램은 모듈로 떼어 아직도 쓰고 있다고 합니다(모듈로 뗄 수 있도록 프로그램하지 않았는데도). 제 프로그램은 제 것이 아니라 그들의 것이기 때문이라고 말하면 억지일까요! see also Wiki:RapeAndPasteProgramming, Wiki:CollectiveCodeOwnership

왜 사회성과 역사성을 이야기하는가?
간단합니다. 저도 컴컴한 골방에서 혼자서 일하기를 좋아합니다. 밝은 데서는 모니터가 잘 안보이기 때문입니다. 그리고 모니터에 코박고 있는 다른 개발자들의 생각을 대화로 이해하기 힘들기 때문입니다. 그렇지만 제대로된 코드를 만들기 위해선 오픈된(역사적 사회적으로) 소스를 이용하여 오픈된 소스를 짤 마인드가 중요하다고 생각합니다


Xper:RefactoringImprovingTheDesignOfExistingCode중 Bad smells in code 중 "Comments" 중에서.
{{|
Our first action is to remove the bad smells by refactoring. When we're finished, we often find that the comments are superfluous. If you need a comment to explain what a block of code does, try Extract Method. If the method is already extracted but you still need a comment to explain what is does, use Rename Method. If you need to state some rules about the required state of system, use Introduce Assertion.
|}}


Make it work, make it correct, make it fast, make it cheap
-- AlanKay

Make it run, make it right, make it fast, make it small.
-- KentBeck

두 인물이 말한 이 단계를 따라가면 GoodSourceCode에 접근할 수 있을것이다. 약간의 차이점은, small하다고 반드시 cheap한 것은 아니라는 것이다. 특히 PerlLanguage에서는 small할 경우 극도로 난해해 지는 경우가 있다.

그러한 맥락에서, GoodSourceCode는 easy해야 cheap하다. 혼자 개발하는 것이 아닌 이상 프로그램에는 절제된 주석이 필수이고, 다른 사람이 보기에 난해하면 곤란하다. --무신

DeleteMe 어디선가 들은 바에 의하면 우리나라 소프트웨어 산업은 일본이나 미국에 비해 10년은 뒤져있다고 합니다. 그것도, 모사의 홍보담당이 회사 홍보하는 자리에서 그 얘기를 당당히 끄집어 내면서 얘기했다고 하니, 10년이면 곧 따라잡을 수 있다는 자신감의 말이였는지도 모를 일이죠. 혹시 이와 비슷한 이야기를 아시는 분 계시나요 ? --무신



"; if (isset($options[timer])) print $menu.$banner."
".$options[timer]->Write()."
"; else print $menu.$banner."
".$timer; ?> # # ?>