还是很多人对 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 看得甚高的工程师们，在这样现实的商业生活中，你会
怎么做的让我刮目相看呢？

满实在的XD…

这你们系统架构的问题, user 跟权限在数据库本来就应该分开,每个功能都有一个开关。或是用role based 来管理权限。

很无奈

BignoZe 显然你没有搞懂，系统架构只能处理能够预知的问题，无法处理没有预料到的问题

这问题有的时候我觉得产品经理还有老板的观念与坚持很重要

楼上正解，很多code会变成这样，上面的人通常是主因

老实说，没有人能在市场面前坚持什么的。能够坚持的，通常已经大到可以寡占的地步，不缺你一个客人

我同意expup,如果RD或RD head没办法捍卫自己的原则跟自己维护的程式,就是只能跟着沉沦或者一走了之, 二选一..

楼上，那我就要问，公司要扩大市占，保护品牌，RD lead在那边坚持或反抗，那RD究竟是助力还是阻力

上头开出跟原设计牴触的需求，就只能贴药膏了

直接在权限系统新增一个该客户专用的角色就好了我们公司也是 常常有这种小规则特例......

如果那个技术债留在哪里,你会常看到,常改到,会造成维护成本

反正时间到我就跑了 懒得重构 主管要干啥随便他吧

那你就值得花时间帮特例重构,如果是很久都碰不到,那就随个人重构的开发成本就跟RD head报工时,如果主事者知道不好但不想

讨论还是就不要深究实作，因为我并没有提供详细的系统内部设计的资讯，单纯只有这个scenario 是真人真事

改进,或是连坏气味都不懂,你做的又痛苦,那还不快逃?

这个例子实在是达不到写不出clean code 的程度

外包商根本不能反抗

任何事都有成本 只是成本谁担而已 这个案例就是RD担 等哪天RD不担跑了 就看什么时候爆炸 不是不报 时候未到罢了

XD

商业上许多妥协是必要之恶理念上我们要追求clean谴责dirty现实中只能无奈

原本产品假设被broken 这是spec问题 哪是clean code要管的

用dirty去硬解商业需求 管不了clean不clean 是这意思吧

系统架构就没有考虑到未来的弹性呀 功能开开关关的很正常设计的人经验不够 导致要写烂code来处理 都怪别人就饱了呀

Spec 只是 paper, change implement 难道不是 code?那我还真不懂 clean code 是干嘛的BignoZe 弹性都是事后讲讲的干话而已，需求永远都会超过你预期的弹性而且你也不知道真实系统是什么样子，就不要秀下限了，怪“不够弹性”大概是最无能的manager口头禅了没有之一

超过了不就是要重构了吗？ 还是说重构一定要大规模才可？

事实上 clean code与敏捷开发 就是为了解决你提的那个真实

这种业务主管每天讲的干话你就不要拿来降低自己身价了

不过就我自己在一线跟客户嘴砲的经验来看 原文案例的客服经理问题也很大就是 没有发挥缓冲的功用

clean code与一些设计准则当然不是银弹 我还没见过有谁敢说这些东西是银弹 但真的完全没有价值 FLAG与网络上一狗票大神也不会这么重视这些了 是吧？要战这些喔 烦请自己google吧 欧美已经战好几年了XDDHH之前也战过TDD啊 XD

现实上不管当初怎么设计, 永远就是会出现目前规划无法处理的状况要谈设计准则, 先讨论设计的是应用系统还是工具软件吧

是阿 现实就是如此 但是发生第一个例子时就开始重构似乎也不够现实

应用软件永远都要考虑到完全相反的使用, 这是现实环境使然工具软件当然可以很潇洒地说目前不支援

没有错 需求永远在变 所以才需要重构 所以才需要测试

其实工程师真正的专业是在刚好的欠债，漂亮的还债。既设计的刚好，不过度设计，又能因应变化时不伤筋动骨。架构不会好高骛远，杀鸡用牛刀，懂domain跟限制，才能刚好，刚好才是最好，但这得有clean code当基本功。不然就是只欠债，拿credit，债让别人还，自己爽的咖。

这么简单的需求都能弄成这样 我也是满佩服 你开一个table

