代碼大全2（3）

一下子把第三章也看完了，只覺得經典就是經典啊，雖然軟件工程課上也是講過的，但那時沒想這麼多呀，，沒有實際的工作經驗，總覺得軟件就是寫代碼，，總想着教人寫代碼纔是軟件，但是後來去實習了才知道軟件遠遠不止這些，，後來看了些書……

第三章：三思而後行：前期準備（Measure Twice，Cut Once：Upstream Prerequisites）

這一章就是在說構建前的準備工作，並且這準備工作是非常重要的！確實，整個開發過程中的每一步都是很重要的！

前期準備包括三件事：問題定義、需求分析、系統架構。

前期準備的重要性：項目前期準備工作可以決定這個項目的成敗！說到這裏就想到了我們公司目前三部正在做的一個系統，趕着要上線了可是還有很多的問題，聽說不知被客戶罵了多少次，同事好幾天都沒見他回來了，說是在客戶那邊附近賓館住下連夜加班做了。我雖然不太清楚具體情況，但我總覺得是需求沒做好……

“準備工作的中心目標就是降低風險，一個好的項目規劃者能夠儘可能早的將主要的風險清除掉。”

前期準備不足的原因：

1. 前期準備人員能力不夠
2. 程序員不能夠抵抗“儘快開始編碼”的慾望，當時的我不就是這樣的麼？
3. 管理者不明白前期準備工作的重要性，要知道“軟件開發不僅僅是寫代碼”

這讓我想起了一件事，初中歷史課本上談到當時建三峽大壩（985項目），說那些專家經過半年的討論論證才同意這個方案，當時我是把那些人罵了個夠，我想不就是建個大壩嘛，需要半年的討論嗎？這些人辦事效率就是低！可見我當時不明白需求調研的重要性。。。就算是現在的很多事我也不一定明白，那結果必然就如同當時初中生的我了……可見換位思考的重要性，很多我們不理解的事我們也不要立馬去反對，而是應該思考、理解、包容。就算我們想要反對，那也應該先把問題弄清楚了，從理性的角度來反駁，而不是毫無意義的噴口水，這就是所謂的“沒有調查就沒有發言權”吧。從這些事中就可看出一個人的風度和氣質、性格等……朋友相交就是平時的這些小事在影響着彼此的關係，所謂合得來合不來就是看彼此是否有共同的……

呃…扯遠了

技術僱員的一部分工作就是培訓周圍的非技術員工，講解開發過程。應對“尚未覺悟的管理者和老闆”。

從多個方面來說：

1. 訴諸邏輯：大項目有大計劃，小項目有小計劃，制定計劃是必須的，不然走錯了進了死衚衕；
2. 訴諸類比：軟件開發就像建房子，建房子前先要準備好設計圖（要包含所有信息），不然就會發生推到重建的事情，又記起一件事，大學時，一條新修的公路剛建好一兩個月，其中很大一段又圍起來挖了來修排水工程，，我當時就在想這些人幹什麼喫的，難道新建馬路時沒想到要建下水管道的嗎？不僅多花了錢，還封路帶來了不方便。由此可見一個好的城市管理者是多麼重要！！一個好的領導是多麼重要啊！！呵呵~剛纔還說不理解就不要噴別人，實在沒忍住！！
3. 訴諸數據：告訴老闆如果不做好需求分析，後期出問題了修復的費用與發現的時間的關係，告訴他，越晚發現問題，改動費用越高。引用兩幅本書的圖片來說明

最好採用迭代開發，，說了那麼多迭代，就像使用“隱喻”這個詞一樣，總是讓人心裏有陰影，雖然都在那麼說，但是就是不給個準備通俗易懂的說法，我理解迭代就是：不斷重複循環。循環的過程中一步步的改善，做的更好。

拿到項目了，不要一頭就往下做，最後做完了給客戶一看，“No，這不是我想要的",   你就等着哭吧~應該做一點就給他看一下，確認完後再繼續，其間有問題的立即改，，，這也是所謂的技巧，領導安排了任務，做的時候要隨時彙報並確認，不能等做完了，領導說做錯了，不斷彙報會讓他又準備接受最後的結果，即使沒完成或者失敗了。

正式開始本章的三個問題：

一、問題定義

產品設想、設想陳述、任務描述、產品定義……都一個意思，這裏就叫問題定義好了。

“問題定義”只說要做什麼，不涉及任何可能的解決方案，問題定義因該用客戶的語言來書寫，從客戶的角度來描述問題，不要一開始就想着編程，因爲有可能客戶所說的問題不需要用代碼來解決，而我們卻把它想多了。

