作者DongFeng ()
看板Soft_Job
标题[请益] 软体开发的架构与职责
时间Fri Jul 6 01:51:41 2018
「半夜睡不着觉, 把心情哼成歌」
大家晚上好, 因为开发卡关却又睡不着所以上来聊聊近况并且请求建议与协助
先介绍一下我自己, 目前职称是後端工程师, 使用语言为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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1530813105.A.DBF.html
1F:推 ttt95217: 这个直接电死 07/06 03:05
2F:推 panda04056: 找 refactor 相关的书籍? 07/06 03:20
3F:推 jj0321: Bob大叔是精神支柱 07/06 08:13
4F:推 handwu: 建议可看看Domain driven design的书,对於各层职责会有 07/06 08:36
5F:→ handwu: 不同的想法 07/06 08:36
6F:推 ripple0129: 按照基本思维,Service是功能,Filter自然是在Service 07/06 10:56
7F:→ ripple0129: ,key不是问题,想用你的filter的人自然本来就需要了 07/06 10:56
8F:→ ripple0129: 解你的filter使用方式,不然就写个enum用autocomplete 07/06 10:56
9F:→ ripple0129: 来选key。 07/06 10:56
10F:推 abccbaandy: 同楼上,不然就学JAVA流吧,一堆o,定义的清清楚楚 07/06 11:42
12F:推 Argos: 先提醒 小心走火入魔 XD 07/06 21:26
13F:→ Argos: 基本上要把握一个大原则 「不要为了设计而设计」 07/06 21:26
14F:→ Argos: 要为了「改变」而去做设计 也就是说 当你困惑该怎麽分职责 07/06 21:27
15F:→ Argos: 或要使用哪一个架构时 先使用最简单 最方便 最直觉的方式解 07/06 21:28
16F:→ Argos: 功能做出来测试也做好之後 想一想 这个部份是否「很常改变 07/06 21:28
17F:→ Argos: 」 如果几乎不会改变 或是依照目前情况看下来 应该是不太会 07/06 21:29
18F:→ Argos: 有变动 那就可以放着了 如果你不确定这部份是不会之後会修 07/06 21:30
19F:→ Argos: 改到 你可以和其它工程师和需求方讨论看看 甚至做个小投票 07/06 21:30
20F:→ Argos: 如果一开始就知道这部份常常会因为需求变化而要做更动 那就 07/06 21:31
21F:→ Argos: 得思考更灵活 但却更复杂的架构了 这时再来重构它 07/06 21:31
22F:→ Argos: 回到你提的案例 真正要问的问题 是你的filter未来半年到一 07/06 21:33
23F:→ Argos: 年内是否会因为需求而要作修改 如果看起来不太会 那就用最 07/06 21:33
24F:→ Argos: 初的验证写好就好了 别再自寻烦恼 07/06 21:34
25F:→ Argos: 职责切分不清不是大问题 真正的问题是出在 你在没有必要的 07/06 21:35
26F:→ Argos: 地方 也做了SOLID和设计模式 造成overdesign 07/06 21:35
27F:→ Argos: 要知道 职责不是分得越细越好 把东西拆开了 是有代价的 07/06 21:36