我的意思是 需求一直在变不能拿来当写烂code的理由就是了

不过现实上留债给别人的咖洨才是绩效好的, 因为速度快

根据不同地方要开关的功能 select 出 user 来不就好了写成这样还要怪东怪西的 还怪别人秀下限 也是幽默XD

维护性跟clean code对长官来说根本无用

对长官无用 但对工程师有用的 你也不想写出来的东西整天出bug 搞得长官不信任你的程式吧？XD事实已经证明 没顾虑到维护性 程式写出来出包机率高太多阿你做这些工 并不是为了公司长官 是为了你自己好吧 XD

nono~ 这些东西爆炸的时候, 当初开发的人已经不知道去哪了

还是你觉得意大利面写法 处处workaround 出错率会比好好整

BignoZe你还在纠结你自己的实作和想像出来的系统，那就不奉陪了，自己玩沙吧

那你也应该修改level曾经而不是做cid== 好吗

东西爆炸人已经不知去哪 那你就特别倒楣阿 XD这无解

先说好, 我也是基本教义派, 现实上是观察到流债的咖洨绩效好

你只能 1.好好重构 日后开心维护 2.先改再说别管了 然后之

欢迎你举出更难的例子喔 这个太好解了 不忍嘘XD

oneheat 修改level等于所有客户都受影响，而不是只有来电的那位......

技术差靠邀技术不对，这种现象很常见啊当然是修改该用户的层级，怎么会牵扯到其他人？

解法太多了 但前题是 有好好写了测试 也懂得怎么重构 XD

那就是所有vip的功能他都能用，而不是只有某一只...你没看清楚情境

当然有啊，大哥，就说一种方式是修改该用户的层级了

留债的咖绩效好？那你该考虑的是换公司吧？XD

楼上, 原po的情境就是客户层级只有一个变量代表阿楼楼上

很多案例是 掉坑》先改在说然后不管》一阵子后自然有新的衰鬼接你的坑

贵公司的问题看起来更像是设计阶段考虑的就太少，开发阶段扩充性又不够

一改就可以用全部的VIP功能了, 这就不对

要看他们level是怎么定义的啊，最差新增一个level也比cid的方式好而正常的设计，不会只有一个level去应对到所有的功能权限

先改不管 有衰鬼接 你怎么能肯定衰鬼不会是你自己 XDDDD

应该说,在可预期的地方做到Clean，才能够有让非预期状况Dirty的空间，如果全部都是一团炒面，那我想所谓的”明天用Dirty code上线”也会是天方夜谈吧，Clean好处无庸置疑，但这个词是相对而非绝对

应该先思考一下当发生例外的时候，你们的系统的要怎么扩充，是否具备弹性容易调整外挂上去等等一个level就要map到所有功能，又不具备分层的概念，这样的设计然后说要设计无用，到底是无用还是不会用呢？

oneheat 设计思考的够不够，这是事后打高炮。需求一开始就是一个客户只会有一个等级。这就是91大刚刚说不要过度设计的理由。但是身为推动公司营利的角色，我不会拿当初开的需求去打客服主管脸，而是想办法做到，就这个差别

对岸BAT之一就这么做的，谁跟你打高砲简单一个问题啦，exception 模组你有考虑到吗？怎么扩充？内嵌的代码弹性如何？这是设计阶段就要想到的，打什么高砲

要有原则 但太有原则 你就升不上去

在第二次出现例外状况就应该要重构设计了 对着客户清单一条一条写if 那如果有一万个客户不就完蛋惹 XD

程式语言都有提供exception的概念了，何况是系统设计呢？

业务说一个客户只有一个等级,是你的系统要满足的最低需求,你

@Argos 一定不是一条一条加的，最烂也该有个exception rule or field去判断是否符合该状态，才做对应的处理

贵司已经有两次纪录 因为客户吵就给糖吃 这时CTO应该就知道

的系统可以支援的更多,就是你设计的弹性,不是不能作,是看你

未来这间公司 肯定是还会在开放例外的吧？

也就是未来这位客服经理讲的话 请不要当一回事