二、需求分析

需求開發、需求描述、需求定義、軟件需求、規格書、功能規格書……也都一個意思。就是說這個項目要有什麼樣的功能。

需求絕壁是會變的，程序員最想要的就是《最終需求——永遠不變版本》，但這是不可能的，所以一開始就要和客戶溝通好，充分詳細的描述他們的需求。如果需求要變怎麼辦：

1. 確保每一個人都知道需求變更的代價！！！！！！！一定要讓每一個人知道！客戶隨時會想到一個新功能，然後讓你去改，作者稱之爲“新功能中毒症患者”，如何應對：對他說：“嗯，這主意不錯，但是它不是需求文檔裏的東西，我會整理出一份修訂過的進度表和成本估算表，然後你再決定是否修改，可以過一陣子再說”。呵呵，只要跟他說新需求會加長時間和費用就可以了。其實沒有什麼不可以的，無非就是加錢嘛，只要給的多就可以改，重新來過都可以，關鍵是錢要給到位！
2. 建立一套變更控制流程，就是所謂的需求池，有需求變更，可以！扔到需求池中吧，按順序來一個一個的改！
3. 使用能適應變更的開法方法：演進交付：分階段交付。
4. 放棄這個項目：實在是更改太變態、太多的話，，要不是沒辦法了誰會這麼做呢！實在是天憤人怨啊。
5. 考慮商業價值：很有特色的功能要是不能帶來價值，就得考慮是否應該現實了。

三、系統架構

高層設計、頂層設計、系統架構……同義。

架構的典型組成：

1. 程序組織：首先義慨括的形式對有關係統做一個綜述，就是說這是用來幹嘛的，然後定義程序的主要構造塊（模塊），模塊有的簡單有的複雜，有的只是一個類，有的需要多個類組成一個子系統，都是用來實現各自的功能，比如顯示界面、與用戶交互、訪問數據、封裝業務規則……每條功能需求都應該至少有一個模塊來實現它，構造快的設計原則：各自負責一個區域的事情，對其他構造快的情況知道的越少越好，對自己要實現的功能越精越好，將涉及的信息侷限於各個構造快之內。明確定義每個構造快的通信規則（輸入、輸出、數據格式……）
2. 主要的類：描述那些主要的類的責任，類之間的交互。如果系統很大，還應該描述如何將這些類組織成一個子系統。80/20法則：對於構成系統80%的行爲的20%的類進行描述。
3. 數據設計：主要文件和數據表結構，數據應該只由一個子系統或類來訪問。
4. 業務規則：描述業務規則對系統設計的影響。
5. 用戶界面設計：這應該在需求分析階段就詳細說明，如果沒有，就應該在架構時定義web頁面格式、GUI等主要元素。
6. 資源管理：例如數據庫連接、線程、進程……
7. 安全性：處理緩衝區、內存、處理用戶輸入的數據、cookies、配置文件、加密規則等……
8. 性能：時間複雜度、空間複雜度、速度、內存
9. 可擴展性：用戶數量、服務器數量、網絡節點數量、數據庫……等的增長
10. 互用性：與其他軟件或硬件交互
11. 國際化/本地化：Internationalization、Localization，編碼、字符資源（不要硬編碼）
12. 輸入輸出：
13. 錯誤處理：約定好規則，比如是由某個（組）類專門來檢查數據還是各個類負責自己的數據有效性 
14. 容錯性：發生錯誤時怎麼辦？
15. 架構是否可行？
16. 過度工程：不要死板硬套，大項目有大架構，小項目要靈活變通，要全局考慮問題，只有符合國情的纔是好的，要走有中國特色的社會主義
17. “買”還是“造”：有些控件或功能是自己編寫還是買，考慮時間、人力、客戶需求等的成本
18. 複用：對已存在的軟件加工，使構造快各自獨立就是爲了能複用吧，不然每次都寫新的程序也太麻煩了，構造快負責的業務單一就能很方便的抽取出來用到其他軟件中來
19. 架構的總體質量：《人月神話》，架構與編程語言無關，不用過度描述，也不要描述太少。架構要指明風險區，並說明爲什麼和已經採取了哪些方案以使風險最小化。架構要從多個視角描述，類似房屋的不同設計圖：正視圖、平面圖、結構圖、水電管道圖等
20. 架構要讓人容易理解！！！

書上說了架構的很多，但是目前最能讓我考慮到的恐怕只有前面幾條了：模塊、類、數據結構。

前期準備時間：20%~30%

一旦開始，再改，成本巨大！早確定、少改動。寧願多花時間來確認需求！！！