剛轉職幾個月
公司是在做人事相關的系統
看前人留下來的專案看的頭很痛
不知道各位開發時會這樣嗎？
1.超多class 每個出來的資料都要用一個class去接
2.串接API
就是主專案寫一個class然後透過這個去調用API去抓資料回來之後再放到主專案的class
去調用。
3.專案下分超多方案
這個我不太會解釋
就是我連DB的可能會寫成一個方案
然後要接的Model再寫成另一個方案
每次要看要連哪一個跟要用什麼接都還要看在哪一個方案底下，然後每一個又有交叉參考
各位前輩這樣算是正常的嗎？

假如專案有10多年，亂很正常。

切很細不奇怪，但依賴關係混亂就是問題

交叉參考是互相依賴嗎？其他都正常

等哪天你看到一個class幾萬行，你就會希望他切開了

後續維護 切很正常 因為去改舊code很容易出問題

方案看重複使用率 太少的話我是不會開啦

很正常啊 你這都還沒碰到微服務咧

不然你覺得怎麼做比較好0.0

看來是你的問題

了解一下MVC可能有用？

你建議怎麼寫？有更好的寫法當然更好

你太菜

java對吧 在業界很常見 這就是orm啊 應付很整齊的需求用 但複雜的還是要寫sql 個人更喜歡字典字典和純struct oop是有點走火入魔了java強制類 但部分還是可以寫fp但java的字典就那鳥樣 寫起來太不爽

請問這邊指的方案的英文是什麼？

應該是方案底下很多專案吧？

方案跟專案 應該是 visual studio 的 solution 跟 project但原PO說專案下有很多方案 是否剛好相反?

你上網看一下開源 比較一下就知道了

覺得很正常，聽敘述很像分層式架構

看來起像是切得比較細 分層式架構的樣子遇過資料庫欄位 程式參數 函式之類都用中文的就很彆扭

隕石開發法

OOP code長到最後 都會變成意大利麵珍惜生命 遠離 oop

pop寫的跟義大利麵一樣長是人的問題不是oop的問題

變義大利麵就是封裝沒做好又相互依賴

嗯..菜味很重

問就是隕石

隕石開發

是太菜看得頭痛 還是code太菜看得頭痛？

要不要了解一下分層？

你的問題

真的菜

正常 這叫多層架構？

就orm，至於架構部分要看他偶合性如何吧，如果切成很多層耦合性還很高就爛code 反之的話就你太菜

1. 其實是許多編譯式語言高效的原因之一，所以這個答案也很看你寫什麼語言

每個class切分不同功能是good practice吧？