Kwangshin's Positive Blog

Page 42, Test-Driven Development by Example written by Kent Beck

Image source: http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/

When we decide how much we need to do test during TDD, we don't need to worry and spend a lot of times to decide the coverage and steps in detail. Let's see the Kent Beck's advice:

This is the kind of tuning you will be doing constantly with TDD. Are the teeny-tiny steps feeling restrictive? Take bigger steps. Are you feeling a little unsure? Take smaller steps. TDD is a steering process - a little this way, a little that way. There is no right step size, now and forever.

- Page 42

Image source: http://www.raynauds.org/index.php/2011/04/heated-steering-wheel-cover-news/

Page 46, Test-Driven Development by Example written by Kent Beck

Moreover, we need to abandon our habit even though we are excellent software engineers. Don't try to do everything by ourselves! Pass our works to computers or tools. That's why we have developed the computers and tools we are using.

In teaching TDD, I see this situation all the time - excellent software engineers spending 5 to 10 minutes reasoning about a question that the computer could answer in 15 seconds.

- Page 46

Page 47, Test-Driven Development by Example written by Kent Beck

I know that I show the message - "All code is guilty until proven innocent" above. However there is an exceptional case, as always. In page 47, Kent Beck is trying to do implement "toString()" method without a test! If there are understandable reasons, then you need to accept it.

Whoa! Code without a test? Can you do that? We could certainly have written a test for toString() before we code it. However,
-. We are about to see the results on the screen.
-.  Because toString() is used only for debug output, the risk of it failing is low.
-. We already have a red bar, and we'd prefer not to write a test when we have a red bar.
Exception noted.

- Page 47

Do not forget the principle and purpose! Our purpose is developing software, not the TDD itself!

Happy TDD!

Page 24, "Test-Driven Development by Example" by Kent Beck

Copy-and-paste reuse? The death of abstraction? The killer of clean design?

Not always...

The following cycle doesn't finished yet...

1. Write a test.
2. Make it compile.
3. Run it to see that it fails.
4. Make it run.

[Trying to do "copy-and-paste" here...]

5. Remove duplication.

The cycle is not complete. The first four steps of the cycle won't work without the fifth.

Don't be worry about doing "copy-and-paste", if the "copy-and-paste" is not a purpose, but a mid-step. Of course, it could be happened when we need to do "copy-and-paste". Please see the principle(essence), not superficial, why we would suggest not to use "copy-and-paste".

Focus on promising ourselves we wouldn't go home until the duplication was gone.

기다리던 책이 나왔습니다! 프로그래밍 언어와 사고하는 능력의 상관관계에 대해서 관심이 있고, 새로운 프로그래밍 언어 하나를 배우는 것이 그저 프로그래밍 언어 하나를 더 할 수 있게 되는 것 이상의 사고의 깊이를 깊게 한다고 믿어왔는데, 이 책의 저자와 출판사도 비슷한 생각을 하는 것 같습니다.

7주안에 7개의 새로운 언어(사실 그냥 새로운 언어가 아니라, 여러가지 조건들을 고려해서 7개의 언어를 선별했다고 합니다.)를 배울 수 있게 해 주는 책입니다. 7개의 언어를 보면 세상에 발표된지는 오래되었지만, 이론적으로 훌륭한 언어들부터 시작해서 요즘 뜨고 있는 언어들까지 골구로 선별하려고 노력한 흔적이 보입니다. 7개의 언어는 Clojure, Haskell, Io, Prolog, Scala, Erlang 그리고 Ruby 입니다. 다들 이름은 어느정도 들었던 언어들인데 모르는 언어들이 대부분이라서 더욱 더 이 책이 흥미롭게 다가오네요.

특히나 책 소개에 나오는 다음 글이 더 마음에 와 닿네요. 아마도 앤디 헌트가 쓰셨겠죠?

Want to become a better programmer? Learning a new programming language will show you new ways of thinking, and new approaches to problem solving that will help you be a better programmer in any language. And what if you could learn the important lessons from seven different languages? You’d be unstoppable.

더 훌륭한 프로그래머가 되기를 원하세요? 새로운 프로그래밍 언어를 배우면 사고하는 데 있어 새로운 길과 방법을 보여주고, 어떤 언어를 사용하든지 상관없이 문제를 해결함에 있어 새로운 접근 방법을 시도하고 찾아낼 수 있는 능력을 길러줍니다. 게다가 7개의 서로 다른 프로그래밍 언어로부터 중요한 핵심 포인트만 배울 수 있다면 어떨까요? 책을 손에서 놓지 못할 것입니다!

제가 간단하게 번역했지만, 어느정도 개인적인 사심이 들어간 것 처럼 보이는 번역이네요. 아직 싱가포르에는 안 들어온 것 같은데, 들어오자마자 사서 일독을 해야 할 것 같습니다. 더 훌륭한 프로그래머가 되기를 원하시는 분들게 강추입니다!

그리고 역시 센스쟁이 출판사네요. 표지 삽화가 바벨탑 사건을 그린 그림이네요. 이 바벨탑 삽화를 보면서 사이드바에서 추천해서는 관련 서적들 목록을 보는데, Programming Ruby, Programming Erlang, Programming Scala 그리고 Programming Clojure와 같은 책들이 보이네요. 하나 하나의 언어가 각자 책 한권 분량으로 나올 정도인데, 7일만에 7개의 언어를 완변하게 마스터 하려고 한다면, 바벨탑처럼 무너질 수 있다는 경고가 아닐까요? ㅎㅎㅎ 너무 오바인것 같네요. 아무튼 7개의 언어를 7주안에 마스터 하는 것은 힘들겠지만, 그 언어들의 특징과 철학을 맛볼 수 있는 좋은 기회는 될 수 있을 것 같습니다.