Kent Beck 的四個簡單程式設計原則

什麼是好設計,打從開始 coding 以來就是一個不斷追求的大哉問,從
SOLID 看到 Design Patterns,每一個原則看起來好有道理,每一個設計模式都在等著你的套用。

但是最近幾年的工作讓我有不一樣的心得,而不再費心追求「完美」的設計。同一個問題,每個人都會想出不一樣的解法,都說自己的解比較好。於是這些設計原則,常就淪為爭論的工具,當我覺得你的解法做太多事情時,搬出YAGNI; 當我覺得你的解法太複雜時,搬出KISS; 當覺得一個類別太肥大的時候,就搬出 SRP,反正都可以找到支持的論點就對了。很多時候其實不管哪一種方案,都是可以接受的可行方案,於是後來我就不想去爭個你死我活、斤斤計較當下的細節設計了。好設計應該是演進(grow)出來的,我首先在乎的反而是有沒有留下可用的測試和清楚好讀的程式,這樣才可以留下(後人)改進的機會。

回到正題,Kent Beck 在 eXtreme Programming 中,對於什麼是 Simple Design,留下了四個 Xp Simplicity Rules,我個人蠻喜歡的,因為很簡單又基本:

  1. Pass All Tests 通過全部測試:有測試才能夠讓軟體不斷的演進(grow)下去,不然你不是被 regression bugs 淹死,就是只能不計成本把code砍掉重練。如何寫好測試也是個大哉問,xUnit Test Patterns: Refactoring Test Code一書是其中的bible,嫌厚的話,可以先看看Refactoring Test Code這一篇paper,都是在講重構你的測試程式。當然,事情總是過猶不及,老闆付錢給你是為了得到 code,不是 tests。測試只是幫助我們寫好code的工具,追求100%完整的好測試並不是目的。

  2. Reveals Intent (Self-Documenting Code) 程式能夠表達出意圖:其中最重要而且基本的,就是要有好的程式命名,無論是類別、方法、變數等等。專講 Readable 的書有一本可以推薦 The Art of Readable Code。我這裡還推薦一個我最喜歡的技巧 Composed Method (搞笑談軟工也有一篇介紹),這招也是 Kent Beck 大師提出的,將細節的實作抽取成一個小方法,讓整個方法裡的操作都是類似的粒度,小小一招,大有作用。

  3. No Duplication (DRY) 不重複:”Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” 完整定義請複誦三次。有時候重複並不是這麼明顯,例如作用重複的程式,但命名不同,或是命名重複,但程式作用不一樣。這裡推薦 David Chelimsky 的影片 Maintaining Balance While Reducing Duplication (slides)和 Maintaining Balance while Reducing Duplication: Part II,可以增進對 DRY 的理解,DRY 不只是在講不要重複程式碼而已。

  4. Has no superfluous parts (Minimizes the number of classes and methods) 不多餘:這一條也就是 YAGNI,不要實作多餘的功能。我個人不怎麼喜愛這個原則。不是不贊同,不需要的功能花時間去寫當然是浪費大家時間,而是這個原則太容易例外了。有時候會寫下多餘的程式來增加功能或擴充性,那是因為你擁有的經驗、直覺跟當時的情境告訴你應該這麼做,這可以在不久的將來就派上用場,過於強調 YAGNI 反而一板一眼教條主義了。光單看”減少類別跟方法的數量”跟 SRP 和 Composed Method 就有所衝突了,後兩者都會增加類別和方法的數量。

重要性 1 > 2 > 3 > 4,也有版本講 1 > 3 > 2 > 4。

參考資料

機會難得之 Matz 在台見面會

因為昨天才敲定這個行程,所以宣傳慢了。目前還有名額,不限有報名 conference 朋友,機會難得。報名請前往 Registrano

來台參加 RubyConf Taiwan 2012 的 Matz (Ruby 程式語言發明人) 和 Koichi Sasada (YARV作者) 將和大家進行粉絲見面會。本活動自由報名,不限參與 RubyConf Taiwan 的聽眾,免費。

