《程序員修煉之道》——第二章 注重實效的途徑（四）

11、原型與便籤

　　咱們須要構建原型，緣由是爲了分析和揭示風險，並以大大下降的代價、爲修正提供機會。與轎車製造商同樣，咱們能夠把原型用於測試項目的一個或多個具體的方面。

　　咱們每每覺得原型要以代碼爲基礎，但它們並不老是非如此不可。與轎車製造商同樣，咱們能夠用不一樣的材料構建原型。要爲像工做流和應用邏輯這樣的動態事物製做原型、便籤就很是好。用戶界面的原型則能夠是白板上的圖形、或是繪圖程序或界面構建器繪製的無功能的模型。

　　原型的設計目的就是回答一些問題，因此與投入使用的的產品應用相比，它們的開發要便宜的多、快捷的多。起代碼能夠忽略不重要的細節——在此刻對你不重要， 但對後來的用戶可能很是重要。例如，你在製做GUI原型，你不會因不正確的結果或數據而遭到指責。而另外一方面，若是你只是在研究計算或性能方面的問題，你也不會因不正確的結果或數據而遭到指責。而另外一方面，若是你只在研究計算或性能方面的問題，你也不會由於至關糟糕的GUI而遭到指責；甚至也能夠徹底不要GUI。

　　但若是你發現本身處在不能放棄細節的環境中，就須要問本身，是否真的在構建原型。或許曳光彈開發方式更適合這種狀況。

　　

　　應制做原型的事物

　　你能夠選擇經過原型來研究什麼樣的事物呢？任何帶有風險的事物。之前沒有試過的事物。或是對於最終系統極端關鍵的事物。任何未被證實的、實驗性的、或有疑問的事物。任何能讓你以爲不舒服的事物。你能夠爲下列事物製做原型：

• 架構
• 已有系統中的新功能
• 外部數據的急結構與內容
• 第三方工具或組件
• 性能問題
• 用戶界面設計

　　原型製做是一種學習經驗。其價值並不在於所產生的代碼，而在於所學到的經驗教訓。那纔是原型製做的要點所在。

 

　　怎樣使用原型

　　在構建原型時，你能夠忽略哪些細節？

• 正確性。你也許能夠在適當的地方使用虛設的數據。
• 完整性。原型也許只能在很是有限的意義上工做，也許只有一項預先選擇的輸入數據或一個菜單項。
• 健壯性。錯誤數據檢查極可能不完整，或是徹底沒有。若是你偏離預約路徑，原型就可能崩潰，並在「煙火般的燦爛顯示中焚燬」。
• 風格。在紙上認可這一點讓人痛苦，但原型代碼可能沒有多少註釋或文檔。使用原型的經驗，你也許會撰寫大量文檔，但關於原型系統自身的內容相對而言卻很是少。

　　由於原型應該遮蓋細節，並彙集所考慮系統的某些具體方面，你可使用很是高級的語言實現原型——比項目其他部分更高級（也許是像Perl、Python這樣的語言）。高級的腳本語言能讓你推遲考慮許多細節，而且仍然能製做出能工做的代碼。

 

　　製做架構的原型

　　許多原型被構造出來，是要爲在考慮之下的整個系統建模。與曳光彈不一樣，在原型系統中，單個模塊不須要能行駛特定的功能。事實上，要製做架構原型，你甚至不必定須要進行編碼——你可使用便籤或索引卡片、在白板上製做原型。你尋求的是瞭解系統怎樣結合成爲一個總體，並考慮推遲細節。下面是一些你能夠在架構原型中尋求解答的具體問題：

• 主要組件的責任是否獲得了良好的定義？是否適當？
• 耦合是否得以最小化？
• 你可否肯定重複的潛在來源？
• 接口定義和各項約束是否能夠接受？
• 每一個模塊在執行過程當中是否能訪問到其所需的數據？是否能在須要時進行訪問？

　　根據咱們製做原型的經驗，最後一項每每會產生最讓人驚訝和最有價值的結果。

 

　　怎樣「不」使用原型

　　在你着手製做任何基於代碼的原型以前，先肯定每一個人都正確理解你正在編寫用過就扔的代碼。對於不知道那只是原型的人，原型可能會具備欺騙性的吸引力。你必須很是清楚地說明，這些代碼是用過就扔的，它們不完整，也不可能完整。

　　別人很容易演示原型外表的完整性誤導，而若是你沒有設定正確的指望值，項目出資人或管理部門可能會堅持要求要部署原型。提醒他們，你能夠用輕木或膠帶製造一輛了不得的新車原型，但你卻不會在高峯時間的車流中駕駛它。

　　若是你以爲你所在的環境或文化中，原型代碼的目的極可能被誤解，你也許最好仍是採用曳光彈的方法。你最後將獲得一個堅實的框架，爲未來的開發奠基穩定的基礎。

　　使當地使用原型，能夠幫助你在開發週期的早期肯定和改正潛在的問題點——在此時改正錯誤既便宜、又容易——從而爲你節省大量的時間、金錢，並大大減輕你遭受的痛苦和折磨。