作者accessdenied (存取违规)
看板Soft_Job
标题Re: [请益] 工作四年多开始迷惘
时间Sun Apr 15 20:02:05 2018
还是很多人对 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 看得甚高的工程师们，在这样现实的商业生活中，你会
怎麽做的让我刮目相看呢？
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.135.20.48
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1523793727.A.CA1.html
1F：推 Vendy: 满实在的XD… 04/15 20:08
2F：推 BignoZe: 这你们系统架构的问题, user 跟权限在资料库本来就应该分 04/15 20:09
3F：→ BignoZe: 开,每个功能都有一个开关。或是用role based 来管理权限 04/15 20:09
4F：→ BignoZe: 。 04/15 20:09
5F：推 jack1218: 很无奈 04/15 20:09
6F：→ accessdenied: BignoZe 显然你没有搞懂，系统架构只能处理能够预 04/15 20:13
7F：→ accessdenied: 知的问题，无法处理没有预料到的问题 04/15 20:13
8F：推 expup: 这问题有的时候我觉得产品经理还有老板的观念与坚持很重要 04/15 20:14
9F：推 abccbaandy: 楼上正解，很多code会变成这样，上面的人通常是主因 04/15 20:17
10F：→ accessdenied: 老实说，没有人能在市场面前坚持什麽的。能够坚持 04/15 20:17
11F：→ accessdenied: 的，通常已经大到可以寡占的地步，不缺你一个客人 04/15 20:17
12F：推 xam: 我同意expup,如果RD或RD head没办法扞卫自己的原则跟自己维护 04/15 20:17
13F：→ xam: 的程式,就是只能跟着沉沦或者一走了之, 二选一.. 04/15 20:18
14F：→ accessdenied: 楼上，那我就要问，公司要扩大市占，保护品牌，RD l 04/15 20:21
15F：→ accessdenied: ead在那边坚持或反抗，那RD究竟是助力还是阻力 04/15 20:21
16F：推 peter9s3b: 上头开出跟原设计抵触的需求，就只能贴药膏了 04/15 20:22
17F：推 vi000246: 直接在权限系统新增一个该客户专用的角色就好了 04/15 20:23
18F：→ vi000246: 我们公司也是 常常有这种小规则特例...... 04/15 20:24
19F：推 xam: 如果那个技术债留在哪里,你会常看到,常改到,会造成维护成本 04/15 20:24
20F：→ vi000246: 反正时间到我就跑了 懒得重构 主管要干啥随便他吧 04/15 20:25
21F：→ xam: 那你就值得花时间帮特例重构,如果是很久都碰不到,那就随个人 04/15 20:26
22F：→ xam: 重构的开发成本就跟RD head报工时,如果主事者知道不好但不想 04/15 20:28
23F：→ accessdenied: 讨论还是就不要深究实作，因为我并没有提供详细的系 04/15 20:28
24F：→ accessdenied: 统内部设计的资讯，单纯只有这个scenario 是真人真 04/15 20:28
25F：→ accessdenied: 事 04/15 20:28
26F：→ xam: 改进,或是连坏气味都不懂,你做的又痛苦,那还不快逃? 04/15 20:28
27F：推 superpai: 这个例子实在是达不到写不出clean code 的程度 04/15 20:46
28F：→ pttworld: 外包商根本不能反抗 04/15 20:46
29F：推 codehard: 任何事都有成本 只是成本谁担而已 这个案例就是RD担 等 04/15 20:49
30F：→ codehard: 哪天RD不担跑了 就看什麽时候爆炸 不是不报 时候未到罢 04/15 20:49
31F：→ codehard: 了 04/15 20:49
32F：推 XXXXLAY: XD 04/15 20:50
33F：推 PUTOUCHANG: 商业上许多妥协是必要之恶 04/15 20:56
34F：→ PUTOUCHANG: 理念上我们要追求clean谴责dirty现实中只能无奈 04/15 20:58
35F：推 rodion: 原本产品假设被broken 这是spec问题 哪是clean code要管的 04/15 21:01
36F：推 del680202: 用dirty去硬解商业需求 管不了clean不clean 是这意思吧 04/15 21:05
37F：推 BignoZe: 系统架构就没有考虑到未来的弹性呀 功能开开关关的很正常 04/15 21:07
38F：→ BignoZe: 设计的人经验不够 导致要写烂code来处理 都怪别人就饱了 04/15 21:07
39F：→ BignoZe: 呀 04/15 21:07
40F：→ accessdenied: Spec 只是 paper, change implement 难道不是 code? 04/15 21:09
41F：→ accessdenied: 那我还真不懂 clean code 是干嘛的 04/15 21:09
42F：→ accessdenied: BignoZe 弹性都是事後讲讲的干话而已，需求永远都会 04/15 21:10
43F：→ accessdenied: 超过你预期的弹性 04/15 21:10
44F：→ accessdenied: 而且你也不知道真实系统是什麽样子，就不要秀下限了 04/15 21:12
45F：→ accessdenied: ，怪「不够弹性」大概是最无能的manager口头禅了没 04/15 21:12
46F：→ accessdenied: 有之一 04/15 21:12
47F：推 art1: 超过了不就是要重构了吗？ 还是说重构一定要大规模才可？ 04/15 21:12
48F：→ Argos: 事实上 clean code与敏捷开发 就是为了解决你提的那个真实 04/15 21:12
49F：→ accessdenied: 这种业务主管每天讲的干话你就不要拿来降低自己身 04/15 21:12
50F：→ accessdenied: 价了 04/15 21:12
51F：→ Argos: 案例 但你显然完全不懂该技术的眉角在哪里 解释也是对牛弹 04/15 21:12
52F：→ Argos: 琴吧？XD 不如自己去书店翻翻书如何？ 04/15 21:13
53F：→ Argos: 一堆书里比你这案例更夸张的都有 也有提出一些准则 04/15 21:13
54F：→ Argos: 当然啦 如果你从头到尾还是对这个没概念 那就继续打高空 04/15 21:14
55F：推 del680202: 不过就我自己在一线跟客户嘴炮的经验来看 原文案例的 04/15 21:15
56F：→ del680202: 客服经理问题也很大就是 没有发挥缓冲的功用 04/15 21:15
57F：→ Argos: clean code与一些设计准则当然不是银弹 我还没见过有谁敢说 04/15 21:16
58F：→ Argos: 这些东西是银弹 但真的完全没有价值 FLAG与网路上一狗票大 04/15 21:16
59F：→ Argos: 神也不会这麽重视这些了 是吧？ 04/15 21:16
60F：→ Argos: 要战这些喔 烦请自己google吧 欧美已经战好几年了XD 04/15 21:18
61F：→ Argos: DHH之前也战过TDD啊 XD 04/15 21:18
62F：推 atpx: 现实上不管当初怎麽设计, 永远就是会出现目前规划无法处理的 04/15 21:18
63F：→ atpx: 状况 04/15 21:18
64F：→ atpx: 要谈设计准则, 先讨论设计的是应用系统还是工具软体吧 04/15 21:19
65F：推 Sunal: 是阿 现实就是如此 但是发生第一个例子时就开始重构 04/15 21:19
66F：→ Sunal: 似乎也不够现实 04/15 21:19
67F：→ atpx: 应用软体永远都要考虑到完全相反的使用, 这是现实环境使然 04/15 21:20
68F：→ atpx: 工具软体当然可以很潇洒地说目前不支援 04/15 21:20
69F：→ Argos: 没有错 需求永远在变 所以才需要重构 所以才需要测试 04/15 21:20
70F：→ landlord: 其实工程师真正的专业是在刚好的欠债，漂亮的还债。既 04/15 21:20
71F：→ landlord: 设计的刚好，不过度设计，又能因应变化时不伤筋动骨。 04/15 21:20
72F：→ landlord: 架构不会好高骛远，杀鸡用牛刀，懂domain跟限制，才能 04/15 21:20
73F：→ landlord: 刚好，刚好才是最好，但这得有clean code当基本功。不 04/15 21:20
74F：→ landlord: 然就是只欠债，拿credit，债让别人还，自己爽的咖。 04/15 21:20
75F：推 BignoZe: 这麽简单的需求都能弄成这样 我也是满佩服 你开一个table 04/15 21:21
76F：→ Argos: 我的意思是 需求一直在变不能拿来当写烂code的理由就是了 04/15 21:21
77F：→ atpx: 不过现实上留债给别人的咖洨才是绩效好的, 因为速度快 04/15 21:22
78F：→ BignoZe: 根据不同地方要开关的功能 select 出 user 来不就好了 04/15 21:22
79F：→ BignoZe: 写成这样还要怪东怪西的 还怪别人秀下限 也是幽默XD 04/15 21:22
80F：→ atpx: 维护性跟clean code对长官来说根本无用 04/15 21:23
81F：→ Argos: 对长官无用 但对工程师有用的 你也不想写出来的东西整天出 04/15 21:23
82F：→ Argos: bug 搞得长官不信任你的程式吧？XD 04/15 21:24
83F：→ Argos: 事实已经证明 没顾虑到维护性 程式写出来出包机率高太多阿 04/15 21:24
84F：→ Argos: 你做这些工 并不是为了公司长官 是为了你自己好吧 XD 04/15 21:25
85F：推 atpx: nono~ 这些东西爆炸的时候, 当初开发的人已经不知道去哪了 04/15 21:25
86F：→ Argos: 还是你觉得义大利面写法 处处workaround 出错率会比好好整 04/15 21:25
87F：→ accessdenied: BignoZe你还在纠结你自己的实作和想像出来的系统， 04/15 21:25
88F：→ accessdenied: 那就不奉陪了，自己玩沙吧 04/15 21:25
89F：→ Argos: 里过的code来得低？呵呵 那当我的话耳边风罗 04/15 21:25
90F：推 oneheat: 那你也应该修改level曾经而不是做cid== 好吗 04/15 21:26
91F：→ Argos: 东西爆炸人已经不知去哪 那你就特别倒楣阿 XD这无解 04/15 21:26
92F：→ atpx: 先说好, 我也是基本教义派, 现实上是观察到流债的咖洨绩效好 04/15 21:26
93F：→ Argos: 你只能 1.好好重构 日後开心维护 2.先改再说别管了 然後之 04/15 21:27
94F：推 BignoZe: 欢迎你举出更难的例子喔 这个太好解了 不忍嘘XD 04/15 21:27
95F：→ Argos: 後又出包 你还是要回去痛苦加班 3.离职 XD 04/15 21:27
96F：→ accessdenied: oneheat 修改level等於所有客户都受影响，而不是只 04/15 21:27
97F：→ accessdenied: 有来电的那位...... 04/15 21:27
98F：推 oneheat: 技术差靠邀技术不对，这种现象很常见啊 04/15 21:27
99F：→ oneheat: 当然是修改该用户的层级，怎麽会牵扯到其他人？ 04/15 21:28
100F：→ Argos: 解法太多了 但前题是 有好好写了测试 也懂得怎麽重构 XD 04/15 21:29
101F：→ accessdenied: 那就是所有vip的功能他都能用，而不是只有某一只... 04/15 21:29
102F：→ accessdenied: 你没看清楚情境 04/15 21:29
103F：→ Argos: 显然 很多人完全不懂 也不想懂 然後就抛问题 觉得无解 XD 04/15 21:29
104F：→ Argos: 把烂code都归咎於这个喔 嗯 很棒的藉口罗 04/15 21:29
105F：→ oneheat: 当然有啊，大哥，就说一种方式是修改该用户的层级了 04/15 21:29
106F：→ Argos: 留债的咖绩效好？那你该考虑的是换公司吧？XD 04/15 21:31
107F：推 atpx: 楼上, 原po的情境就是客户层级只有一个变数代表阿 04/15 21:31
108F：→ atpx: 楼楼上 04/15 21:31
109F：推 del680202: 很多案例是 掉坑》先改在说然後不管》一阵子後自然有新 04/15 21:31
110F：→ del680202: 的衰鬼接你的坑 04/15 21:31
111F：推 oneheat: 贵公司的问题看起来更像是设计阶段考虑的就太少，开发阶 04/15 21:32
112F：→ oneheat: 段扩充性又不够 04/15 21:32
113F：→ atpx: 一改就可以用全部的VIP功能了, 这就不对 04/15 21:32
114F：推 oneheat: 要看他们level是怎麽定义的啊，最差新增一个level也比cid 04/15 21:33
115F：→ oneheat: 的方式好 04/15 21:33
116F：→ oneheat: 而正常的设计，不会只有一个level去应对到所有的功能权 04/15 21:34
117F：→ oneheat: 限 04/15 21:34
118F：→ Argos: 先改不管 有衰鬼接 你怎麽能肯定衰鬼不会是你自己 XDDDD 04/15 21:36
119F：嘘 smallchocho: 应该说,在可预期的地方做到Clean， 04/15 21:36
120F：→ smallchocho: 才能够有让非预期状况Dirty的空间， 04/15 21:36
121F：→ smallchocho: 如果全部都是一团炒面，那我想所谓的 04/15 21:36
122F：→ smallchocho: ”明天用Dirty code上线”也会是天方夜谈吧， 04/15 21:36
123F：→ smallchocho: Clean好处无庸置疑，但这个词是相对而非绝对 04/15 21:36
124F：→ Argos: 那刚好是你自己不就作死了 04/15 21:36
125F：推 oneheat: 应该先思考一下当发生例外的时候，你们的系统的要怎麽扩 04/15 21:37
126F：→ oneheat: 充，是否具备弹性容易调整外挂上去等等 04/15 21:37
127F：→ oneheat: 一个level就要map到所有功能，又不具备分层的概念，这样 04/15 21:38
128F：→ oneheat: 的设计然後说要设计无用，到底是无用还是不会用呢？ 04/15 21:38
129F：→ accessdenied: oneheat 设计思考的够不够，这是事後打高炮。需求一 04/15 21:40
130F：→ accessdenied: 开始就是一个客户只会有一个等级。这就是91大刚刚 04/15 21:40
131F：→ accessdenied: 说不要过度设计的理由。但是身为推动公司营利的角 04/15 21:40
132F：→ accessdenied: 色，我不会拿当初开的需求去打客服主管脸，而是想 04/15 21:40
133F：→ accessdenied: 办法做到，就这个差别 04/15 21:40
134F：推 oneheat: 对岸BAT之一就这麽做的，谁跟你打高炮 04/15 21:41
135F：推 oneheat: 简单一个问题啦，exception 模组你有考虑到吗？怎麽扩充 04/15 21:42
136F：→ oneheat: ？内嵌的代码弹性如何？这是设计阶段就要想到的，打什麽 04/15 21:42
137F：→ oneheat: 高炮 04/15 21:42
138F：→ MOONY135: 要有原则 但太有原则 你就升不上去 04/15 21:43
139F：→ Argos: 在第二次出现例外状况就应该要重构设计了 对着客户清单一条 04/15 21:43
140F：→ Argos: 一条写if 那如果有一万个客户不就完蛋惹 XD 04/15 21:44
141F：→ oneheat: 程式语言都有提供exception的概念了，何况是系统设计呢？ 04/15 21:44
142F：→ xam: 业务说一个客户只有一个等级,是你的系统要满足的最低需求,你 04/15 21:45
143F：→ oneheat: @Argos 一定不是一条一条加的，最烂也该有个exception ru 04/15 21:45
144F：→ oneheat: le or field去判断是否符合该状态，才做对应的处理 04/15 21:45
145F：→ Argos: 贵司已经有两次纪录 因为客户吵就给糖吃 这时CTO应该就知道 04/15 21:45
146F：→ xam: 的系统可以支援的更多,就是你设计的弹性,不是不能作,是看你 04/15 21:46
147F：→ Argos: 未来这间公司 肯定是还会在开放例外的吧？ 04/15 21:46
148F：→ xam: 会不会作跟要不要作而已. 04/15 21:46
149F：→ Argos: 也就是未来这位客服经理讲的话 请不要当一回事 04/15 21:47
150F：推 oneheat: 就经验不够设计不足或者是看过的东西太少，先怪这东西无 04/15 21:47
151F：→ oneheat: 用再说，这种是很常见没错 04/15 21:47
152F：→ oneheat: 有例外真的不是重点，java也有例外处理啊，重点是当例外 04/15 21:48
153F：→ oneheat: 发生的时候，系统要怎样去外挂上这样的例外处理才是重点 04/15 21:48
154F：推 Timba: 淦 笑死 .... 不过自己遇到 以前遇到都笑不出来 04/15 21:50
155F：→ Argos: 如何建构可以任意开放例外权限的功能 现在就应该纳入时程里 04/15 21:52
156F：→ Argos: 还是一个准则 遇到容易改变或预期会改变的 就尽量抽象化 04/15 21:53
157F：推 oneheat: 初期设计就没考虑exception的话，真的只能套句版上爱说 04/15 21:54
158F：→ oneheat: 的，快逃啊！这样的公司期待学到什麽@@ 04/15 21:54
159F：→ Argos: 但最常遇到的就是这边根本不太可能改变却改变了 那就是重构 04/15 21:54
160F：→ Argos: 之时 把这块修成可以适应变化的 系统设计本来就慢慢在演化 04/15 21:55
161F：→ Argos: 这个策略也不是我讲的 事实上各大企业开发多半都是这策略吧 04/15 21:56
162F：→ MOONY135: 通常是哪来的时间重构 有洞补洞 04/15 21:56
163F：→ Argos: 时程问题又是另一个战场罗XD 这牵涉到的东西又更多了 04/15 21:58
164F：推 xam: 重构派总是会挤出时间重构,反重构派总是会挤出藉口不重构 04/15 21:58
165F：→ Argos: 强的可以一周就重构好 弱的可能三个月 那怎麽解？XD 04/15 21:58
166F：→ PUTOUCHANG: 理想是丰腴的, 现实是骨感的 04/15 21:58
167F：推 oneheat: Refactoring也有bottom up的，没人说一定要top down吧 04/15 21:59
168F：→ Argos: 理想通常当然只是理想 这也是为何没有银弹的原因 04/15 21:59
169F：→ Argos: 但不能因为达不到100% 就连1%都不做 这不是拿来当藉口的吧 04/15 21:59
170F：推 askacis: 开一个黑名单/白名单模组处理这个鸟事,linux driver很多 04/15 22:00
171F：→ Argos: 说真的 这些方法准则 通通基於在一个前题之下 04/15 22:00
172F：→ askacis: 时候为了相容各家chip也大多都是这样处理的 04/15 22:00
173F：→ Argos: 也就是有一批人是积极态度想解决一定程度的问题 04/15 22:01
174F：→ Argos: 但有一批人 就认为这太理想化 连动手都不肯动手就放弃了 04/15 22:01
175F：→ Argos: 但事实是 有做就是有改善 今天有改善10% 那也是改善 04/15 22:02
176F：→ MOONY135: 反正时程通通*2 就有时间重构了 04/15 22:02
177F：推 oneheat: 这也不是理不理想的问题而是後续叠加代码需要付出多少资 04/15 22:03
178F：→ oneheat: 源的问题吧 04/15 22:03
179F：→ oneheat: 重构的目的是为了让将来的开发更有效率，如果重构的时间* 04/15 22:04
180F：→ oneheat: 2 将来开发也没比较省，那的确没有重构的意义 04/15 22:04
181F：→ testPtt: 看来像赶时间的手法 客户少我可能也会这麽做吧 04/15 22:04
182F：→ Argos: 其实变因太多了 原文案例 也没写这是新创 还是大公司 系统 04/15 22:05
183F：→ Argos: 整体复杂度 人员组成 公司风气 这全是变因啊 XD 04/15 22:05
184F：→ Argos: 同样问题 出在三人公司与出在Google里 完全不一样解法啊 XD 04/15 22:06
185F：→ Argos: 所以说 不如说 打从一开始这完全就在打高空 XD 04/15 22:07
186F：推 oneheat: 这家公司没记错的话一年付300万给楼主，是三人公司也太.. 04/15 22:08
187F：→ oneheat: . 04/15 22:08
188F：→ pttworld: 文中的level是群组概念，怎麽有人不懂 04/15 22:10
189F：→ Argos: 说不定这他朋友新创企业嘛XD 前不着村後不着店的 就当聊聊 04/15 22:10
190F：→ xam: 查了之前的纪录,看来跟他解释重构是对牛弹琴.. QQ 04/15 22:14
191F：→ yyc1217: 如果是role based 就可以新增一个"奥客"权限了 04/15 22:24
192F：推 y3k: 是我的话这种判断就算要下 也是要挤到同一个class里面处理 04/15 22:30
193F：→ y3k: 想不到这种做法的人我不认为他程式设计专业到哪里去 04/15 22:30
194F：→ y3k: 你这篇文章实在是有为这种无能找藉口开脱的嫌疑 04/15 22:32
195F：→ landlord: 线上incident牵扯到商誉跟重要命脉的，紧急程度一定远 04/15 22:38
196F：→ landlord: 高於乾净程度。先用最快有效的方法解决线上问题绝对合 04/15 22:38
197F：→ landlord: 理。但工程师专业在於怎麽让重复、类似的问题不会发生 04/15 22:38
198F：→ landlord: 第二次，或是未来怎麽在设计上避免这问题再发生，怎麽 04/15 22:38
199F：→ landlord: 用最小成本埋下扩充弹性，不重复自己犯的错，也是成长 04/15 22:39
200F：→ landlord: 的一环。解决问题跟满足需求仍然是价值的最高权重，但 04/15 22:39
201F：→ landlord: 技术如果舍弃，就会降低自己解决问题跟满足需求的可能 04/15 22:39
202F：→ landlord: 性跟可行性。一味只追求高大上的技术、名词或潮流，当 04/15 22:39
203F：→ landlord: 然也不容易在限制内用最刚好的解决方案，就像太空梭上 04/15 22:39
204F：→ landlord: 用铅笔的例子一样。 04/15 22:39
205F：→ y3k: Code在某些情况下是会变得脏 这很无奈 而且很多时候不是RD的 04/15 22:39
206F：→ landlord: 线上紧急问题用最快方式解，既然这问题影响程度这麽大 04/15 22:40
207F：→ landlord: ，就该想办法根本解，除非无解。 04/15 22:40
208F：→ y3k: 问题 但是RD要有本事让这个脏污不要渗到根处 在合理的cost下 04/15 22:40
209F：嘘 Masakiad: 各位都很客气我只好第一嘘了，营运服务的系统会没预先 04/15 22:41
210F：→ Masakiad: 考虑这麽基本的例外客户我也是笑笑。就算当下不做也早 04/15 22:41
211F：→ Masakiad: 该架构上开出扩充的弹性。啊，我忘了楼主只会商业模式 04/15 22:41
212F：→ Masakiad: 不会设计模式啦。没关系你就用商业导向解吧，反正最後 04/15 22:41
213F：→ Masakiad: 还是要花钱请高手回来重构。 04/15 22:41
214F：→ ku399999: 技术债杠杆就是你认为系统能承受多少技术债?不是不能做 04/15 22:42
215F：→ ku399999: 而是你有没有打算还?何时?事实是大多公司都不打算还啊 04/15 22:42
216F：→ ku399999: 不还债的工程师在市场上是什麽价位?还是不当工程师? 04/15 22:44
217F：→ Masakiad: 这种心态就是觉得技术债利息少直接忽视，久了就一次痛 04/15 22:45
218F：→ Masakiad: 还大笔的到时候会不会赚还不知道，有的还还不出债咧！ 04/15 22:45
219F：→ ku399999: 反正到时候干这些事的工程师离职给後面的人去死 做到功 04/15 22:49
220F：→ ku399999: 能自己都觉得加不上去摆烂 主管只好请新进人员重写一个 04/15 22:50
221F：→ ku399999: 的例子也不是没有啊 最後人家还不是不续约 04/15 22:50
222F：推 takingblue: 推这篇，理想的lean code只能在open source project 04/15 22:53
223F：→ takingblue: ，商业世界一切以营运为主 04/15 22:53
224F：→ Argos: 同意紧急事态当然先修再说 但你终究还是得要回来面对的 04/15 22:54
225F：→ Argos: 大家完全忽视脏code所带来的风险 其实完全不小於客户在吵 04/15 22:54
226F：→ Argos: 写脏东西没事时都没事 等到哪天某工程师失手 权限给错了给 04/15 22:55
227F：→ vi000246: 即使资料库没做角色资料表 程式面也是能补足的 04/15 22:55
228F：→ vi000246: 就像landlord大说的 用class把权限判断包起来 04/15 22:56
229F：→ Argos: 到admin等级的 或是把VIP不小心降级成停权的 那就.....XD 04/15 22:56
230F：→ vi000246: 再怎麽改也不会到处都是if判断 04/15 22:56
231F：→ Argos: 啊不要以为不会发生这种事 哪个不熟的新人进来 脏code看没 04/15 22:56
232F：→ ku399999: 一个公司如果行销跟财务都想着钱砸越多效果越好 不计成 04/15 22:57
233F：→ Argos: 很懂就改了 一下就出事了啊 XDDDD 04/15 22:57
234F：→ vi000246: 说错 是y3k大 04/15 22:57
235F：→ pttworld: 专案外包的技术债还不出来就约满不续，钱有赚就好 04/15 22:57
236F：→ ku399999: 本的花钱行销 没人踩煞车这样真的有比较好吗 04/15 22:57
237F：推 oneheat: 而且，一般coding也会尽量写65432 == cid 啦 04/15 23:01
238F：推 oneheat: 满种程度蛮羡慕这样的公司能发300万给楼主的，应该是某 04/15 23:02
239F：→ oneheat: 寡占企业吧 04/15 23:02
240F：推 kimkao: 紧急到立刻要有解的，当然先能解就先上! 04/15 23:05
241F：→ kimkao: 但接着要考虑的是你持续的稳定与可维护性的问题 04/15 23:06
242F：→ Argos: 其实後来想到 应该是该公司客户权限并不是很重要才会这样 04/15 23:06
243F：→ kimkao: 技术债不是个非0则1的问题，除了你知道可以晚一点还债 04/15 23:06
244F：→ Argos: 你试试看银行系统权限这样玩玩看 XD 04/15 23:07
245F：→ kimkao: 更要考虑你是否还具备这样的能力还债!如果一直都是跳过 04/15 23:07
246F：→ kimkao: 会越来越没能力~ 04/15 23:07
247F：→ Argos: 完全不在乎脏code带来的bug风险 大概内部也没有code review 04/15 23:08
248F：→ Argos: 测试也是简单人工测几次就先上线再说 心脏放大颗福利自然来 04/15 23:08
249F：→ ku399999: 就是觉得新人进入难度不是成本 谁来都可以做不差你一个 04/15 23:09
250F：→ ku399999: 难维护你家的事 加班做就好了 死都死别人当然没差 04/15 23:09
251F：→ Argos: 死别人当然是没什麽关系啦XD 工程师出大包火掉就好 但客户 04/15 23:10
252F：→ ku399999: 工程师就消耗品 04/15 23:10
253F：→ Argos: 那边是你公司自行承担 这样run公司也蛮强大的 富贵险中求XD 04/15 23:10
254F：→ Argos: 反正到时如果有工程师开错权限 客户经理再道歉开更多权限吧 04/15 23:12
255F：→ ku399999: 我上面有举例了 需求致上最後客户也是会不续约啊 04/15 23:14
256F：推 Csongs: 这就是产业sa的价值 04/15 23:17
257F：→ ku399999: 因公司营运叫工程师不要注重程式品质无助工程师职涯发展 04/15 23:17
258F：推 justben: const magic numbers 在开头 而且一开始就要注解 04/15 23:44
259F：→ justben: 抽一个档案 define if xxx version do 0000 things 04/15 23:45
260F：→ justben: 大概也只能这样了 04/15 23:45
261F：推 deray: 要用3个=== 04/15 23:47
262F：嘘 dfgh012316: 同意Masakiad大见解 04/16 00:01
263F：→ lovdkkkk: 同 superpai, 这例子... 04/16 00:03
264F：推 god145145: 多少pay出多少code 很明显是不想多花钱 04/16 00:25
265F：推 asleisureto: 问下为何写成65432 == cid会比较好@@? 04/16 01:14
266F：→ sorryla: 内文的例子就看得出工程师的水准，这种基本的例外处理还 04/16 01:16
267F：→ sorryla: 需要花时间去写一堆if？ 04/16 01:16
268F：推 ckp4131025: 65432摆前面不会有null而crash的问题 04/16 01:33
269F：→ accessdenied: 常数值放作罢只是 equal 避免写成 assign 的防呆而 04/16 01:47
270F：→ accessdenied: 已，这种 lvalue rvalue 左右值的拿来判断工程师素 04/16 01:47
271F：→ accessdenied: 质也太脑补了吧 04/16 01:47
272F：→ accessdenied: *常数值放左边 04/16 01:47
273F：推 twin2: 可以看的出很多人会继续坚持要clean code然後修复太慢最後 04/16 01:51
274F：→ twin2: 商誉受损怪到当初出设计的人身上,你要带着技术信仰的纯工程 04/16 01:51
275F：→ twin2: 师了解管理中为结果负责的概念太难 04/16 01:51
276F：→ konkonchou: 不好好作SA, 换来就是 quick and dirty code 04/16 02:42
277F：推 bibo9901: 从没听过矿工会变煤老板的 04/16 04:47
278F：推 mathrew: 很实在啊 04/16 07:26
279F：→ mathrew: 不是很同意M大，这篇写的只是比较让大家容易看得懂 04/16 07:27
280F：→ mathrew: 实务上，并不会只有遇到这几种状况，很难全部都想到 04/16 07:28
281F：推 cookie1115: 推Masakiad 04/16 07:36
282F：推 zzshcool: 满贴切的xddd 04/16 07:59
283F：→ ku399999: 认真回覆的不回 回那种东西...唉 04/16 08:51
284F：→ ku399999: 商誉受损? 没看人家工程师还不是照办 哪里受损? 04/16 08:53
285F：推 GoalBased: 这个东西向不是很简单吗。。能讨论成这样 04/16 08:54
286F：→ ku399999: 可能这就是他能举出最严重的技术债了 04/16 08:57
287F：推 clarkman: 老实说按照以前的工作经验，跑好好的城程式不太可能让人 04/16 09:21
288F：→ clarkman: 重构，除非撇除重新开发的成本，更主要的是如果导致新的 04/16 09:21
289F：→ clarkman: bug出来怎麽办 04/16 09:21
290F：→ clarkman: 通常长官不太会让人动这个，除非你已经赢得主管的新任而 04/16 09:23
291F：→ clarkman: 且不影响其他案子的进度，更重要的是出现bug被自己扛责 04/16 09:23
292F：→ clarkman: 任 04/16 09:23
293F：推 steve1012: 看公司吧 我改东西 manager 都挺支持的 04/16 09:24
294F：→ clarkman: 我以前重构过几次而且也运转的不错，但结果是累死自己 04/16 09:24
295F：推 Argos: 真奇怪 我怎麽没看到有人坚持一定要先重构？XD 04/16 09:43
296F：→ Argos: 支持要好好修改的 不都几乎同意先用OK蹦止血 但事後有时间 04/16 09:44
297F：→ Argos: 还是得好好整理伤口吗？我觉得最後重点都在有没有心而已啦 04/16 09:45
298F：→ Argos: 什麽时程太紧人力不够需求太多 都是藉口 就算你拖了一年 难 04/16 09:45
299F：→ Argos: 保哪天出事了 还是总得要有人来收烂摊子 04/16 09:46
300F：推 clarkman: 我自己也是重构派的，但我只是讲事实，当突发状况出现， 04/16 09:47
301F：→ clarkman: 用一些方法解决，通常主管不是让你慢慢重构，而是给你下 04/16 09:47
302F：→ clarkman: 一个任务了 04/16 09:47
303F：→ Argos: 不然就是完全不管 那诸如此类的workaround就会一直发生 04/16 09:47
304F：→ Argos: 然後到最後系统处处充满了可怕的地雷 工程师整天出包 新需 04/16 09:49
305F：→ Argos: 求加上去时间也更慢 更痛苦 然後有自知之名的工程师就会走 04/16 09:50
306F：推 clarkman: 通常主管原因给你时间和信任慢慢重构是很幸福的 04/16 09:50
307F：→ Argos: 人 後面也徵不到厉害的人来因为该公司名声就是烂code+不愿 04/16 09:50
308F：→ Argos: 意有时间让人重构 XD 04/16 09:51
309F：→ Argos: 这些问题也不是什麽新题目了 30年前出版的人月神话就讲过了 04/16 09:54
310F：→ Argos: 他讲的是40年前的软体工程 看来40年来完全没啥进步 哈哈 04/16 09:54
311F：推 abccbaandy: 人的问题无解阿...什麽开发流程碰到老板一句明天要就 04/16 09:57
312F：→ abccbaandy: GG 04/16 09:57
313F：→ hakama99: 这个案例不是加个level就完事了吗 04/16 09:59
314F：→ hakama99: 有空再重构成用table开关各功能阿 04/16 10:00
315F：→ Argos: 而且很多人都讲没有时间 没有时间 嗯 时间真的紧到这样 那 04/16 10:05
316F：→ Argos: 估计也是没时间code review 也是没时间做太多测试 也是没 04/16 10:05
317F：→ Argos: 时间写系统文件 大概技术部门也没时间开会讨论架构了 XDDDD 04/16 10:06
318F：→ Argos: 然後这麽没时间 这麽的忙 烂code简单测测 资深也不用看过先 04/16 10:06
319F：→ Argos: 上线吧 哇喔 好棒 04/16 10:07
320F：→ Argos: 你说这风险会比客户跑来闹 威胁要上网黑公司来得小多少 我 04/16 10:08
321F：推 dylan29341: 非常中肯 特地登入上来推 04/16 10:08
322F：→ Argos: 也是笑笑 瞻前也要顾後啊 很多事是一体两面的 04/16 10:08
323F：→ dylan29341: 尤其对新创更是如此 且战且走是很重要的概念 04/16 10:09
324F：→ dylan29341: 与其花时间写无懈可击的架构 不如先确定你产品有人用 04/16 10:09
325F：→ dylan29341: 未来对於重构需求增加了 公司有钱有闲有人力再来解决 04/16 10:09
326F：→ dylan29341: 在商言商 投入成本与公司获利要取得最佳解 04/16 10:10
327F：→ Argos: 也是啦 如果今天该公司新创半年 使用者不到万人 出事也不会 04/16 10:10
328F：→ dylan29341: 有时候是不得已的 04/16 10:10
329F：推 Masakiad: clarkman 有没有时间重构这不是问题，以本篇案例来说是 04/16 10:10
330F：→ Masakiad: 没打算重构，只打算workaround 方式走一辈子 04/16 10:10
331F：→ Argos: 有太大的损害 至少老板不会因此被判刑 那的确随便即可罗 04/16 10:10
332F：→ Argos: 所以讨论这个 还是要看时空背景各个条件阿 不然就打高空阿 04/16 10:11
333F：嘘 Masakiad: 说到底对程式码品质有要求的团队都会找时间插下去重构， 04/16 10:20
334F：→ Masakiad: 先不管本篇难度太低的问题，该案例可以发现系统架构弹 04/16 10:20
335F：→ Masakiad: 性不足，这根本就是排入重构时程的好时机。你可以当下 04/16 10:20
336F：→ Masakiad: 不重构然後开发处理例外事件的模组，但技术部门应该排 04/16 10:20
337F：→ Masakiad: 时间治标（系统架构弹性不足）才对。 04/16 10:20
338F：→ Masakiad: 正常team: workaround => refactoring (维持原有功能但 04/16 10:23
339F：→ Masakiad: 让架构有可扩充空间）=> 将workaround 的逻辑转成模组 04/16 10:24
340F：→ Masakiad: 挂进去 04/16 10:24
341F：→ Masakiad: 本篇：workaround => 再发生 workaround2 => 得到还好没 04/16 10:25
342F：→ Masakiad: 花时间重构的结论 04/16 10:25
343F：嘘 SmallpTsai: 反正A大有一百万的理由告诉你重构无法面对客户的下一 04/16 10:39
344F：→ SmallpTsai: 个无理要求 04/16 10:39
345F：推 abc0922001: 因为5%的例外情况，放弃95%XDD 04/16 10:53
346F：推 BignoZe: 因为商业需求需要dirty code的情况很常见 但是当情况一再 04/16 12:50
347F：→ BignoZe: 重复就可以重构成好管理的架构了 原po就是没能力改又爱抱 04/16 12:50
348F：→ BignoZe: 怨 04/16 12:51
349F：→ lovdkkkk: 论他其实在收集工作时用的嘴炮材料的可能性 04/16 14:15
350F：→ lovdkkkk: 一堆人免费提供各种看法/意见, 在公司遇到类似议题就可 04/16 14:16
351F：→ lovdkkkk: 以轻松的藉花献佛, 潮爽der科科 04/16 14:17
352F：→ Argos: 大概英文不好？这种讨论随便google就一堆耶 XD 04/16 14:30
353F：→ Argos: 本篇吵过的所有论点 欧美论檀那边早己吵过几百遍了吧 XD 04/16 14:32
356F：→ Argos: 要收集这些 国外那些文章比较精彩啦 04/16 14:39
357F：→ lovdkkkk: 真der, 只是要自己看, 不像这样众人合力帮他重点摘要 XD 04/16 14:46
358F：→ accessdenied: 而且都在地中文化了，读起来很轻松啊。我英文不好也 04/16 15:02
359F：→ accessdenied: 是大家都知道的 04/16 15:02
360F：推 lovdkkkk: 诚实推 XDrz 04/16 15:10
361F：→ vi000246: 能每篇都让推文战翻也算是奇耙了 04/16 16:49
362F：→ accessdenied: 这等成就，Argos网友贡献了一半以上吧 04/16 17:30
363F：推 expup: 我的经验是公司产品上一定会有Clean dirty code 04/16 19:14
364F：→ expup: 这也没有什麽吧 只是有些债要不要还 有的时候根本不用还 04/16 19:16
365F：→ konkonchou: clean code前也要人员具更佳解，很多能力就只到那 04/17 00:02
366F：推 gundamdx: 做的事跟大学刚毕业的菜鸟工程师一样还可以领三百万？是 04/17 00:55
367F：→ gundamdx: 靠爸吗 笑死 04/17 00:55
368F：推 SuperCry: 抛砖引玉，就像模拟联合国、模拟法庭一样，楼主用心良苦 04/17 01:19
369F：→ SuperCry: ，是真正的架构大师 04/17 01:19
370F：推 impotent: 阅 04/17 08:15
371F：→ Argos: 好说好说 偶尔聊聊这个也不错 当然最後还是在个人选择 04/17 09:57
372F：→ Argos: 看你还要待在焦油坑里几年 慢慢沉没 还是有心想要找寻解决 04/17 10:01
373F：→ Argos: 方案 减轻一些痛苦和负担 04/17 10:02
374F：推 penril0326: 公司营运就是这样 clean code讲的只是理想状态 不可能 04/21 18:49
375F：→ penril0326: 完全达到 04/21 18:49
376F：→ m13m13m: cid可以改成一个档案了... 每次load进来if cid in xxx: 05/09 19:18
377F：→ m13m13m: 这样比较不丑一点xd... 05/09 19:18