時間: 2012/12/6 18:30 ~ 21:30 (Matz 約 19:00 到場)

議程: 現場 QA,自由聊天

地點: 伯朗咖啡天母店 – 台北市天母東路68號5F (新光三越A棟5F) Google Map

◎公車: 啟智學校:285、646、645、606、616、685 ◎捷運:芝山站出口,轉搭新光三越接駁車

報名請前往 Registrano 系統

喜愛的程式設計名言

每次看技術書籍的時候,特別喜歡翻過一遍作者放在章節開頭的名言佳句(如果有的話),通常都蠻有意思的。所以在自己的裡也想這樣做,這是目前收集的名言佳句。不過要做到每則名言都剛好呼應該章內容真是困難啊。

  1. Life’s too short to build something nobody wants – Ash Maurya, Running Lean 作者
  2. Give someone a program, you frustrate them for a day; teach them how to program, you frustrate them for a lifetime. – David Leinweber
  3. There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. — C.A.R. Hoare
  4. Actually, I’m trying to make Ruby natural, not simple. Ruby is simple in appearance, but is very complex inside, just like our human body. – Matz, Ruby 發明人
  5. Much of the essence of building a program is in fact the debugging of the specification. – Fred Brooks, The Mythical Man-Month 作者
  6. The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. – Tom Cargill
  7. Complication is what happens when you try to solve a problem you don’t understand – Andy Boothe
  8. Weeks of programming can save you hours of planning. – Unknown
  9. Controlling complexity is the essence of computer programming. — Brian Kernighan
  10. All problems in computer science can be solved by another level of indirection(abstraction) – David Wheeler
    …except for the problem of too many layers of indirection. – Kevlin Henney’s corollary
  11. Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. — Rick Cook
  12. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. — Brian W. Kernighan
  13. I’m not a great programmer; I’m just a good programmer with great habits. ― Kent Beck
  14. Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris. – Larry Wall, Perl 程式語言發明人
  15. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. – Martin Fowler
  16. Measuring programming progress by lines of code is like measuring aircraft building progress by weight. – Bill Gates
  17. It’s not a bug – it’s an undocumented feature. – Unknown
  18. The most depressing thing about life as a programmer, I think, is if you’re faced with a chunk of code that either someone else wrote or, worse still, you wrote yourself but you no longer dare to modify. That’s depressing. – Peyton Jones
  19. It works on my machine! – 數以萬計的程式設計師
  20. Talk is cheap. Show me the code. – Linus Torvalds
  21. I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages — Alan Kay, Smalltalk 發明人
  22. When you choose a language, you’re choosing more than a set of technical trade-offs—you’re choosing a community. -Joshua Bloch
  23. Quality, Speed or Cheap. Pick two. – Unknown
  24. Developer testing isn’t primarily about verifying code. It’s about making great code. If you can’t test something, it might be your testing skills failing you but it’s probably your code code’s design. Testable code is almost always better code. – Chad Fowler
  25. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. – Donald Knuth
  26. No code is faster than no code. – Merb core tenet
  27. If you’re the smartest person in the room, you’re in the wrong room. – Unknown
  28. How long would it take your organization to deploy a change (to production) that involves just one single line of code? Do you do this on a repeatable, reliable basis? – Mary Poppendieck
  29. Nine people can’t make a baby in a month.  — Fred Brooks, The Mythical Man-Month作者
  30. Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer. – Steve McConnell, Code Complete 作者
  31. A person does not really understand something until after teaching it to a computer. – Donald Knuth

有特別喜歡哪句嗎? 或是你自己有喜愛的名言,歡迎告訴我。

「守、破、離」學習模式三階段

第一次在 Agile in a Flash 小卡上看到「守、破、離」還一頭霧水不知道在講什麼。最近因才終於了解意思,據說是出自於學習劍道的不同階段:

  • 「守」,一切盡量遵守教條,練習基本功夫直到熟練。這個階段專心學習一種實務,比學習各種理論重要。
  • 「破」,開始打破一些規範限制,可以因地制宜靈活運用。這個階段開始思考理論,也會參考看看其他門派是怎麼做的。
  • 「離」,超越所有規範的限制,自創一格,達到無招勝有招的境界。

