Skip to main content

Posts

Showing posts from January, 2007

Programming By Contract vs. Defensive Programming

Head First Object-Oriented Analysis & Design 이라는 책을 읽다 보니 Programming By Contract와 Defensive Programming 방법을 비교한 부분이 있습니다. ((Head First 시리즈는 Head First Design Pattern 다음으로 두번째인데 너무 맘에 드는 시리즈입니다. Design Pattern이 뭔지 OOA&D가 뭔지 다 아시는 분들에게도 강추!!)) Programming By Contract는 Design By Contract(DBC) 라는 말로 더 잘 알려져 있죠. 간단히 비교하자면 DBC에서는 client가 service를 사용하기 전에 service를 제공하는 supplier와의 contract에 따라 precondition을 만족시키는 입력만을 제공해야 하고, Defensive Programming에서는 client가 어떤 입력을 주더라도 supplier는 안전하게 동작해야 한다 정도가 됩니다. 일반적으로는 입력이 올바르지 않을 경우 DBC나 Defensive Programming 모두 supplier가 이를 처리해야 하므로 DBC와 같이 확실히 contract을 가지는 것이 supplier 입장에서 구현이 쉬워집니다. 또한 DBC를 사용하는 쪽이 코드도 간결해지죠. 코드끼리 서로 믿지 않으면서 작업하려면 체크해야 할것들이 많아지니까요. 이 부분을 읽으면서 제가 지금 하고 있는 프로젝트에 대해 생각을 해봤습니다. 지금 작업하고 있는 소프트웨어는 덩치가 엄청 큽니다. 이 하나의 소프트웨어에 4~5개의 랩들이 포함되어 있으며 각 랩은 2~3개의 파트로 나누어져 있습니다. 각 파트의 개인들이 담당하고 있는 block도 모두 다르죠. 이런 상황에서 core dump 같은 문제가 발생하면 문제의 원인이 누구인지가 모두의 관심사가 됩니다. :-) 보통 pstack을 확인하면 나오는 부분은 supplier쪽 코드들이죠. 예를 들어 null pointer access로 에

CodeHighlighter plugin test page.

This post is for testing CodeHighlighter plugin which uses GeSHi as a fontifier engine. ((Those code blocks are acquired from Google Code Search .)) ((For more supported languages, go CodeHighlighter plugin or GeSHi homepage.)) C++ (<pre lang="cpp" lineno="1">) class nsScannerBufferList { public: /** * Buffer objects are directly followed by a data segment. The start * of the data segment is determined by increment the |this| pointer * by 1 unit. */ class Buffer : public PRCList { public: Buffer() { ++index_; } PHP (<pre lang="php" lineno="4">) for ($i = 0; $i < strlen( $utf8_string ); $i++ ) { $value = ord( $utf8_string[ $i ] ); if ( $value < 128 ) { // ASCII $unicode .= chr($value); } else { if ( count( $values ) == 0 ) { $num_octets = ( $value < 224 ) ? 2 : 3; } $values[] = $value; Lisp (<pre lang="lisp">)

Hello Wordpress, again.

한 두주일 정도 Textpattern을 사용해봤는데 다시 Wordpress로 돌아오기로 결정했습니다. 무엇보다 스킨 변경이 너무 복잡하고 사용자층이 Wordpress에 비해 너무 앏네요. 원하는 plugin도 찾기 어렵고... :-| 그동안 Textpattern에 썼던 글들은 모두 Wordpress로 옮겼습니다. 2개 있던 댓글도 옮겼는데 그중의 하난 제가 쓴... ;-) 애초에 wp-dokuwiki plugin이 무거워서 옮겼던 것이라 이 plugin은 설치를 안할 예정인데 몇가지 아쉬운 점이 있네요. 첫째는 code highlighting 기능인데 이 기능은 예전에 만들어 놨던 것 을 조금 수정해서 쓰려고 준비중입니다. 두번째는 Footnote 기능인데 찾아보니 Footnotes 0.9 Plugin for WordPress 2.0.x 라는게 있네요. 이정도면 비록 wiki syntax에 비할바는 아니지만 쓸만할 것 같습니다. :-)

Bad smell in code review

코드 리뷰 시간에 코드 owner가 수정 사항의 설명을 마치면서 자신의 수정이 완벽하지 않다며 다음과 같이 말하더군요. 하나의 클래스안에서 특정 함수를 그 클래스안의 특정 함수들만 사용하게 하고 싶다. 즉, 클래스 내부의 메소드 사이에도 private같은 것이 있으면 좋겠다. Refactoring의 bad smell이 생각이 나더군요. 좀더 자세한 내용을 들어보니 SRP(Single Responsibility Principle)가 지켜지지 않은 클래스였습니다. (low-cohesion, high-coupling) 이 내용이 이번 코드 리뷰의 결과로 수정되지는 않았으나 refactoring list 의 Extract Class 가 적용되어야 할 경우였습니다. 제가 배운 오늘의 교훈은. "왜 xx 기능이 내가 사용하는 언어에선 지원되지 않나?"라는 생각이 들면 먼저 설계에 문제가 없는지를 검토해 보자 입니다. :-) -- 저희가 코드 리뷰를 시작한지 몇개월 되지 않았는데 대부분의 reviewer들이 review할 코드를 읽지 않고 들어옵니다. 따라서 별로 능동적으로 참여하지 않게 되고 시간 낭비라는 생각에 코드 리뷰 시간을 싫어하죠. :-) Wikipedia 를 보니 line-by-line 코드 리뷰가 defect를 제거하는데 별로 효율적이지 않다는 말도 있네요. 하느냐 마느냐... 그것이 문제군요. :-) 부록(?)으로 Code Review Starter Kit 에 있는 내용입니다. Everyone knows which code to review Reviewers are familiar with requirements and design Purpose of review is clear Reviewers review all the code by themselves first Reviewers record comments in writing Code author hears and accepts comments in perso

