《構建之法》閱讀筆記

第一部分關於結對程式設計的體悟與實踐

在結對程式設計這一部分我曾講過很多的注意點，比如**變數命名風格、縮排風格、注釋風格，前後語句次序風格，等等。然而這裡還有一些新的東西。**風格這個老掉牙的話題咱們先擱置不談，而說說在結對程式設計中同樣重要的其他注意點。

step1：「自己改+你說我看」：不符合共同協定的編碼風格的地方，一律修改

我們需要在一開始就商定好**風格，比如哪些地方需要換行，變數的命名規則等等。

然後，先過自己這一關——自己對**進行修改。比如在上面的例子中，函式名為anothermain，這是什麼鬼意思？這種根本不知其所以然的命名，必須**。還有像enternum這樣的變數，也會讓人摸不著頭腦，應該改為characternum這種規範的命名。

在自己認為沒有大毛病之後，還需要對方對自己進行挑錯。在這裡，挑錯要注意乙個原則：不要在雞蛋裡挑骨頭，要本著找出有意義的錯誤的原則，認真查錯。比如，「這樣的函式命名會不會和以後的命名衝突，從而引起歧義？」

step2：**潛在的邏輯問題，預防「邏輯災害」的發生

step3：修改完後也不鬆懈，繼續進行經驗總結

總結這個步驟，是讓我們「事半功倍」的不二捷徑。它不容忽視

然而，如果我們進行過程式優化，就會發現，這是乙個很令人詫異的結果——**的執行時間變成了原來的兩倍！這究竟是怎麼回事呢？

原來，在新的函式中，我採取了反覆呼叫子函式的措施來精簡**。而在我的子函式中，我為了繼續精簡**，又套用的新的子函式，這裡進行了兩次的套用。而在判斷是否為乙個單詞並進行儲存的時候，這種層層呼叫的次數是超乎想象的。正是這裡頭的反覆巢狀，大大拖慢了程式的執行速度。

接下來是進行修改，在不損失**簡潔性的前提下進行**優化，其中主要是效能優化。我首先要做的是把兩層的函式巢狀改為一層。

通過將兩層的函式巢狀改為一層，我的子函式從原來的16行變成了42行，可以說複雜了不少，但接下來我們看一下執行效率。

**的執行時間大約是最初執行時間的 1.4 倍。

這個結果比第一次優化的結果好了不少，但沒有達到本次**優化的最終目的——在不損失效能的前提下進行感官上閱讀體驗的提公升。當然，我也已經知曉了**變慢的原因——函式巢狀和函式呼叫花去了太多無用的時間，接下來的優化步驟也明晰了。