學習軟體開發又何嘗不是如此,無論是 Scrum、TDD 或是 Design Patterns,總是得先經歷一段照章行事「盡信書」的階段,循序漸進,才能融會貫通。而不是直接進到「黑貓白貓,會抓老鼠的就是好貓」「無招勝有招」「盡信書不如無書」的階段,直接把所有規範拋開。

例如,前一陣子 Kent Beck 大師 (TDD作者和XP發明人)在 stackoverflow 回答了一題測試要測多少深,答案竟然是 “I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence.” 可說是跌破眾人眼鏡 XD 但其實這種答案根本是第三階段的大師答案嘛,也就是「隨心所欲寫測試」的大師境界。如果從來沒學過寫測試,看到這句搞不好會說測試根本不重要,不需要學哩。所以搞清楚自己在哪個階段也是很重要的,當你聽到有人說「「X方法不重要,只要做的出來就好」時,要注意到大師已經練到可以隨心所欲,我們普通人還是先乖乖遵守「所有 production code 都應該要有對應的 test」培養寫測試的感覺跟經驗吧。

RubyConf Taiwan 2012 CFP&CFS

To English readers:

Hi, I’m the organizer of RubyConf Taiwan. Please see Call For Presentations and Call For Sponsors for more information.

Our invited speaker this year includes Yukihiro Matsumoto (Ruby creator), Koichi Sasada (Ruby 1.9 VM YARV author), Akira Matsuda (kaminari author, Rails Contributor, Ruby core team), Koan-Sin Tan (famous open source developer in Taiwan).

今年的 RubyConf Taiwan 已經開始籌辦一陣子了,才想到自己部落格還沒有貼這則消息… XD 日期是 2012/12/7-8,跟去年一樣是週五周六,場地則改在天母會議中心

詳細的公告,請詳見 Ruby Taiwan 部落格的 Call For PresentationsCall For Sponsors。這週末就截止徵稿囉,要投要快。

大家期待的邀請講者部分,名單有:

* Yukihiro Matsumoto (matz): Ruby 程式語言發明人
* Koichi Sasada: Ruby 1.9 VM (YARV)的作者
* Akira Matsuda: kaminari 的作者、日本最活躍的 Rails Contributor、Ruby core team
* Koan-Sin Tan (Freedom): 台灣開放源碼社群的資深前輩,會來跟我們談跟 Ruby 淵源很深的 Smalltalk

最快九月底,最慢下個月就會開放報名,敬請期待。

從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup

首先感謝 AgileCommunity.tw 辦了這場活動,大家討論的非常熱烈,分享了各自的團隊經驗,真是愉快的活動。

我投的題目是「從 Scrum 到 Kanban: 為什麼 Scrum 不適合 Lean Startup」,這個問題最早是我剛看 Lean Startup 時的小感想,加上被喲哪桑和自己的團隊施行 Scrum 所到碰到的問題和經驗。到底 Scrum 這麼多人推薦和著書的敏捷方法,會不會有什麼不一定適用的地方。所幸接著看到 Kanban and Scrum 這本書,作者將 Kanban 和 Scrum 做了比較,例如同一個 Limited WIP 的概念,不同工具只不過是用不同手法表現出來:Scrum 用 Sprint 固定開發週期,Kanban 用每一個流程狀態來限制。當我讀到這裡時,就體會到了工具只是工具,勿以器馭心。這又才解答了不少我對開發方法論的疑問。

所以我們團隊開始從 Scrum 改用 Kanban 了嗎? 目前算是某種混合的狀態吧,不是說用 Kanban 就要把 Scrum 的東西通通丟掉,就不斷地持續調整中:用 Kanban 增加了施工前和施工後的產品開發流程,並開始加上 WIP 限制。另一方面,則減少了 Sprint 固定開發週期的要求。

p.s. 「勿以器馭心」是宮本武藏的名言,出自簡體版的 Kanban and Scrum 翻譯