就经验不够设计不足或者是看过的东西太少，先怪这东西无用再说，这种是很常见没错有例外真的不是重点，java也有例外处理啊，重点是当例外发生的时候，系统要怎样去外挂上这样的例外处理才是重点

淦 笑死 .... 不过自己遇到 以前遇到都笑不出来

如何建构可以任意开放例外权限的功能 现在就应该纳入时程里还是一个准则 遇到容易改变或预期会改变的 就尽量抽象化

初期设计就没考虑exception的话，真的只能套句版上爱说的，快逃啊！这样的公司期待学到什么@@

但最常遇到的就是这边根本不太可能改变却改变了 那就是重构之时 把这块修成可以适应变化的 系统设计本来就慢慢在演化这个策略也不是我讲的 事实上各大企业开发多半都是这策略吧

通常是哪来的时间重构 有洞补洞

时程问题又是另一个战场囉XD 这牵涉到的东西又更多了

重构派总是会挤出时间重构,反重构派总是会挤出借口不重构

理想是丰腴的, 现实是骨感的

Refactoring也有bottom up的，没人说一定要top down吧

理想通常当然只是理想 这也是为何没有银弹的原因但不能因为达不到100% 就连1%都不做 这不是拿来当借口的吧

开一个黑名单/白名单模组处理这个鸟事,linux driver很多

说真的 这些方法准则 通通基于在一个前题之下

也就是有一批人是积极态度想解决一定程度的问题但有一批人 就认为这太理想化 连动手都不肯动手就放弃了但事实是 有做就是有改善 今天有改善10% 那也是改善

反正时程通通*2 就有时间重构了

这也不是理不理想的问题而是后续叠加代码需要付出多少资源的问题吧重构的目的是为了让将来的开发更有效率，如果重构的时间*2 将来开发也没比较省，那的确没有重构的意义

看来像赶时间的手法 客户少我可能也会这么做吧

其实变因太多了 原文案例 也没写这是新创 还是大公司 系统整体复杂度 人员组成 公司风气 这全是变因啊 XD同样问题 出在三人公司与出在Google里 完全不一样解法啊 XD所以说 不如说 打从一开始这完全就在打高空 XD

这家公司没记错的话一年付300万给楼主，是三人公司也太...

文中的level是群组概念，怎么有人不懂

说不定这他朋友新创企业嘛XD 前不著村后不著店的 就当聊聊

查了之前的纪录,看来跟他解释重构是对牛弹琴.. QQ

如果是role based 就可以新增一个"奥客"权限了

是我的话这种判断就算要下 也是要挤到同一个class里面处理想不到这种做法的人我不认为他程式设计专业到哪里去你这篇文章实在是有为这种无能找借口开脱的嫌疑

线上incident牵扯到商誉跟重要命脉的，紧急程度一定远高于干净程度。先用最快有效的方法解决线上问题绝对合理。但工程师专业在于怎么让重复、类似的问题不会发生第二次，或是未来怎么在设计上避免这问题再发生，怎么用最小成本埋下扩充弹性，不重复自己犯的错，也是成长的一环。解决问题跟满足需求仍然是价值的最高权重，但技术如果舍弃，就会降低自己解决问题跟满足需求的可能性跟可行性。一味只追求高大上的技术、名词或潮流，当然也不容易在限制内用最刚好的解决方案，就像航天飞机上用铅笔的例子一样。

Code在某些情况下是会变得脏 这很无奈 而且很多时候不是RD的

线上紧急问题用最快方式解，既然这问题影响程度这么大，就该想办法根本解，除非无解。

问题 但是RD要有本事让这个脏污不要渗到根处 在合理的cost下

各位都很客气我只好第一嘘了，营运服务的系统会没预先考虑这么基本的例外客户我也是笑笑。就算当下不做也早该架构上开出扩充的弹性。啊，我忘了楼主只会商业模式不会设计模式啦。没关系你就用商业导向解吧，反正最后还是要花钱请高手回来重构。

技术债杠杆就是你认为系统能承受多少技术债?不是不能做而是你有没有打算还?何时?事实是大多公司都不打算还啊不还债的工程师在市场上是什么价位?还是不当工程师?

