一 設計流程要點
功能方法考慮效能，流程方法考慮設計模式。
1. 願景
你需要做個什麼東西，要做到什麼水平。
2. 邊界
你需要幹什麼，什麼你不用幹，什麼你不能幹。
3. 需求
客戶給的需求，老闆給的需求是功能需求；自己給的需求，**給的需求是非功能需求。功能需求簡單，一眼望穿。難點在於非功能需求。
4. 明確
明確非功能需求（實際上是扯淡）。你只能憑經驗明確一部分，大多數還是實踐的時候遇到坑反饋給你，你才能明確。所以這裡需要明確的是非功能需求的功能方法。
5. 定方案
提煉重點、難點、核心功能。
6. 嘗試
有些功能需要調研，寫demo，不要一開始寫，寫出坑，改的時間都沒有。
7. 切割
垂直的（分不用模組），前邊工作做好了，就開始做劃分（子系統、子模組）。
沒有關聯的能分開就分開，可能分開的是乙個子系統，也可能是乙個子模組，很多時候是乙個檔案乙個類。
8. 切割
水平的（同一模組分不同層次），就是把乙個模組分層。
把乙個類分成base sub，一層一層的關聯下來。減少改動，提高復用性，容易檢查和修改，也容易理解。
[補充一下切割，切割有三要素：資料結構、功能和流程]
1）資料結構關鍵是思路核心，這個看經驗
2）功能簡單粗暴，粒度越小越好，單一，不該管的事一律不管
3）流程所謂邏輯，原則是流程就是call call call（呼叫），流程裡一定不要做功能，會很亂，拆不開合不 上，難以重構
9. 分合
就是設計裡常說的耦合問題。耦合問題的原則是內聚、外解耦（官方叫 高內聚、低耦合），這裡說的分合是什麼時候分，什麼時候合。
按照7、8部分的切割。能切開的都分，切不開的都合。另外，作為功能集的一定要分；作為框架集的一定要合（不然你寫一堆介面 ，自己調著都煩）。
解耦要看實際情況，不要一昧的解耦，當然都耦合在一起，誰痛苦誰知道
10. 職責劃分
11. 介面設計
12. 變
複雜一點，需要做抽象，轉換，把乙個問題轉變為另乙個問題
13. 換
換個形式，比如使用設計模式，用於改變流程，其實就是改變了**的理解方式，換湯不換藥
14. 仿
就是偷，自己做不明白就偷別人的。先用起來
15. 造
用著用著等你理解了，再去改造成自己的。先要結果，再追求提高
[補充一下仿造]
比如對於設計模式中的工廠方法模式，一開始不理解，可以先拿來在專案中簡單模組中使用， 後面用的多了，理解深了就可以改造拓展
這裡對部分概念做一下補充（還是針對 流程、功能方法和資料結構）
1. 重構
重構和設計模式，只能用在流程上功能方法是比較單一的，除非你寫的有問題，不然就那幾行，沒什麼可重構的。
主要重構的是流程，流程複雜化、不容易理解和控制。重構就是改的簡單容易理解一點，那怎麼簡單起來呢，應用設計模式一開始的時候，除非你很有經驗，不然的話，不用考慮設計模式的問題。當你開始撓頭的時候，怎麼這麼亂，都不想寫了，這個時候開始重構，引入設計模式。
2. 資料結構
資料結構影響功能實現和效能。
功能實現基本大家都能做到，其實實現功能根本就不是程式設計師的追求。追求的是怎麼實現好。
如果沒有效能問題，不要輕易重構。資料結構在流程裡是可以轉變的，通過功能方法轉變，所以方法設計好了，資料結構和流程是可以解耦的，不太需要關心
3. 功能方法
功能方法設計，簡單 簡單 簡單，不要乙個方法做多件事，恨不得它是萬能的。相反只要這個方法能做好一件事，就是乙個合格的方法， 粒度就是單一，容易拿掉、修改和重現實現，而且便於理解。
設計模式實現是非功能需求，如果想不到適用性，就不要強加，沒啥用多寫多看，有經驗再用
下面是乙個 windows專案為例的實用框架搭建
軟體開發專案流程
當我們發現市場上有乙個專案有利可圖，且我們有能力做的時候，發起的一次專案可行性 關於立項，我們根據自己公司的情況來下定義，因為大的網際網路公司都有比較正規的立項流程，我們這裡不做介紹。這裡我們主要介紹關於中小型公司，沒有特別標準的流程的公司。根據專案整合管理工程師的教課資料，總結以下階段 專案建議書...
軟體開發流程
課程的主講老師是msdn的特約講師邵志東先生。課程中間，邵志東老師介紹了軟體開發流程 程式設計師基本素質 關於質量控制和開發模板及專案組建設。邵老師首先介紹了軟體開發的流程，他把軟體開發分為了兩大類，即專案開發及產品開發。專案開發是公司根據某一客戶的需求單獨為某一客戶訂製的軟體 產品開發是公司針對某...
軟體開發流程
軟體開發流程 software development process 即軟體設計思路和方法的一般過程，包括設計軟體的功能和實現的演算法和方法 軟體的總體結構設計和模組設計 程式設計和除錯 程式聯調和測試以及編寫 提交程式。第一步 需求調研分析 1相關系統分析員向使用者初步了解需求，然後用word列...