Correct/Changeable/Clean Code 与行为科学 > "I know it when I see it." 「我看到时就会知道」这句话可用在以下情形： 某人在试着去定义一件事，但那件事本身是主观的、没有明确的定义；那个人就可 以说「 (我不知道该如何去定义那件事，但) 我看到时就会知道」。 在 1964 年，美国最高法院大法官 Potter Stewart 在审理一言论自由案件 (某一 电影被州法院认定为「猥亵」 (obscenity, 不受言论自由保护), 案中的艺术电影 院经理上诉到最高法院) 时， Stewart 表示他大概永远无法明确地定义「什麽样 的东西才符合『硬色情』的定义，但「我 (Stewart) 看到时就会知道」。 我对 "dirty code" 有类似的感受；我无法确实定义何谓 dirty code, 但我看到 时就会知道 XD 而因为无法确实定义 dirty code, 我换从 clean code 的角度来 看，抽出两个概念： * Clean Code 无瑕的程式码 * Correct Code 正确的程式码 * Changeable Code 改得动的程式码 我主张「无瑕的程式码是『改得动的正确程式码』通过多重需求变动考验的产品。」 # 「正确的程式码 (correct code) 」第一 正确的程式码带给顾客「顾客想要的价值」。 * 付钱的人才是顾客 * 顾客付钱给你，是为了更接近它的目标 (更好的自己 / 更好的环境) * Job to be Done, JTBD; 顾客为了更接近它的目标所必须完成的工作项目 * 正确的程式码能满足顾客的 JTBD 。 # 「改得动的程式码 (changeable code) 」第二 改得动的程式码让叠代进化是可行的。 * 是否可维护 ( maintainable ): 在改动程式码逻辑後，能否测试既有功能仍正 确运作？ * 是否可重构 ( refactorable ): 在改动程式码架构後，能否测试既有功能仍正 确运作？ * 建构 ( build ) 及 布署 ( deploy ) 能否稳定可靠地重覆执行？ * 能否追踪「谁为了什麽在何时动了什麽 code ; 布署了哪个版本」？ # 「无瑕的程式码 (clean code) 」第三 是否可扩充 ( extensible ) / 满足新需求 ; 是否优雅 ( elegant / graceful / style ) ; 是否好懂 ( easy to understand ) ; 是否效能最佳化 ; 是否符合潮流 ; 是否能规模化 ; 等等。 # 行为科学 以上论述的「 correct 第一、 changeable 第二、 clean 第三」可简化为「先求 有，再求好」，但为什麽後半句的「再求好」在现实中很难做到？ 原因是因为： * 人脑会高估「现状、已拥有的东西」的价值达 2~4 倍。 * 人脑会觉得「利益要是成本的 2~4 倍」才值得做出改变。 也就是为什麽会不时会听到「用 资料夹+日期 做版控，不愿改变」的故事。 ## 那麽，该怎麽办？ 这是个很微妙的问题，它有两个层次： (1) 「人脑抗拒改变」是个行为科学的题目，不是「科技技术」的题目。从行为科 学的角度着手会有效很多。 (2) 这篇文章的读者 ( Soft_Job 版乡民、我的 FB 追踪者 ) 应该有不少是 「习惯了从『科技技术』角度着手解决问题的工程师」，我们能否 *改变* 我们自己从「科技技术」角度着手解决问题的习惯呢？ 这里有两个切入的角度： (a) 提昇大脑对 改变带来的利益 的感受 以 "dirty code" 为例，与其从「 dirty code 的功与过」着手，不如从以下 角度切入： * Correct Code 能让我们拿到今天的薪水 * 学会「导入、实现 Changeable Code 文化」的能力，事实上是在学「行为 科学 / 呼叫人脑 API 」的能力，也就是「影响力 == 销售能力」，能让我 们明天拿到更好的待遇 (b) 降低大脑对 改变需要的成本 的感受 这可以想像成：一样是往上爬升 10 公尺，「爬 100 阶 10 公分的楼梯」会 比「爬一面 10 公尺的墙」简单得多。 这个在这一单篇文章的篇幅中很难做到，因为每个人的「成本」不太一样，大 致上可归纳为以下两种荷尔蒙的影响： * 有些人是以 多巴胺/成就感 为 (主要) 能量来源；过关斩将一点一点进步 ，会带给它的大脑很多奖励。 * 有些人是以 催产素/归属感 为 (主要) 能量来源；跟志同道合的夥伴一起 学习，会带给它的大脑很多奖励。 在这样一篇单向传递讯息的文章中，很难做到。 --- 先写到这里。 欢迎提问、讨论 :) --- 一些参考资料： 英文：行为、心理 * https://hbr.org/2006/06/eager-sellers-and-stony-buyers-understanding-the-psychology-of-new-product-adoption * https://www.hanselman.com/blog/maslows-hierarchy-of-needs-of-software-development * https://dubroy.com/blog/a-hierarchy-of-needs-for-code/ * 中文： Kano 满意度模型： https://www.hansshih.com/post/85896168800/kano --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 136.56.2.86 (美国) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1618438977.A.2D5.html > 不用担心改A坏B 同意；短短八字道尽 软工至高境界 之一 XD 是的，陷在那样的困境中，有想更上一层楼的心，但不得其门而入，是很难受的。 有兴趣的话可以来谈谈你觉得的「好」该是什麽样子，然後一起来找方法把那个 「好」拆成更小的题目，来实现它。 > 合理 这需要把「合理的『理』」的脉络纳入考量，例如说： * 目前有多少粮草？ * 还能撑多久？ * (硬干 "dirty code" ) 做到「正确」要花多少粮草？ * 能得到多少粮草？ * 怎麽样才算「改得动」？ * 例如说，目前产品的复杂度，是需要全套的「 CI + CD + 自动化测试」，还是 「 (有版控的) build / deploy script ; 加上测试步骤列表文件」就可以先 顶得住？ * 做到「改得动」要花多少粮草？ 把这类脉络纳入考量後，会比较容易判断「是否合理」 :) ※ 编辑: AmosYang (136.56.2.86 美国), 04/16/2021 01:16:34 同意；「有人愿意出钱买帐」是最直接的验证价值的方法。 ※ 编辑: AmosYang (136.56.2.86 美国), 04/17/2021 01:15:55