[請益] 軟體開發的架構與職責

[DongFeng ()]

「半夜睡不著覺, 把心情哼成歌」

大家晚上好, 因為開發卡關卻又睡不著所以上來聊聊近況並且請求建議與協助

先介紹一下我自己, 目前職稱是後端工程師, 使用語言為php, 相關年資累計約五年四個月

目前手上的 Project 使用 Laravel Framework 開發, 程式碼架構依目錄區分為 Controller(Presentation)->Service(Business)->Repository(Data)->Entity

基本上各層的存取範圍以箭頭方向為準且不可逆, 但因為協同開發的關係偶爾還是會出現 Controller直接存取Repository的情況



因為沒有新的 feature/issue 的關係, 所以本週有空檔可以回頭整理之前寫的程式碼

越整理我就越沮喪

我發現自己沒有分辨哪些邏輯該歸類到哪一層的能力, 舉例來說:

--
有一個 MemberService 的 Class, 負責跟會員有關的操作

裡頭有一個方法 paginate 會回傳指定頁數與數量的會員資料, 除了吃指定頁數與數量的參數以外這個方法也吃另一個叫 $filter 的參數

$filter 是陣列型態, 我會在方法的最開始檢查這次的 $filter 傳了哪些篩選條件進來 & 這些篩選條件有沒有符合預期的型態

在這裡我會想: $filter是陣列豈不是說其他要使用這個方法的人還需要知道可用的 key 有哪些? 那是不是把 $filter 拿掉改成 addNameFilter(value)->addGenderFilter(value)->paginate(page, perPage) 這樣比較好?

緊接著另一個聲音又出現了: 這樣是不是例外新增一個 MemberFilterService 比較好? 不然篩選條件越來越多怎麼辦?

後來我保留 $filter, 檢查完 $filter 之後丟給 Repository, 在 Repository 裡頭又寫了一些 if-else 判斷 $filter 提供了哪些篩選條件(但沒檢查內容是否符合預期型態)

然後我又想: 是不是乾脆把檢查的程序搬到 Repository 來就了? 或是在 Repository 裡頭加 addXXXXFilter? 可是這樣 Service 不就沒事幹了?
---

諸如此類的狀況, 導致本週我根本沒做多少事情還創造出一些荒腔走板的程式碼



我可以很快的完整交待的 feature/issue, 只要我能夠忍受程式碼職責切分不清

但事實是我也想不出更好的寫法, 深深感受到自己的無力也對於沒有任何產能感到壓力

希望版上各位前輩能對我這樣的困境給一點建議跟方向, 推薦書籍也行, 我最愛買書了(但都沒時間看QQ)

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.71.15.173
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1530813105.A.DBF.html
推 ttt95217: 這個直接電死
推 panda04056: 找 refactor 相關的書籍？
推 jj0321: Bob大叔是精神支柱
推 handwu: 建議可看看Domain driven design的書，對於各層職責會有
→ handwu: 不同的想法
推 ripple0129: 按照基本思維，Service是功能，Filter自然是在Service
→ ripple0129: ，key不是問題，想用你的filter的人自然本來就需要了
→ ripple0129: 解你的filter使用方式，不然就寫個enum用autocomplete
→ ripple0129: 來選key。
推 abccbaandy: 同樓上，不然就學JAVA流吧，一堆o，定義的清清楚楚
→ ymps3502: https://tinyurl.com/ycr7e4qp
推 Argos: 先提醒 小心走火入魔 XD
→ Argos: 基本上要把握一個大原則 「不要為了設計而設計」
→ Argos: 要為了「改變」而去做設計 也就是說 當你困惑該怎麼分職責
→ Argos: 或要使用哪一個架構時 先使用最簡單 最方便 最直覺的方式解
→ Argos: 功能做出來測試也做好之後 想一想 這個部份是否「很常改變
→ Argos: 」 如果幾乎不會改變 或是依照目前情況看下來 應該是不太會
→ Argos: 有變動 那就可以放著了 如果你不確定這部份是不會之後會修
→ Argos: 改到 你可以和其它工程師和需求方討論看看 甚至做個小投票
→ Argos: 如果一開始就知道這部份常常會因為需求變化而要做更動 那就
→ Argos: 得思考更靈活 但卻更複雜的架構了 這時再來重構它
→ Argos: 回到你提的案例 真正要問的問題 是你的filter未來半年到一
→ Argos: 年內是否會因為需求而要作修改 如果看起來不太會 那就用最
→ Argos: 初的驗證寫好就好了 別再自尋煩惱
→ Argos: 職責切分不清不是大問題 真正的問題是出在 你在沒有必要的
→ Argos: 地方 也做了SOLID和設計模式 造成overdesign
→ Argos: 要知道 職責不是分得越細越好 把東西拆開了 是有代價的