第四章關鍵的構建決策（代碼大全2）

標籤：des   style   color   使用   io   strong   問題   cti   

　　一旦你能確定 “構建”的基礎已經打好，那麼準備工作就轉變為針對特定“構建”的決策了。第3章“三思而後行:前期準備”討論了設計藍圖和建築許可證在軟體業務裡的等價物。你可能對那些準備工作沒有多少發言權，所以在第3章關注的焦點是確定“當構建開始後你需要做什麼”。本章關注的焦點是程式員和技術帶頭人個人必須（直接或間接）負責的準備工作。在向工地進發之前，如何選擇適用的工作別在你的腰帶上，你的手裡車裡應該裝哪些東西？本章討論的就是這事務在軟體中的等價物。

4.1 選擇程式設計語言（Choice of Programming Language）

　　研究表明，程式設計語言的選擇從多個方面影響生產效率和代碼品質。

　　程式員適用熟悉的語言時，生產效率比適用不熟悉的語言時要高。適用進階語言的程式員比適用較低級語言的程式員達到更好的生產率和品質。某些語言更能表達編程中的各種概念。

語言描述（Language Descriptions）

　　介紹了很多種語言，在這裡就不寫了。

4.2 編程約定（Programming Conventions）

　　在高品質軟體中，你可以看到“架構的概念完整性”與“其底層實現”之間的關係。“實現”必須與（指導該實現的）“架構“保持一致，並且這種一致性是內在的、固有的。這正是變數名稱、類的名稱、子程式名稱、格式約定、注釋約定等這些針對”構建活動“的指導方針關鍵所在。

　　在一個複雜的程式中，架構上的指導方針使得程式的結構平衡，針對”構建活動“的指導方澤則提供了底層協調，將每個類（Class）都銜接到一種完整的設計（comprehensive design）中，成為其可靠的組件。任何大的程式都需要一個控制結構，該結構可以統一程式設計語言的細節。大結構的部分魅力在於，各個具體組件都能反映整體架構的內涵。假如沒有一個統一的規則，你創作出來得東西將會充斥著各種不同的風格，顯得混亂和邋遢。這些不同風格使得你的大腦承受沉重的負擔——著僅僅是為了理解不同編程風格之間的（本質是是隨意的）差異。成功編程的一個關鍵就在於避免隨意的變化，這樣你的大腦可以專註於那些真正需要的變化。

　　在”構建“開始之前，講清楚你使用的編程約定。編碼約定的細節要達到這樣的精確度:在編寫完軟體之後，幾乎不可能改變（翻譯）軟體所遵循的編碼約定。本書隨處都有這樣的約定細節。

4.3 你在技術浪潮中的位置（Your Location on the Technology Wave）

　　在我的職業生涯中，我看到了PC之星的升起和大型主機之星的隕落，我看到圖形化使用者介面代替了字元介面程式，我還看到了Web的崛起和Windows的衰落。我只能假設當你讀到這本書的時候，又會有某些新的技術蒸蒸日上，而我今天（2004年所）知道的Web編程將會慢慢消失。這些技術周期（或者說是技術浪潮）意味著不同的編程實踐，編程實踐取決於你在技術浪潮中所處的位置。

　　你如何面對自己的編程工作，取決於你在技術浪潮中所處的位置。如果處在浪潮的後期，你就可以計劃用很大部分時間穩定持續的編寫新功能。如果你處在浪潮的前期，可以預期你將要花很大一部分時間，用來找出文檔中未加說明的程式設計語言特性、偵錯工具代碼缺陷帶來的錯誤、修訂代碼以適應廠商提供的新版本函數庫等。

　　如果你在一個很初級（簡陋）的環境下工作，你會發現， 與成熟的環境相比，本書介紹的編程實踐將更有協助。正如David Gries所言，編程工具不應該決定你的編程思路（1981）。Gries對”在一種語言上編程（programming in a language）“做了區分。”在一種語言上編程“的程式員將他們的思想限制於”語言直支援的那些構建“。如果語言工具是初級的，那麼程式員的思想也是初級的。

