锵锵好, 个人曾经做过两年某产品的 tech support,
处理过 n 百个各种大小客制/bug patch/等等等的临时性大小修改,
小从元件行为的改变, 如 calendar 只要选到年或月不要到日,
大到 DB 资料太多要用某元件加载时会读太久怎么改善的整体调整
每天处理 3~5 个不等
个人认为
1. 它们不冲突
可以 "先" 不论程式如何, 快速的解决问题,
然后 "再" 把程式整理得干净整齐一点
2. 它们其实是依赖关系
就以你的例子, 要插入 if ... 解决好了,
能简单插入 if 然后 return true 解决,
表示最少整理成一个函式, 这已经是 clean code 的一部份了
Ref
Clean Code Chapter 3 Function 简报
第 6 页 : Do One Thing (你的例子里是判断权限)
https://www.slideshare.net/kentwelcome1/clean-code-chapter-3-function
你的例子其实正好支持了 clean code 有用这件事情,
不然连要在哪里插 if 可能都找不到呢
当然我相信一定也有只能一层层硬加没办法整理得更好的情形,
但那表示整个逻辑就是那么复杂、就只能那样做,
和能简化时不简化、能弄得整齐干净不弄放著烂, 是完全无关的两件事
大概4酱
※ 引述《accessdenied (存取违规)》之铭言：
: 还是很多人对 clean code 的乌托邦有着不切实际的梦想....
: 醒醒看看 real world 的例子吧......
: 下面都是真人真事
: 有一天，客服接到客诉，客人发现我们用户条款有模糊不清的地方，导致客人使用我们的
: 服务权益受损。因为某个功能，原本设定为VIP方案才能使用，但用户权益没有厘清，导
: 致这个初阶用户认为自己应该也享有这个功能。
: 在解说无效下（通常都是无效的），客户要求退费并且威胁要 消保官和发文抹黑，客服
: 经理当然为了公司品牌、保全用户，决定个案处理让这位客户能特别使用这个VIP功能...
: .，并且承诺明天就生效。
: 回到 RD 场景，这种 Member.Level 1 的客人要能够使用 某特定 Level 3 的功能，而且
: 不是所有 Level 3 都能用，只有某一只 Level 3 的功能....
: 干，明天就要生效？RD 默默地下 SQL 查出这位客户的 ID, 在那只 Level 3的功能的 au
: thorize code 写下一行非常肮脏的
: if (cid == 65432) return true;
: 上版。
: 事情过后，客户不吵了，RD 内部安排要不要 重购 这个 hotfix, 在 Db 内设定一个exce
: ptional member 的资料表，让客服可以有 UI 设定这种 Level 不到位的特殊顾客？
: 客服经理说：不用，这种情况不会再发生！我们已经更新的客户权益说明，排除这种误解
: ！不会再有下一人！
: RD 面面相觑，客服经理说不会再发生，那我们还需要投入资源做一个例外模组吗？还是
: 就让那个带着 magic number 的怪异 if 停留在程式码中？
: 真实世界的选项是什么，相信大家猜得到。
: 过几天，又发生公司因为系统上版过久，超过官网公告的 downtime 维护时间。等著使用
: 公司系统的用户逐一抗议自己的权益受损，支付吃到饱的费用却超过公告时间无法使用..
: ..
: 接下来谈的补偿办法，又是目前系统根本没有设计过的方式，跟上面提到超越Level限制
: 又是不同的作法。RD 们又开始那著这些客户清单，一条条地输入
: If (cid == .....
: 回头来看，当初没有开发那个 Level 例外的模组是对的，因为后面发生的例外处理，解
: 决方案是什么根本无法预料！
: 但是，这就是“营运”啊！这些处理真的就让公司能在市场上继续发光发热！
: 就连 MS 也做过类似的事情，这未来有空再说。
: 这些dirty code有没有影响未来系统的修改？
: 有的！像是这些写死的逻辑，那些客户现在还在使用吗？还是早就解约离开了？还在使用
: 的，我们更新功能要怎么维持当初客服保证的补偿不会受影响？
: 这些都变成修改系统的干扰。
: 但是，这些顶多增加修改的成本和难度，却没有害当初公司业务根本做不起来。
: 这就是一种技术债杠杆。
: 我想问那些把 clean code 和 DP 看得甚高的工程师们，在这样现实的商业生活中，你会
: 怎么做的让我刮目相看呢？