这种心态就是觉得技术债利息少直接忽视，久了就一次痛还大笔的到时候会不会赚还不知道，有的还还不出债咧！

反正到时候干这些事的工程师离职给后面的人去死 做到功能自己都觉得加不上去摆烂 主管只好请新进人员重写一个的例子也不是没有啊 最后人家还不是不续约

推这篇，理想的lean code只能在open source project，商业世界一切以营运为主

同意紧急事态当然先修再说 但你终究还是得要回来面对的大家完全忽视脏code所带来的风险 其实完全不小于客户在吵写脏东西没事时都没事 等到哪天某工程师失手 权限给错了给

即使数据库没做角色资料表 程式面也是能补足的就像landlord大说的 用class把权限判断包起来

到admin等级的 或是把VIP不小心降级成停权的 那就.....XD

再怎么改也不会到处都是if判断

一个公司如果行销跟财务都想着钱砸越多效果越好 不计成

很懂就改了 一下就出事了啊 XDDDD

说错 是y3k大

专案外包的技术债还不出来就约满不续，钱有赚就好

而且，一般coding也会尽量写65432 == cid 啦满种程度蛮羡慕这样的公司能发300万给楼主的，应该是某寡占企业吧

紧急到立刻要有解的，当然先能解就先上!但接着要考虑的是你持续的稳定与可维护性的问题

其实后来想到 应该是该公司客户权限并不是很重要才会这样

技术债不是个非0则1的问题，除了你知道可以晚一点还债

你试试看银行系统权限这样玩玩看 XD

更要考虑你是否还具备这样的能力还债!如果一直都是跳过会越来越没能力~

完全不在乎脏code带来的bug风险 大概内部也没有code review测试也是简单人工测几次就先上线再说 心脏放大颗福利自然来

就是觉得新人进入难度不是成本 谁来都可以做不差你一个难维护你家的事 加班做就好了 死都死别人当然没差

死别人当然是没什么关系啦XD 工程师出大包火掉就好 但客户

工程师就消耗品

我上面有举例了 需求致上最后客户也是会不续约啊

这就是产业sa的价值

因公司营运叫工程师不要注重程式品质无助工程师职涯发展

const magic numbers 在开头 而且一开始就要注解抽一个档案 define if xxx version do 0000 things大概也只能这样了

要用3个===

同意Masakiad大见解

同 superpai, 这例子...

多少pay出多少code 很明显是不想多花钱

问下为何写成65432 == cid会比较好@@?

内文的例子就看得出工程师的水准，这种基本的例外处理还需要花时间去写一堆if？

65432摆前面不会有null而crash的问题

常数值放作罢只是 equal 避免写成 assign 的防呆而已，这种 lvalue rvalue 左右值的拿来判断工程师素质也太脑补了吧*常数值放左边

可以看的出很多人会继续坚持要clean code然后修复太慢最后商誉受损怪到当初出设计的人身上,你要带着技术信仰的纯工程师了解管理中为结果负责的概念太难

不好好作SA, 换来就是 quick and dirty code

从没听过矿工会变煤老板的

很实在啊不是很同意M大，这篇写的只是比较让大家容易看得懂实务上，并不会只有遇到这几种状况，很难全部都想到

推Masakiad

满贴切的xddd

认真回复的不回 回那种东西...唉商誉受损? 没看人家工程师还不是照办 哪里受损?

这个东西向不是很简单吗。。能讨论成这样

可能这就是他能举出最严重的技术债了

老实说按照以前的工作经验，跑好好的城程式不太可能让人重构，除非撇除重新开发的成本，更主要的是如果导致新的bug出来怎么办通常长官不太会让人动这个，除非你已经赢得主管的新任而且不影响其他案子的进度，更重要的是出现bug被自己扛责任

看公司吧 我改东西 manager 都挺支持的

我以前重构过几次而且也运转的不错，但结果是累死自己

真奇怪 我怎么没看到有人坚持一定要先重构？XD支持要好好修改的 不都几乎同意先用OK蹦止血 但事后有时间还是得好好整理伤口吗？我觉得最后重点都在有没有心而已啦什么时程太紧人力不够需求太多 都是借口 就算你拖了一年 难保哪天出事了 还是总得要有人来收烂摊子

