敏捷開發並不是教條式的照本宣科，開發者要懂得變通最重要的是用心思考，而非把必要的思考都看成精神層面的問題，這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應，但文辭有略為做過一番修飾，可以用來澄清我對測試驅動開發步驟的看法。
對 David Ko 提出 Kent 認為 Red/green/refactor 是 TDD 的三字箴言的說法，同人倒是覺得有探討的必要。以下分享我在 Facebook 回應 David Ko 的觀點，這些觀點應該可以解釋為什麼測試開發不需要徹底重構；其實重構並不是問題，而是到底什麼叫做徹底？而且如果 TDD 可以徹底重構，那麼一開始就可以讓設計一次到位，那寫好的測試程式以後也用不著了，不正是多此一舉？
測試驅動開發的精神，不應該用一般機械論的觀點來進行工作或任務的化約，而是基於複雜理論的重要觀念；維持穩定與變化的動態平衡，不在於掌握系統核心而在於邊緣，讓變動限定在人們可以掌握的範圍內，這或許才是測試驅動開發最關鍵的精神吧！
表面上看起來好像實作泛型可以讓某一段程式碼重複使用，但 Java 在泛型的限制，也增加他重構程式碼的困難度與複雜度。這麼說來，假如石頭成的想法是正確的，用 Java 的泛型來重構程式碼，只會讓程式員沒事自討苦吃。然而，同人在仔細研究他的程式碼之後，發現可以用更簡潔的方式來使用 Java 的泛型。
最近同人在開發資料剖析的程式時，碰到一個很奇怪的現象。我使用 map 容器來存放剖析資料的結果，然而卻發現以原先新增資料所用的相同鍵值，竟然會找不到該筆資料。但我的測試程式顯示容器中所存放的鍵值與資料，其內容是正確的，但為什麼用相同鍵值去找，結果竟然回傳查無資料呢？原來問題就出在以字元串列常數當索引鍵值。
程式碼的重覆性使程式不容易維護、以及增加系統出錯的機率，同時使得程式的再用性難以提昇。因此降低程式碼的重覆性對程式碼的品質與彈性有很大的助益。然而，在資料存取與與物件型別的無法分離的情況下，卻會使得開發者難以對治程式碼的重覆性；相同處理資料的邏輯，受限於處理資料的不同型態，使得開發者必須依據資料型態不同，而改寫同一段程式碼，使得程式碼很難共用。 就像一個比較常見的例子是資料永續存取的實作，常會因為存取資料型態的不同，而影響到資料存取的界面，因此對每一個需要持久化的商業領域物件，都必須重覆地實作它們的 CRUD 存取功能。 雖然透過永續層的概念，我們可以將這種重覆性隔離開來，加上有些 ORM 永續框架的協助，開發資料存取物件的負擔並不太大。然而即使如此，我們有沒有可能避免重覆開發資料存取的元件，不用針對每一種物件型別都要寫一支相對的資料存取物件呢？要達到這樣的目的，我們必須分離資料存取的處理程序與物件型別，但要如何才能做到呢？
在〈開發者的 common sense〉的留言中，同人看到一些網友的批評。我發現這些批評顯示了有些開發者不擅於抽象化思考，而習慣於用經驗法則來取代思考。然而，誠如 Brooks 所言：「軟體的本質是複雜的，而不是偶然發生的」對治複雜度本來就是開發者的天職，而軟體開發的抽象化思考則是其用以統理複雜度的利器。由此看來，那些網友的批評著實令人為他們捏一把冷汗呀。 從路邊的垃圾桶與路人的留言，我們可以發現他們弄錯 common sense 的意思。他們認為 common sense 不能一概而論，因為每個人的 common sense 都不同。但這樣的觀點令人感到疑惑，如果每個人的 common sense 都不一樣，所以無法一概而論，那這種 common sense 還能叫做 common sense 嗎？ 到底他們觀點上邏輯的矛盾，問題是出在那裡呢？同人認為問題並不是開發者的 common sense 不存在，而是忽略了開發者應該將經驗化成一般性的通用概念。舉例來說，軟體工程領域本身就是從實務發展出來的理論，其中許多概念就是開發者必須知道的 common sense，對開發者來說是合理的知識，也是他們都知道、無須解釋或加以論證的常識。 由此可知，如果開發者缺乏一般性的通用概念，那他碰到問題就很難舉一反三，自然也就難以掌握重點，而只能依據表相來處理問題，往往使得問題變得更複雜。oofunp 的留言就很像欠缺概念思考的開發者常見的反應，一開始以自己熟悉的技術來看問題，最後才發現自己對問題的理解是錯誤的。尤其「以為抽象化是將資料庫定義抽象化」的想法，更是整個弄錯抽象化思考的意義，結果最後他還是誤解了業務規則的意思。 同人前一篇文章所提到的業務規則，並非來自技術領域上萬用的設計，而是對問題領域經過抽象化思考後，所萃取而得到可以解決業務需求的重要概念。顯然 oofunp 的誤解是以技術的角度來看待抽象化思考，才會產生嚴重的觀念混淆。事實上，抽象化思考重視的不是技術實作，而是如何從實際問題當中萃取出重要的抽象概念，以增進我們對問題領域的瞭解，才能採用最適當的技術來開發軟體系統。 此外，過份強調技術經驗而輕忽概念性思維的開發者，很容易表現出自己對問題的盲目。就像 X files 留言的批評一樣，責怪同人沒有交待清楚是 XML 格式的問題，直到別人提出質疑才說明與列出參考文獻，認為同人缺乏部落格文章寫作的 common sense。但我的文章已經很清楚地提到是有關「交易訊息」語法的問題，難道他不瞭解交易訊息是 XML 技術的一般化抽象概念表述嗎？XML 只是實現交易訊息概念的一種技術，用以解決跨系統整合的問題。如果他要看到 XML 字眼才知道是訊息格式的問題，那改天換了另一種交易訊息的實作方式，我想大概他腦筋又要轉不過來了吧。 以上網友的三種批評，表面上看起來好像是不同的問題，但其背後都存在同樣的本質，那就是從交易訊息的問題中可見一斑，他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢？
昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結構上的問題。其實那篇文章除了結構問題之外，同人也在該篇文章內容中，發現了一些值得探討的問題，因此想在這篇文章發表我的看法。 以該篇文章內容而言，同人認為值得探討的有兩個地方，一個是程式語言一直再改變的迷思、另一個則是作者建議讀者，儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念，而第二個問題就是嚴重的偏見了，值得讓人進行思辨以建立正確的觀念。
如果穩定的程式真的是偶然的，程式的穩定似乎只能依賴運氣而不是人為努力，事情真的是這樣嗎？其實這位噗友太過強調環境變化的隨機性，卻忽略了適應環境變化，程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的，雖然演化的過程是偶然、但其最後結果卻是必然。換句話說，穩定的程式是偶然下的必然。
從事軟體開發的工作中，同人也常觀察到一些開發者不懂藏拙的智慧，意欲表現自己很有能力，但卻總是被人看到他們虛有其表的黔驢之技。我們當然很希望這樣的人，不要出現在工作經驗當中。但很不幸地，世事總是難以如我們的預期，如果不幸在工作碰到這樣的人，我們應該如何自處呢？
最新迴響