關於開發效率和項目周期的問題貼)

在項目開發的過程中，經常會遇到市場人員急命的催，開發人員玩命的寫，但還是趕不上進度，每個人都感覺很累，卻沒有太大效果。 怎麼辦呢？我想這種情況是可以避免的，退一步說，最起碼應該不會像這個樣子。這裡總結一下自己的一些心得和體會：

1.經常總結完成模組中共性的代碼，封裝成方法或組件，方便以後調用。
   比如，資料訪問，XML配置操作，分頁控制項，資料校正，加密等等我都總結成一個個獨立的模組或組件，使用的時候拿來調用就行了，為項目爭取了很多時間，也留出更多的時間來想商務邏輯的處理。

2.複雜業務簡單化
   對一些複雜的業務系統，可以通過抽象的方式，來簡單化，把複雜的問題抽象成簡單的模型，變成人們容易理解的業務模型。能用簡單的方式解決的問題我們為什麼要搞的那麼複雜。我們開發軟體就是來解決問題的，不是來做秀的。

3.思路清晰，代碼簡潔，通讀易懂。特別對團隊開發很是重要。
   我不知道有些程式員怎麼了，個人英雄主義很重，總是把代碼寫的稀奇古怪，這樣好像來表示自己的不同凡響，技術水平高。其實，我認為作為現在的團隊開發，這樣會給企業帶來很大的隱患。同時我個人覺得這也不是一個好的編碼習慣，因為寫代碼也是人一種表達思想的方式，用最少的話和最精闢的詞表達出人們容易理解的問題才是最厲害的。就像人穿衣服注意整潔一樣，再高貴的衣服，如果不注意整潔，給人的感覺一樣很糟糕的。

4.注意高內聚和低耦合。減少模組間的耦合度，抽離出通用的模組，每個模組就像一塊積木。這樣做一個系統時，如果能充分利用這些資源，會起到事半功倍的效果。省時省力。我總結的角色許可權管理摸塊就是這樣，用到了很多項目，也確實為我節省了不少時間，也可以說為公司創造了不少效益。

5.做好架構設計。好的架構會給開發人員一個明確的導向，且不會讓程式員作太多的無用功和重複勞動和返工。並且好的可擴充性設計會對項目善變的需求有好的應對能力。

6.採用OOP，分層開發等經典的開發模式，從一定程度上減少重複，增強擴充性。

7.盡量採用成熟可靠的技術。
    這句話我想有兩種理解，
一：採用最合適的技術，而不是選擇“最先進”的。不能因為“用技術”而“用技術”。它給項目帶來的後果是不可估量的，風險也是很大的，以至甚至延期等等。當然學習好它還是很好的，但是在做商業應用方面還要考慮好。
二：去用那些已經存在的成熟的模式或代碼，不要自己再去“造車”了。一來縮短開發週期，二來降低風險。所以，我們平常開發時，還是要有一定的“拿來主義”，這沒什麼不好的，相反，應該是一個明智的選擇。

8.學會改變世界。
    寫了很久的程式，養成一個習慣，就是堅持用盡量少的代碼實現盡量多的事情，所以一般能共用的代碼，我就寫成共用的，這樣基本上就減少了不少的代碼量。另外，通過一定的抽象過程，本人已經總結出一定規律，並成功的開發出一個.Net(C#)代碼自動產生器工具，基本上我嘗試了一下，一個有二十幾個表的系統，二十分鐘內，我就完成了三層架構的構建，產生了80%的代碼，這個過程如果純手工的話，我覺得效率高的也要一兩周吧。人類的進步是從使用工具開始的，我們要進步也比須製造工具來替代人工，改變世界，其實我們的生活可以很精彩。

（作者：李天平    轉載請註明）