這兩天有點走火入魔。思考業務構件的重用可能性有多大。
我進本公司剛三個月，公司主要面向交通行業，主攻公路勘察設計院資訊化這一細分市場,作了有幾年了,既然作的是管理軟體，實際上對技術的要求並不高，由於it人員的高流動頻率，公司的業務知識積累很難有效傳遞給開發人員，即知識管理上非常欠缺，結果是，處於低水平重複的惡性迴圈，很難為客戶提供高質量的產品和服務。
象我公司發展到這個階段，應該達到了以「二次開發模式」為主，即在該領域的多次開發後，產品原型已提煉出來，在這個基礎上，再給後來的客戶作少量個性化定製開發。當前最迫切的是，將這個「原型」以怎樣的形式描述和保留，抽象到哪乙個層面上，我覺得到領域模型這一級就足夠了，拋開資料庫的困擾，先建自己的商業物件庫，以適當的粒度切分，uml圖為主，輔以文件，描述介面及上下文存根，適用環境等，這些是真正能讓開發人員迅速理解和復用的精華所在。下乙個專案，準備增加這種意識,在實踐中摸索和進步。
將來的發展是考慮mda或者業務構件復用。我想來想去，真正好復用的構件始終是"技術"構件。所謂業務構件，也仍然是程式**段，積累再多，也不能有效應對業務敏捷變化。還真是頭大呀，少量業務非常明確的模組可能會形成「構件」，如使用者許可權管理，工作流。唉，洗洗睡了。
業務不要重用
在最近修改我們公司的專案的定轉活功能時，我發現之前程式設計師寫的乙個類裡，乙個算是mvc模式中的v層的類，寫的 竟然不單是定轉活這個功能使用的，還有其它如活轉定等功能使用。這樣寫的壞處 1 難維護。因為 是多個地方使用，所以修改起來，步步驚心，不知修改了 會對其它什麼功能引起問題。2 不易閱讀 因為...