例如:
一個專案基礎功能點100個功能點,
然后A專案 加了30個特殊的二開需求,
B專案加了20個特殊的二開需求,其中有5個和A專案的需求一樣
C專案加了10個特殊需求,和AB專案需求都不重合.
這個專案我預測基本的功能開發完代碼量在5W-6W行左右.大概要有500個專案吧.
小弟我第一次接觸這樣的專案,有什么好的設計模式可以方便以后的代碼維護嗎?
我現在想好的有兩種方式:
1.把所有的功能點都抽象出來,然后看哪個功能點要修改了,我去重寫一下然后通過工廠方法去找要用的子類
這種我現在能想到的缺點問別人說后期代碼維護成本高.
2.每個專案拷一套代碼(反正代碼量也不多),然后修改完后,上傳SVN.
這種目前想到的缺點是如果要修改一個基類功能要所有的專案都打開一遍修改編譯....
現在比較糾結,不知道要選哪種模式,希望各位大佬可以建議一下.謝謝.
uj5u.com熱心網友回復：
更改思路 ，不是你呼叫我，我呼叫你。而是我發個訊息，有人回應就回應，沒人回應就沒人回應。
加入eventbus，把東西變成訊息驅動
不管你多少專案，都是一樣。專案A，有20組訊息，80個回應。
專案B需要回應的就回應，不需要回應的不理。
實際上這也是java的人為啥在使用kafaka的原因，全部隔離開。每個模塊都沒有直接參考，只有發訊息，回應訊息，他們誰也不認識誰。
你就像你現在一樣，我不認識你，你也不認識我。你只是發了一個訊息，我只是無聊回應你的訊息
uj5u.com熱心網友回復：
我也想知道有什么好的方式 能想到的：利用插件的形式 每種功能制作成插件 需要哪個插哪個
uj5u.com熱心網友回復：
還有一種情況忘記說了:D專案中有10個需求點是在基礎需求上修改一下的.
還有是C/S的專案.
uj5u.com熱心網友回復：
我可以理解為服務端有所有的功能點,然后客戶端隨便怎么訪問嗎?
uj5u.com熱心網友回復：
設計其實就是“畫圖”，而“抽象和擴展”的圖形，在型別圖、狀態圖、用例圖、活動圖等等軟體工程所需要以來的圖紙上都需要有體現。這個不適合本末倒置。在部署的時候，每一個專案總歸有自己的啟動代碼，手寫啟動自己的子類的代碼就可以了。不同專案的子類可以從公共類別庫繼承父類的功能，但是每一個專案沒有必要部署無關的東西，每一個專案的特別的東西應該分開、讓其他專案摸不到。
uj5u.com熱心網友回復：
有一種看似好像“強”實則其實很弱的思路，就是有些人喜歡搞所謂的“集中管理各種型別”的型別，也就是濫用“工廠方法”這個名詞兒。實際上是否恰當、有沒有能力，做過了才知道。一般人要理解不是喊喊口號就能把一切變數都放到一個巨大且雜亂的型別的。uj5u.com熱心網友回復：
我們設計、編程的時候，自然是能少設計型別（包括介面）就少設計型別，能少抽象就少抽象，能少變體就不要替換。真正善于管理大量的“抽象與擴展”特性的人反而知道如何少做，所以你看到的總是高效率、高擴展、特別淺顯和“自然而然”的實作，而不是多么糾結“技識訓”的東西。這個方面是一種哲學，沒有反復走過的道路是不知道深淺的。記住這個經驗就行了。uj5u.com熱心網友回復：
1、沒有銀彈2、底層抽象，上層模板化
3、掌握如上基本原則，開發中優化（比如哪些是可以抽象的，應該抽象的，不能抽象的）
uj5u.com熱心網友回復：
開發完代碼量在5W-6W行左右.大概要有500個專案吧這都是什么意思
很久以前，遇到一個人和我說他的程式里有幾千個表。我想這個系統很大了，我要好好和他切磋一番。
結果那人說了半天，好像就是做了一個他們廠的員工檔案的整理，我就不明白為什么要那么多表了。
他很淡定地說，一個員工一個資訊表，我廠幾千個人，所以要幾千張表。
uj5u.com熱心網友回復：
他可能指五六百個模塊把
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/29685.html
標籤：分析與設計
上一篇：C# 釘釘注冊回呼介面二開