2010年12月1日 星期三

程式設計師的偏見

這本書真的不錯,隨便瀏覽一、兩頁就發現,程式設計師的偏見,你(或我)都犯了...

→ 堅持使用原先的API,對於集合和正則運算式的新API 視而不見。
→ 無效的假設,以為最直接的解決方案就是最好的解決方案。

2010年11月29日 星期一

作者如同投手,有些作者完全知道如何控球,有些則是「暴投」作家

作者以投手與捕手的關係,來解釋主動式的閱讀為何,剛開始看這一段,我覺得很難理解,看到後面一後,有種豁然開朗的感覺。
在探討「溝通」這件事上,我突然聯想到會議上,我們的教授就像是個暴投作家。

然,這個比喻有點不完全恰當;讀者想「接住」多少意念完全是看他在閱讀時多麼主動,以及他投入不同心思來閱讀的技巧為何。

太多的資訊就如同太少的資訊一樣,都是一種對理解力的阻礙

現代的媒體正以壓倒性的氾濫資訊阻礙了我們的理解力;他們將知識份子的態度與觀點包裝起來,觀眾或讀者直接將包裝過後的觀點裝進自己的腦海中,根本不用思考。

好的閱讀幫助我們的心智保持活力與成長

截自第二十一章

我們的身體是有限制的,心智卻沒有限制。身體不能無限制地成長,而我們的頭腦卻能無限地成長與發展下去。心智不會因為到了某個年紀時就停止成長,只有當大腦失去活力,僵化了,才會失去了增加技巧與理解力的力量。
這是人類最明顯的特質,也是萬物之靈與其他動物最主要不同之處。心智就跟肌肉一樣,如果不常運用就會萎縮。心智的萎縮就是在懲罰我們不經常動腦。心智萎縮也可能要人的命。許多工作忙碌的人一旦退休之後就會立刻死亡。他們活著是因為工作對他們的心智上有所要求,那是一種人為的支撐力量,也就是外界的力量。

2010年11月25日 星期四

TDD 與 non-TDD 之間的差別

If you compare the TDD version of the code to the non-TDD version, you'll see that the TDD one has much more code, but in lots of really small methods.

In six months, when it comes time to alter this code , you can make changes with confidence.
The method names in TDD code describe an atomic operation, so when a test fails, you understand what you've broken more quickly.
methods 的命名就已經描述了這個動作(atomic operation),所以當測試失敗時,你很快就能知道發生什麼事了。

If something breaks, you will know within a few lines of code what's wrong.
儘量讓 method 小而簡單,可以增加程式的可讀性。

If you find yourself writing embedded comments within methods, your method should be more refined.
如果你的 method 裡有註解,那表示,你的 method 應該要重新設計了。

it's not really about testing, it's about getting the infrasturcture set up correctly

用一個簡單的小程式:尋找 perfect number ( 完美數) ,在寫 code 之前先寫它的第一個測試,
測試回傳的公因數里是否有 1,但,這個測試會不會太簡單了,有什麼用嗎?

@Test public void factors_for_1(){
int[] expected = new int[] {1};
Classifier c = new Classifier(1);
assertThat(c.getFactors(), is(expected));
}


How can this be a useful test ? It seems too simple. Really simple tests like this aren't really about testing, they are about getting the infrastructure set up correctly. I must have the test libraries on the classpath, I need a class named Classifier, and I must resolve all the package dependencies. That's a lot of work! Writing a stupidly simple test allows me to get all the structure established before I have to start thinking about testing the actual hard problems.

Once I get this to pass, should I keep it around? Yes! I call thes really simple test canary tests. ( 金絲雀對有毒氣體更加敏感。因此,通常作為煤礦危險信號的先知者) These very simple tests can tell you if something fundamental has broken.