Using Autoconf

XMLCPP 라이브러리를 만들면서 Autoconf 에 대해 알게 되었습니다. 원래 Autoconf의 목적은 다양한 Unix-like 시스템에서 source code package가 컴파일될 수 있도록 해주는 shell-script들을 생성해주는 것입니다. 하지만 여러 Unix-like 시스템에서 사용할 계획이 없는 프로그램이라도 이를 사용하면 install/uninstall/dist/check 등의 다양한 장점을 얻을 수 있습니다. 특히 automake, libtool등과 같이 사용하면 Makefile도 간단히 만들 수 있고 .a나 .so등도 쉽게 관리가 가능합니다. 이번 글에서는 간단한 예제를 가지고 autoconf를 사용하는 방법을 소개합니다. 자세한 파일 내용들은 첨부 파일을 참고하세요. (( hello-10tar.gz )) Create directories & files Create basic directories & files 다음과 같이 디렉토리와 파일들을 생성합니다. 생성하는 파일들은 GNU coding standards 에서 요구하는 파일들입니다. ((만약 이 파일들이 필요없다면 automake에 --foreign 옵션을 줄 수 있습니다.)) $ mkdir config include src tests $ touch INSTALL README AUTHORS ChangeLog COPYING NEWS Copy libtool files 다음과 같이 libtool 관련 파일들을 config 디렉토리에 cp 합니다. $ cd /usr/share/libtool 혹은 cd /usr/local/share/libtool $ cp config.* lt* your/path/to/config/ Write source code files 이번 글에서는 간단한 Hello 클래스를 구현합니다. .h 파일은 include, .cpp 파일은 src 디렉토리에 생성합니다. Create configure.ac file 먼저 configure.ac 파일의 templa

2006년 추천 서적

몇년전부터 읽은 책들의 목록 을 쭈욱 적어보고 있습니다. 그래서 연말에 최고의 책과 추천할만한 책들을 정리해보고 있는데 올해의 결과는 다음과 같습니다. 당연하게도 점수는 주관적입니다. 특징이라면 C++책이 한권밖에 안들어있다는거... :-) 이제 비슷비슷한 내용에 질려가나 봅니다. C++0x라도 나오면 좀 나아질런지. 근데 문제는 비슷비슷한 내용이 있을거라는걸 알지만 어쨌든 한번은 읽어줘야 된다는거. 책들은 많이도 나오는데 말이죠. 2006년 마지막으로 읽은 책은 Ken Pugh의 Prefactoring인데 완전 비추입니다. 제목은 완전 낚시. :-| Best 은하수를 여행하는 히치하이커를 위한 안내서, (5.0) Must Read (Developer) The C++ Standard Library Extensions: A Tutorial and Reference, Peter Becker (4.0) DEBUGGING, (4.5) 실용예제로 배우는 웹 표준, (4.5) Must Read (All) 양자 인간 (이백살을 맞은 사나이), 아이작 아시모프, (5.0) 콘택트 1,2, 칼 세이건, (5.0) 프로페셔널의 조건, 피터 드러커, (4.5) 죽은 경제학자의 살아있는 아이디어, (4.5) 세계는 평평하다, 토머스 L. 프리드먼, (4.5)