[請益] 菜鳥問一下大家的開發模式
剛轉職幾個月
公司是在做人事相關的系統
看前人留下來的專案看的頭很痛
不知道各位開發時會這樣嗎？
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太菜看得頭痛？
![Re: [請益] 菜鳥問一下大家的開發模式](https://www.gss.com.tw/images/easyblog_articles/592/b2ap3_large_james-harrison-vpOeXr5wmR4-unsplash-2.jpg "Re: [請益] 菜鳥問一下大家的開發模式")
64
Re: [請益]高流量網站和資料結構首先很高興看到原PO發問 能夠這樣追逐更深入的技術，先恭喜你，離高手又更近一步了 我寫程式要飯也好一陣子了，分享一下我從聽說大流量很屌，想玩大流量， 到現在可以真正碰觸到大流量一路的心得 在開始之前，先回應原PO的 搶票網站 例子![Re: [請益]高流量網站和資料結構](https://i.imgur.com/TON1Nidb.jpg "Re: [請益]高流量網站和資料結構")
39
Re: [心得] (轉)軟體開發六年後我改變想法的事情這篇滿有意思的，牽涉的主題很廣，不過有些事情只有一句很難講清楚 針對中間幾點，分享一些我自己的理解 ※ 引述《alihue (wanda wanda)》之銘言： : 看到不錯的文章 翻譯分享一下 : 原文:![Re: [心得] (轉)軟體開發六年後我改變想法的事情](https://martinfowler.com/bliki/images/microservice-verdict/path.png "Re: [心得] (轉)軟體開發六年後我改變想法的事情")
33
Re: [討論] Unit test 的撰寫請益先說結論，先都不要寫。 Legacy system 要先補大範圍的 integration test，確定整體的行為是對的。 如果 code 沒有要再改，不用補細部 unit tests。 原因是因為，原本 API 可能因為設計不良，導致無法寫 unit test 得先 refactor 才有辦法讓它變成 testable，這情況就要先 refactor 再補 UT![Re: [討論] Unit test 的撰寫請益](https://martinfowler.com/logo-sq.png "Re: [討論] Unit test 的撰寫請益")
30
[請益] 降薪到其他領域練功各位前輩好 目前大概有將近三年工作經驗，接近三十歲 年薪約 90 多 兩份工作都是和 ML 相關的 都是產品和專案並行的公司23
[請益] coding style差太多怎辦?大家好 小弟上上份工作快離職前 聽到新進的同事說 他都習慣把程式寫成一個一個小的function 後來離職我花了一點時間學習設計模式13
[心得] 為什麼要學 GraphQL?來聊個簡單的議題? 『為什麼要學 GraphQL?』 部落格好讀版: 身為網站工程師，您不能不知道什麼是 GraphQL，這是一個前端跟後端溝通的 API Query 語法，大幅改善了前後端的合作模式，這篇會跟大家介紹為什麼麼要學 GraphQL， 以及整理出三大 GraphQL 優勢，讓大家了解跟傳統 Restful API 有什麼不同。當然不是![[心得] 為什麼要學 GraphQL?](https://img.youtube.com/vi/00NKSvAraLQ/mqdefault.jpg "[心得] 為什麼要學 GraphQL?")
4
Re: [討論] 用AI寫code產生的疑問AI(GPT)用於Coding的實務心得 作者是虎尾科大資工系陳國益教授，經同意後轉載文字內容，原連結於下: 在上週前往華新麗華授課時，有工程師問到：若有要接手的大型專案，應如何透過AI協助 ，加速對專案的理解速度，或是快速產生手冊、API列表等，傳統上要花非常多時間交互3
Re: [閒聊] 中華499吃到飽 原號攜碼 (簡訊)最近也收到這個專案，剛想來申辦， 結果點選申請的連結過去，沒有這個方案可以選擇(只有999以上資費方案)， 客服也打不進去，不知道有沒有辦過這個專案的板友可以分享一下， 謝謝。 ※ 引述《oppa0312 (OPPA)》之銘言：3
[問題] 專案負責部門與採購部門的權責劃分大家好，小弟近期剛接手公司的總務行政部門，是個新手主管 老闆日前交辦了一項專案，這項專案的前期評估需要蒐集市場資料 並整合不同廠商之間的規格與報價等等內容而擬出建議方案給老闆參考 而現在有個問題讓我有點苦惱 就是需求部門與採購部門之間的權責該怎麼劃分1
[問題] 關於一般活存的期限問題版友好，請教一點關於存款規則的問題 問1. 一般數位活存或定存專案之類 通常會寫「活動期限、專案期限」之類 這期限指的是「申辦期限」還是「配息期」？![[問題] 關於一般活存的期限問題](https://i.imgur.com/VEge8Pmb.jpeg "[問題] 關於一般活存的期限問題")