TDD는 XP와 함께 매우 유명한 프로그래밍 기술 중의 하나다. 어느 정도 TDD나 Agile software development methodology에 관심이 있는 사람이라면, “Test First”가 TDD의 가장 중요한 idiom을 알고 있을 것이다. ‘automated test를 먼서 작성하고, test를 동작하게 만들기 위한 가장 간단한 code를 작성하고, refactoring은 가능한 한 뒤로 미루라’는 것이 TDD의 기본이다.
이 책은 세 개의 파트로 나뉘어있다. Part I은 어떤 story (일종의 requirement)를 구현하는 과정을 TDD를 사용해서 보여주고 있다. Part II는 xUnit이라는 tool을 사용해서 TDD를 좀 더 편리하게 수행하는 것을 보여주고 있다. Part III는 TDD와 연관된 여러가지 pattern들을 정리해두었다.
TDD는 여러가지 이익을 가지고 있지만, 가장 마음에 드는 것은 test 설계부터 하기 때문에, 구현자의 입장보다 사용자의 입장에서 먼저 생각해보게 되고, 결국 interface의 품질이 더 좋아진다는 것이다. interface는 중요하지만, implementation은 그다지 중요하지 않다. implementation은 변경할 수 있고, interface는 그렇지 않을 가능성이 크기 때문이다. 이미 사용자들이 interface를 사용하고 있다는 이유로 대충 설계해놓은 interface를 개선할 수 없게되는 경우를 흔히 볼 수 있다.
번역도 되어있고 하니, 한번쯤은 읽어볼만한 책이다. 아마 집중해서 읽으면 2-3일이면 다 읽을 수 있을 듯 하다.
‘Introduction to Software Engineering’ 과목에서는 Object-Oriented Design을 가르친다. 간단한 정의와 함께, UML design 과정에서 use case로부터 object를 골라내서 class diagram을 그리는 법은 가르친다. 하지만, 아무도 object-oriented programming paradigm 뒤에 들어있는 생각을 가르쳐주지는 않는다. (물론, 다룰 주제가 많은 software engineering 과목에서 OOP를 깊게 설명하기는 어렵다.)
OOP language를 쓰는 것은 일종의 유행이다. 모두들 그 이유를 잘 알지도 못하면서 OOP를 선호한다. 심지어는 그것이 무엇인지도 모르면서 말이다. 사실, 나도 그런 사람들 중의 하나였고, C를 사용한 procedural programming paradigm에 익숙해지고 난 후, 주로 OOP language (C++, Java, Python, Ruby, …)를 사용하기 시작하면서, 계속 던지게 되는 질문은 OOP란 무엇인가, 대체 procedural programming paradigm보다 object-oriented programming paradigm이 무엇이 우월한가라는 것이었다.
‘Object Thinking’은 이러한 질문에 답변해주는 책이다. 즉, SE 과목에서 한두페이지의 페이지에 설명해놓은 것을 이 책에서는 300페이지에 걸쳐서 설명해놓은 책이다. OOP는 technique이 아니라 paradigm이다. 생각하는 방식은 누군가의 간단한 한마디 말로는 바뀌기 힘들다. (물론 그런 경우도 있다.) ‘Object Thinking’은 ‘object philosophy’, ‘object culture’란 말을 도입한다. 당연하게도, 사상(thinking)에는 철학(philosophy)이 전제되고, 문화(culture)가 따르고, 역사(history)를 가지기 마련이다. object thinking의 중심 원리(principle)들과 역사를 설명하고, 다른 philosophy와 culture와 대조를 함으로써 object thinking이 무엇인지가 조금씩 드러난다.
이 책에서는 단지 OOP가 무엇인지에 대해서만 다루고 있는 것은 아니다. OOP 외에도 software development의 여러가지 생각(thought)들을 object culture의 범주안으로 통합시킨다. 특히, XP와 같은 Agile software development가 여기에 해당된다. 따라서, 이 책에서 얘기하는 ‘object thinking’은 단지 OOP가 아닌 것이다.
또, 이 책에서 설명하는 OOP는 Booch를 중심으로 표준화된 전통적인 SE 진영의 OOP와는 조금씩 다르게 보인다. 여러번 책에서 언급되는 Smalltalk community 쪽(이를 공식적으로는 어떻게 지칭하는지 모르겠다.)에서 발전된 생각으로 보인다. 한가지 예로, OOP에 관한 여러 책들에서 object란 data와 algorithm의 결합이라고 지칭하지만, 이 책에서는 그러한 생각을 과감하게 거부한다. object란 behavior로 정의된다고 주장한다. 이러한 생각 한가지만으로도 object design에는 엄청난 영향을 미치게된다고 생각된다. (이 주제에 대해서는 나중에 따로 다뤄보겠다.)
아직 번역서가 없지만, 여력이 된다면, 또는 언젠가 번역이 된다면, 반드시 읽어보라고 추천해주고 싶은 책이다. 시간이 난다면, 이 책에서 인상 깊었던 생각들을 조금씩 블로그에 정리해볼까도 한다.
WebRSSAggregator는 RSS들을 수집, 통합하여, 웹을 통해 보여주는 어플리케이션이다. 즉, 흔히 말하는 RSS reader다. (전에도 이 사이트를 통해서 소개한 적이 있었으므로 더 자세한 내용은 생략하겠다.)
소프트웨어 개발의 진행 결과는 관리자에게 보고하고, 구현을 마친 요구 사항은 적어두면서, 개발을 하면서 발생한 design decison들을 기록하는 사람들은 거의 없다. 사실, 개발자의 실력을 키워주는 것은 그러한 작은 design decison이 모여서 이루어진 어떤 sense라고 생각한다. 이러한 과정은 물론 우리들의 뇌 속에서 자동으로 이루어지는 것이지만, 소프트웨어 개발을 하면서 드는 생각들을 정리해두는 것만으로도, 더욱 효과적으로, 긍정적인 피드백을 주리라고 생각한다.
Iteration 3
최근에는 적절한 feature들의 set을 모아서 기간을 정하고, 이를 하나의 iteration으로 개발하는 방식을 주로 사용하고 있는데, 이는 FDD에서 어느 정도 따온 방식이라고 볼 수 있다. WebRSSAggregator도 어느덧 세번째 iteration에 접어들었고, 이 iteration에서 구현할 feature들은 다음과 같다.
Refactoring
Model-View-Controller
Apply eruby template
Get method accepts Filter (rather than several get* methods)
More subscription information on subscription list, admin interface
“Mark read”
Content folding
Feature
Label operation: mark, unmark
More subscription information
retrieve channel information on addSubscription (title, link, description)
automatically update feed on addSubscription (only for Web interface?)
Documentation
rdoc documentation
Release
commit rubyforge
여러가지로 적어두었지만, 사용자 인터페이스를 정리하고, 코드를 MVC 기반으로 refactoring하는 것이 이번 iteration의 주요 목표다. 그리고, RubyForge에 WebRSSAggregator를 release하는 것이 이번 iteration의 최종 목표다.
View
어느 정도 기능들이 많아지고 사용자 인터페이스가 복잡해지면서, 가장 문제가 되는 것이 view와 logic의 분리다. 웹 어플리케이션의 View를 어떻게 설계할 것인가를 고민 중이다. MVC에 따르면, 여러 sub-view들 간에 hierarchy를 가진 view 구조를 선호하고 있다. 따라서, 각각의 subview를 (div element를 사용한) block으로 만들고 어플리케이션에 특화한 layout을 가진 main view가 이들을 조직화하고, 대부분의 formatting은 css에 맡김으로써, 간단한 (적어도 WebRSSAggregator에는 사용 가능한) View 정도는 깔끔하게 만들어낼 수 있지 않을까 생각하고 있다.
당장은 subview들 약간만 작업해놓은 상태다. (SimpleItemListView, FlatItemListView) 한가지 고민되는 것은 우리나라의 여러 portal에서 즐겨쓰는 table을 사용한 html page design에는 이러한 방식이 최악이 될 수도 있다는 것이다. 아직도 table의 div 대체 가능성에 대해서 명확한 대답을 보지 못했고, 가능하다면 이것을 증명해보고 싶기도 하다. (물론 WebRSSAggregator 따위로 될 리는 없지만)
이미 Rails 같은 MVC framework이 널려있고, MVC pattern이 꽤 흥행해왔기 때문에 Web App에서의 View에 관련된 내 고민들은 이미 대체로 해결된 별 쓸모없는 것일지도 모른다. 좀 더 살펴볼 예정이고, 조언도 환영한다. 어쨌거나 흥미로운 문제고, 이것 때문에 Web App Development에 대한 나의 관심이 요즈음 한껏 고양된 상태이다.
Accessing DB
Filter
DB로부터 data를 얻어올 때, business logic이 요구하는 내용에 따라 여러 method가 난립했었는데, filter라는 개념을 도입하여, 단순하게 정리했다. 예를 들어, 기존에는,
과 같이 단 하나의 method로 정리되었다. 참고로, Rails에서는 SQL 문의 WHERE 절에 들어가는 expression과 유사한 string을 filter로 사용한다.
ItemManager getItems(filterString)
이러한 filter들을 사용자 interface로 정리하는 것은 꽤 괴로운 일이었다. 직접 사용자의 선택을 모두 case by case로 처리하고 있는데, 다른 MVC framework의 Controller 디자인을 참조해보아야할 듯 하다.
Table Data Gateway/Active Record/Data Mapper
가장 처음 WebRSSAggregator를 만들었을 때는 class가 하나도 없었고, 단지 DB로 SQL 문을 query해서 data를 읽어온 후, html로 번역해서 뿌려주는 ruby script였을 뿐이었다. 초기 기능을 만들고나서 바로 class로 refactoring을 수행했고, 가장 먼저 건드린 곳이 DB를 access하는 부분이었다. 현재의 모습이 그 때 refactoring의 결과인데, 그러한 설계를 Table Data Gateway라고 부른다는 사실을 오늘 처음 알았다.
간단히 설명하면, DB table에 있는 data에 대한 모든 operation (주로 CRUD와 SELECT)을 수행하는 object다. 물론 이러한 operation들은 보통 business logic의 requirement에 따라 만들어지고, 각 operation이 보통 하나의 SQL 문을 나타낸다고 볼 수 있다.
WebRSSAggregator에서 ItemManager, SubscriptionManager, 그리고 CategoryManager가 모두 Table Data Gateway에 속한다. (‘Manager’라는 너무나 보편적인 이름을 지은 것은 후회해야할 일일 것 같다.)
ItemManager, SubscriptionManager, CategoryManager는 각각 attribute만을 가진 Item, Subscription, Category를 사용한다. 즉, Table Data Gateway는 passive data를 다루는 Controller object에 해당하는 것이다. “Object Thinking”에서는 이러한 설계가 Object-oriented paradigm의 철학과는 배치된다고 적극 말리고 있고, 이에 대한 대안을 찾고 있었는데, Rails의 문서를 뒤지던 중에, Active Record라는 pattern을 발견했다.
Active Record는 간단히 말해서, Controller object가 passive data들을 control하는 것이 아니라, Table 또는 Table의 row에 해당하는 object가 스스로 DB access를 수행하는 설계를 가지고 있다. 앞에서 말했던 “Object Thinking”에서의 충고에는 충실한 편이다.
당장은 Table Data Gateway인 ItemManager, SubscriptionManager, CategoryManager의 responsibility를 현재는 passive data에 불과한 Item, Subscription, Category로 이전시켜, Active Record로 만들 생각이다.
DB Access에 관련된 pattern에는 Table Data Gateway와 Active Record외에도 Data Mapper가 있다. Data Mapper는 object와 relational database 사이에서 OR mapping을 수행해주는 object다. 따라서, 이 경우 object는 DB Access에 관해 신경을 쓰지 않을 수 있게 된다. business logic과 DB를 access하는 logic을 적극적으로 분리하는 pattern이라고 볼 수 있다.
PHP programming language에 대한 어떤 비판 중에는 HTML 안에 code를 embed할 수 있기 때문에, presentation과 code의 분리를 방해한다라는 주장이 있다. asp, jsp 등이 web language로서 보편화된 것을 보면, 그 주장이 사실이라고 하더라도, 분명 그러한 단점을 넘어서는 장점이 있기때문일 것이다.
개인적인 생각으로는 code를 HTML에 embedding할 수 있는 것은 매우 편리하다. 위에서 살짝 언급했듯이, subview들을 block등으로 적절히 나타낸다고 하더라도, 전체 layout을 나타낼 때 code를 사용해 HTML을 generation한다면 매우 이해하기 힘들고 수정하기도 힘든 코드만 대량으로 생산해낼 뿐이다. 하지만, code embedding과 HTML을 적절히 조화시키면 깔끔한 View 코드를 생성할 수 있다.
이러한 코드를 보면 그러한 비판은 정말로 유효한 것 같다. (실제로는 더욱 심할테니!) 하지만, 이것은 언어 자체의 문제나, HTML에 code를 embedding 시킬 수 있는 기능 자체의 문제가 아니다. 이러한 코드를 쓴 사람은 어떤 프로그램을 짜더라도 엉망으로 짤 것이다. 프로그래머로서의 자질 자체가 문제인 것이다.
WebRSSAggregator에도 이러한 생각을 증명하기 위해서 eruby를 적용해보았다. 현재까지 만들어진 sub-view들을 제외한 View는 전부 HTML과 embedding된 ruby code로 되어있다. 가능한 한 대부분의 View는 클래스화 하겠지만, 전체 페이지 모두를 클래스화할지는 아직 의문이다.
To Be Continued…
WebRSSAggregator에서의 MVC 구현이 좀 더 진척된 미래의 어느 시점에 다음 편이 나오지 않을까 싶다.
주변 사람들이야 다 알겠지만, 병역 특례기간도 끝났고, 휴학기간이 끝나서, 이번 봄학기에 복학할 예정이다. 지난 월요일에 대전에 가서 이것저것 처리하고 왔다.
대전에는 가끔씩 갔었지만, 학교엔 거의 3년만에 가본 것 같다. 정문에서 전기전산학과 건물까지밖에 안돌아다녀봐서 잘은 모르겠지만, 3년이라는 세월이 무색할 정도로 옛날 그대로였다. 복학원 제출하고 수강 신청을 했다. 지도교수님도 찾아뵈었는데, 처음엔 얼굴을 못알아보시더니, 곧 알아보시는 눈치였다. ‘뭐하고 사냐?’와 ‘각오는?’의 질문에 적당히 둘러대는 정도로 면담을 마치고, 철호군과 집을 알아보러 나섰다.
원래 지난 달에, 철호군의 지인(?)을 통해 철호군과 함께 살 집을 구해놨었는데, 계약 또는 가계약을 안했더니, 집주인이 변심해버리는 바람에, 다시 집을 알아봐야했다. 철호군이 저번에 알아보았던 곳 근처에서 한번 알아보고, 갤러리아 백화점에서 10분 정도 거리의 임대형 건물들이 한데 모여있는 곳에서 또 한번 알아봤는데, 나중에 간 곳이 비슷한 가격에 집이 마음에 들었다. 3500만원 전세 정도로 대략 18평 정도 투룸을 계약하게되었다. 신혼부부가 살고 있는 집이라 깔끔하기도 하고, 방들도 큰 편이라 마음에 들었다. 철호군이 꼼꼼하게 하자사항을 따져주고, 부동산에서도 꽤 친절하게 설명해주어서, 무난하게 계약을 끝낼 수 있었다.
계약을 마치고, 7시쯤 되어서, 아라기술에 가서 아르바이트 관련 얘기를 했다. 대충 하프타임 정도로 얘기를 했고, 합리적인 선에서 일하기로 결정했다. 22학점을 들으면서 하프타임이면 상당히 고달픈 삶이 될 것 같다. 3월, 5월 같이 시험기간이 없는 달에는 그럭저럭 해나가더라도, 시험기간이 있는 달에는 아르바이트를 줄이는 게 좋을 듯하다. 봄학기에 아르바이트를 어느 정도 해보고, 많이 힘들다면, 가을 학기에는 아르바이트를 하지 않거나 아주 조금만 하는 것이 좋을 듯 하다. 방학 기간에 어차피 현장 실습을 해야해서, 가을학기에 살 정도는 생활비를 벌어둘 수 있지 않을까 생각이 든다.
대충 1년동안 졸업 요건을 채울 수 있긴 한데, 이후로 무엇을 할지 아직 모호한 상태라서, 1년 내에 끝낼지 한학기 더해서 성적을 어느 정도 올릴 지는 아직 고민 중이다. 성적은 아무래도 앞으로의 진로에 있어서 얼마나 더 많은 옵션이 있느냐의 중요한 요건이라고 생각하지만, 한학기를 투자할 만한 가치가 있는 옵션이 있는지는 좀 더 생각해봐야할 것 같다. 현재 고려하고 있는 것은, 석사 과정 진학과 외국 회사 취업 쪽이다. 석사 과정은 어느 정도 학계의 분위기를 경험해보고 안목을 넓히는데는 괜찮다고 생각한다 (라는 충고를 받았다). 게다가 2년 정도라면 그 이익에 대한 투자로는 적절하기도 하고. 사실, 외국 회사 취업은 아무래도 준비 기간이 필요하기 때문에, 그 경우를 선택한다면 무조건 복직하게 될 것 같고, 석사 과정 진학이라면 아마도 성적을 올려두는 것이 필요할 것이다.
당장은 이런 식으로 2-3년 정도의 옵션만 생각할 예정이다. 장기적으로 여러 옵션들을 고려할 능력도 없거니와, (내가 이 분야에 머물러 있다는 가정하에) 이 분야는 빠르게 변화하기 때문이다.
“More Effective C++”와 “Effective STL”을 번역하신 곽용재님이 번역작업 중이시고, 초고를 탈고하셨다고 한다. The C++ Programming Language는 C++의 창안자인 Bjarne Stroustroup이 쓴 책인 만큼 권위있고, 자세하며, 잘 쓰여진 책이다. (Books for Software Development 참조) C++ 을 배우는 사람들이 C++ 책을 추천해달라고 할 때, The C++ Programming Language를 추천해줄 수 없었던 가장 큰 이유가 번역이 되지 않았다는 사실이었는데, 앞으로는 대답이 달라질 수 있을 듯하다.
“Rapid Development”를 번역하신 박재호님이 번역작업중이시다. 이 책은 원래 개발자들 사이에 매우 유명한 “Joel On Software”라는 Joel Spolsky의 홈페이지 내용을 책으로 엮은 것이다. 나는 송민철 팀장님이 알려주신 “The Joel Test”를 통해서 Joel On Software를 알게되었는데, 이 후로 계속 RSS를 구독중이다. 아쉽게도, 원서를 아마존을 통해서 이미 사버려서, 번역판을 살 일은 없을 것 같지만, 이런 좋은 책이 번역된다는 것은 매우 기쁜 일이다.
Xfire는 게이머들간의 social network를 형성하기 위한 툴입니다. 내가 플레이하는 게임이나 플레이하는 서버를 다른 사람들과 공유할 수 있죠. 어떤 게임을 플레이하고 있는지 탐지하기 위해 하드 드라이브를 검색해야하는데, 직접 게임들이 있는 곳을 바로 지정 못하는 점과, 인터페이스가 좀 아쉽지만, 그런대로 쓸만합니다. 어찌보면, Game Server Browser인 All Seeing Eye의 부분적인 기능을 가지고 있기도 하군요. (저는 All Seeing Eye의 lifetime registered user입니다.)
Counter-Strike community쪽에서는 Xfire를 사용하는 모습이 종종 보입니다. 우리나라의 Counter-Strike community인 NariCS에서도 Xfire를 지원합니다. (자신이 쓴 글 밑에 Xfire profile이 embed됩니다.)
다음은 제 Xfire profile입니다. 등록한지는 오래 됐는데, 그동안 사용을 안했고, 이제부터 사용해볼 생각입니다. 아이디는 cestlavie이니, 관심있는 분은 buddy로 등록하시길.
PHP, which stands for “PHP: Hypertext Preprocessor” is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. Its syntax draws upon C, Java, and Perl, and is easy to learn. The main goal of the language is to allow web developers to write dynamically generated webpages quickly, but you can do much more with PHP.
즉, PHP는 general-purpose이긴 하지만, Web development를 위해 특화된 언어이며, 쉽게 배울 수 있고, 빠르게 개발할 수 있는 (agile) 언어라는 점을 선언하고 있다.
PHP의 역사를 보면 왜 PHP가 이러한 철학을 가지고 있는지는 확연하게 드러난다. PHP의 원래 이름은 “Personal Home Page Tools”였으니 말이다.
Why PHP?
왜 PHP 였는가? 왜 여러 language alternative들 중 PHP가 “Web language”의 자리를 차지했는가? 답은 PHP 언어의 철학안에 있다. PHP는 웹 개발에 특화되어있었으며, 쉽게 배울 수 있고, 빠르게 개발할 수 있으며, open source였기 때문이다. 언어 외적인 중요한 factor 중 하나는 PHP가 빠르게 성장하고 있던 Apache의 module 기능을 처음으로 적용한 middleware solution이라는 것이었다. (“처음으로” 라는 사실은 중요하지 않다. “초기에”라는 말이 적합할 것이다. 3개월 정도 후에, Perl도 modperl을 내놓았기 때문이다.)
C# Attribute를 사용해 contract/interface를 명시하는 방식은 이미 최근 RPC 관련 programming model에서 일반적인 trend라고 볼 수 있고, ServiceHost는 일종의 Container라고 볼 수 있을 것 같다. 특기할만한 점은 C# Generics을 이용해 container와 implementation을 결합했다는 점 정도. 여러 end point를 추가할 수 있는 점도 여러 Transport를 제공하는 Indigo의 특성을 잘 드러내주는 점이라고 할 수 있을 듯 하다.