我自己也是重构派的，但我只是讲事实，当突发状况出现，用一些方法解决，通常主管不是让你慢慢重构，而是给你下一个任务了

不然就是完全不管 那诸如此类的workaround就会一直发生然后到最后系统处处充满了可怕的地雷 工程师整天出包 新需求加上去时间也更慢 更痛苦 然后有自知之名的工程师就会走

通常主管原因给你时间和信任慢慢重构是很幸福的

人 后面也征不到厉害的人来因为该公司名声就是烂code+不愿意有时间让人重构 XD这些问题也不是什么新题目了 30年前出版的人月神话就讲过了他讲的是40年前的软件工程 看来40年来完全没啥进步 哈哈

人的问题无解阿...什么开发流程碰到老板一句明天要就GG

这个案例不是加个level就完事了吗有空再重构成用table开关各功能阿

而且很多人都讲没有时间 没有时间 嗯 时间真的紧到这样 那估计也是没时间code review 也是没时间做太多测试 也是没时间写系统文件 大概技术部门也没时间开会讨论架构了 XDDDD然后这么没时间 这么的忙 烂code简单测测 资深也不用看过先上线吧 哇喔 好棒你说这风险会比客户跑来闹 威胁要上网黑公司来得小多少 我

非常中肯 特地登入上来推

也是笑笑 瞻前也要顾后啊 很多事是一体两面的

尤其对新创更是如此 且战且走是很重要的概念与其花时间写无懈可击的架构 不如先确定你产品有人用未来对于重构需求增加了 公司有钱有闲有人力再来解决在商言商 投入成本与公司获利要取得最佳解

也是啦 如果今天该公司新创半年 使用者不到万人 出事也不会

有时候是不得已的

clarkman 有没有时间重构这不是问题，以本篇案例来说是没打算重构，只打算workaround 方式走一辈子

说到底对程式码品质有要求的团队都会找时间插下去重构，先不管本篇难度太低的问题，该案例可以发现系统架构弹性不足，这根本就是排入重构时程的好时机。你可以当下不重构然后开发处理例外事件的模组，但技术部门应该排时间治标（系统架构弹性不足）才对。正常team: workaround => refactoring (维持原有功能但让架构有可扩充空间）=> 将workaround 的逻辑转成模组挂进去本篇：workaround => 再发生 workaround2 => 得到还好没花时间重构的结论

反正A大有一百万的理由告诉你重构无法面对客户的下一个无理要求

因为5%的例外情况，放弃95%XDD

因为商业需求需要dirty code的情况很常见 但是当情况一再重复就可以重构成好管理的架构了 原po就是没能力改又爱抱怨

论他其实在收集工作时用的嘴砲材料的可能性一堆人免费提供各种看法/意见, 在公司遇到类似议题就可以轻松的藉花献佛, 潮爽der科科

大概英文不好？这种讨论随便google就一堆耶 XD本篇吵过的所有论点 欧美论檀那边早己吵过几百遍了吧 XDhttp://lmgtfy.com/?q=agile+is+deadhttp://lmgtfy.com/?q=clean+code+bullshit要收集这些 国外那些文章比较精彩啦

真der, 只是要自己看, 不像这样众人合力帮他重点摘要 XD

而且都在地中文化了，读起来很轻松啊。我英文不好也是大家都知道的

诚实推 XDrz

能每篇都让推文战翻也算是奇耙了

这等成就，Argos网友贡献了一半以上吧

我的经验是公司产品上一定会有Clean dirty code这也没有什么吧 只是有些债要不要还 有的时候根本不用还

clean code前也要人员具更佳解，很多能力就只到那

做的事跟大学刚毕业的菜鸟工程师一样还可以领三百万？是靠爸吗 笑死

抛砖引玉，就像模拟联合国、模拟法庭一样，楼主用心良苦，是真正的架构大师

阅

好说好说 偶尔聊聊这个也不错 当然最后还是在个人选择看你还要待在焦油坑里几年 慢慢沉没 还是有心想要找寻解决方案 减轻一些痛苦和负担

公司营运就是这样 clean code讲的只是理想状态 不可能完全达到