程式設計師的偏見

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

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

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

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

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

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

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

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

截自第二十一章

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

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.

TDD Test-driven development

TDD forces you to think through the testing process before you write the code.
TDD 強迫你要寫 code 前先把流程想過一遍。

Every developer has the experience of writing a class in one big bunch, making assumptions along the way. Then when it comes time to actually use the class, you realize that some of your assumptions were wrong, and you have to refactor the original code.

寫了一大堆才發現寫錯，這時候要重構就痛苦了。

如果寫文件是麻煩的，花時間的...

那麼，你就不會想去維護它。會儘可能的迴避它。

low-ritual artifacts are best, and my favorite is the lowly drawing on a whiteboard.
you really need it only until you embody it in code, and then the code can speak for itself.

在白板上畫好圖後，把它照相下來，就再也不必寫文件了，唯一要做的就是把 code 實作出來，然後程式自己會說明它自已(用 generate doc 工具)。

SVN2Wiki, SVN 2 Wiki plug in

同一件事，做一次就好。
...we realized that we were actually violating the canonicality principle because we were asking the developers to document stuff they had already documented - in their comments where posting to version control.

原來之前用過的 Trac 整合 SVN 的功能，類似 SVN 2 Wiki 。
這本書中有討論為何會設計這個 plug-in.

SVN2Wiki is a great example of living documentation
把 SVN 的 cechk in 註解整合進 wiki 軟體後，程式碼與文件，變得更緊密相依，文件才有活著的感覺，不然通常都會發生文件無法被用來參考的冏境。
Most documentation for projects is lame because it no longer has relevance.
(大部分文件都是跛腳的，因為它們不會被維護)

DRY Document

Out-of-date documentation is worse than none because it is actively misleading.
錯的(過時的)文件比不寫文件還糟，因為它會誤導你！！

只趕進度，不更新文件的人要注意了，這是個很嚴重的缺失...

Continuous intergration

is a process where you build the entire project, run tests, generate documents, and do all the other activities that make software on a regular basis, the more often the better, generally you should build every time you check in code to version control.

The continuous integration server runs on a separate machine, monitoring your check-in to version control.

CI machine should not include the development tool you use to create the project, only the libraries and other frameworks needed to build the application.

If you can build application with a single command on a standalone machine, you obviously have the configuration correct.

Cruise Control 是 Thought Work 的 CI 軟體，其他的還有：
Bamboo, Hudson, TeamCity, LuntBuild.

DRY Version Control

Checking your files into version control early and often encourages you to make small changes.

You'll face a merge conflict if you make long-tern changes to the file encourages you to check in more often.

原來 mick 每次做一點小修改就 commit 的道理是出自這裡啊。

DRT

It's hard to even notice the problems in lost of situation, especially if non-DRYness (moistness?) is the status quo.

Don't Shave Yaks

　　查了一下這句英文的意思，大致是說不要瞎忙，例如根據 Subversion 的 log 來 generate 文件。
　　為了一個小小的問題，搞了一堆事情出來，是在浪費自己的時間；讀到這，才想起以前常常會犯這樣的錯呢，我想這應該也是許多人都有的經驗吧。
　　書裡同時提到，這樣的狀況，就是許多專案的時程估不準的原因。因為 Programmer 會不小心把時間浪費在這種事情上。