通過一段時間的看程式和修改別人的程式，簡單做了一下總結，自己的一點觀點，這也是上班後第一次發表到每月技術文章中的文章，現在貼出來，以後自己回頭再看時供自己比較一下。
1.避免「串起來」
如果乙個功能需要多個步驟按次序完成，那麼各個分步驟模組兒之間不要發生呼叫關係，並且按順序執行的要求也不要由每個分步驟模組兒自己來決定，要交由宿主方法來組織。
示例：不推薦模式：
推薦模式：
functiona()
functionb(parameter)
functionc(parameter)
void main()
functiona()
functionb(parameter)
functionc(parameter)
void main()
執行順序由各函式決定
執行順序由宿主方法決定
缺點：模組之間耦合高，不利於**或宿主方法中功能變動時的維護。
優點：各分步驟模組之間偶爾度降低，執行步驟可靈活統一地在宿主方法中被控制。
2．遵循「誰建立，誰負責；取用分開」
如果某個操作需要一些物件作為前提條件，那麼盡量把這些物件的建立和業務操作中依賴物件的處理邏輯分開。
示例：典型的資料庫操作中會出現這種情況，我們運算元據庫表的時候需要先建立一些訪問資料庫的物件如connection，然後利用connection物件去執行我們的sql命令。
我們可以將這個任務劃分為幾個子任務來處理：
a.建立用於資料庫連線的connection物件；
b.構造sql命令的處理邏輯，呼叫連線物件執行命令；
c.連線物件的**；
宿主方法中分別呼叫這幾個模組兒來實現最終的功能。
不推薦模式：
//乙個方法完成所有功能
void main()
//只處理跟業務操作有關的
void functionf(connection conn)
//宿主方法組織完成功能
void main()
缺點：連線物件難以統一管理，**復用性和可移植性不高。
優點：連線物件可以被統一排程管理，減少連線物件只被建立而「忘記」關閉的潛在危險的發生；降低各模組**的複雜性。
3. 資料報裝、驗證或預處理操作應和業務邏輯分開
如果乙個模組有輸入或輸出資料，但是通常情況下又需要對輸入和輸出的資料進行格式轉換，如：輸入資料進行base64格式轉換，輸出資料報裝成json串，那麼建議盡量保持業務處理中的輸入和輸出資料是最原始的，而將資料的預處理和格式轉換等放在專門的模組中處理。
示例：不推薦模式：
void main(p)
//公用的轉換方法
functiona(p)
void main(param)
缺點：如果格式轉化邏輯發生變化，**將難以維護；各業務邏輯部分的**重複過多，模組復用率低。
優點：能夠統一管理資料報轉格式；模組復用率提高，**易於維護。
1 開發規範 常用的版本控制
這裡版本控制是經過筆者在專案中實踐總結得出的,有比較廣的適用範圍,當然也要根據不同的業務有取捨應為筆者水平有限,其中有不足的地方也 往大家指出,多多交流 對於版本控制 我這邊是這樣做的 兩條路線,1.大版本控制,也就是所謂的通過請求的url進行控制 當然也可以在引數進行大版本控制 2.小版本控制,通...
mysql 的開發規範 MySQL開發規範
一 基礎規範 1 使用innodb儲存引擎 2 資料庫字符集使用utf8，校對字符集使用utf8 general ci 3 所有表 欄位都盡量新增注釋 4 庫名 表名 欄位名使用小寫字母，禁止超過32個字元，須見名知意 5 非唯一索引以 idx 欄位1 欄位2 命名，唯一索引必須以 uniq 欄位1...
AS 開發心得
as開發心得 隨著大web時代的來臨，越來越多的開發工作從c s模式轉到b s 模式。前不久公司與某電商合作推出3d內容展示應用。儘管最終結果並不理想，還是就過程中的一些問題總結一下。和所有的指令碼語言類似actionscript 簡稱as 的使用很容易上手。as3.0以前的版本，更多的是面向過程的...