　　”深入一種語言區編程“的程式員首先決定他要表達的思想是什麼，然後決定如何使用特定語言提供的工具來表達這些思想。

“深入一種語言去編程”的例子（Example of Programming into a Language）

　　理解“在一種語言上編程”和“深入一種語言區編程”的區別，對於理解本書是至關中要的。大多數重要的編程原則並不依賴特定的語言，而依賴你使用語言的方式。如果你使用的語言缺乏你希望用的構件，或者傾向於出現其他種類的問題，那就應該試著去彌補它。發明你自己的編碼約定、標準、類庫以及其他的改進措施。

4.4 選擇主要的構件實踐方法（Selection of Major Construction Practices）

　　"構件"有一部分準備工作，就是決定在這麼多的可選的實踐方法中，你想要強調哪些。某些項目使用結對程式設計以及測試驅動開發，而其他項目使用單人開發和形式化檢查。這兩種技術組合都有可能發揮作用，取決於項目的特定環境。

　　下面的核對錶總結了在“構建”過程中，應該有意識地使用或排斥的特定編程實踐。這些實踐的細節遍布全書。

核對錶：主要的構建實踐（Checklist：Major Construction Practices）

編碼

　　你有沒有確定，多少設計工作將要預先進行，多少設計工作在鍵盤上進行（在編寫代碼同時）？

　　你有沒有諸如名稱、注釋、代碼格式等“編碼約定”？

　　你有沒有規定特定的由軟體架構確定的編碼實踐，比如如何處理錯誤條件、如何處理安全性事項、對於類介面有哪些約定、可重用的代碼遵循哪些標準、在編碼時考慮多少效能因素等？

　　你有沒有找到自己在技術浪潮之中的位置，並相應調整自己的措施？如果必要，你是否知道如何“深入一種語言去編程”，而不受限於語言（僅僅“在一種語言上編程”）？

團隊工作

　　你有沒有定義一套整合工序——即，你有沒有定義一套特定的步驟，規定程式員在把代碼check in(簽入)到主源碼（程式碼程式庫）中之前，必須履行這些步驟？

　　程式員是結對程式設計、還是獨自編程，或者是這二者的某種組合？

品質保證

　　程式員在編寫代碼之前，是否為之編寫測試案例？

　　程式員會為自己的代碼寫單元測試嗎？（無論先寫還是後寫）？

　　程式員在check in 代碼之前，會用調試器單步跟蹤整個代碼流程嗎？

　　程式員在check in 代碼之前，是否進行整合測試（integration-test）？

　　程式員會複審（review）或檢查別人的代碼嗎？

工具

　　你是否選用了某種版本控制工具？

　　你是否選定了一種語言，以及語言的版本或編譯器版本？

　　你是佛選擇了某個編程架構，或者明確地決定不使用編程架構？

　　你是否決定允許使用非標準的語言特性？

　　你是否選定並擁有了其他將要用到的工具——編譯器、重構工具、調試器、測試架構（test framework）、語法檢查器等。

要點(Key Points)

　　每種程式設計語言都有其優點和弱點。要知道你使用的語言的明確優點和弱點。

　　在開始編程之前，做好一些約定（convention）。“改變代碼使之符合這些約定”是近乎不可能的。

　　“構建的實踐方法”的種類比任何單個項目能用到的要多。有意識的選擇最適合你的項目實踐方法。

　　問問你自己，你採用的編程實踐是對你所用的程式設計語言的正確響應，還是受它的控制？請記得“深入一種語言去編程”，不要僅“在一種語言上編程”。

　　你在技術浪潮中的位置決定了哪種方法是有效——甚至是可能用到的。確定你在技術浪潮中的位置，並相應調整計劃和預期目標。