推 yangs0618: 推个 希望有机会听到进一步分享how10/28 07:58
→ yangs0618: On提出数据说服主管/管理层 开发是越来越耗时间10/28 07:59
→ panbanana: 要怎么跟上头说开发越来越久跟code quality有关10/28 08:18
几个很简单的学术名词就能说明，我相信大家也知道
耦合性 如果我改A模组，B模组就需要跟着改 (这还是B模组没有牵连其他模组的情况下)
经验法则告诉我们 改的模组越多，消耗的时间也越多
所以时间成本增加
正交性 如果一个错误设计的函数其副作用会影响到非预期的变量或状态(非正交)
非正交的设计会导致bug甚至影响业务的正确性
生活化的例子：“如果你今天开热水器，结果旁边的维波炉也开了”
不会抓狂吗？
所以时间成本增加(你要再请工程师花时间解bug甚至赔偿客户)
粒度 你是希望有一千个功能相似又微妙差异的工具，每次要选择都要重新翻箱倒柜
还是你是希望有十个零件可以组出一千种功能？
不一定有对错，但从新人教育程度跟熟悉的速度，
认识十个零件肯定是比一千个工具之间的细微差异还简单
粒度低可以降低时间成本
这些都是理论，我相信对没有技术背景的人来说也不难懂
那数据呢？统计呢？
从ticket、commit的内容我们可以发现，一定是有某些模组、某些类别、某些函数经常
被更改，而这些程式码才是最有价值的地方，因此程式码的重要性、频率是可以从执行
纪录、commit等资讯来加以量化的
如果某个模组特别容易出bug，很有可能是其模组本身或是其使用的模组有问题
这时你才有机会说服管理阶层建立测试及其重要性
管理阶层重视的不是工程师写程式舒不舒服，而是用户有没有受影响？能不能减少公司
的执行成本？
测试可以尽量避免工程师改坏功能，而只有保证不改坏程式码，工程师才有可能说服
管理阶层允许大幅改写原始的程式码
而如何证明code quality跟test可以降低执行成本？这需要有证明的材料，如果某个
模组的code quality很高，而该模组相关的开发与维护速度都比其他模组来得有效率，
那也许可以透过比较间接证明此观点 (但有些政治因素比较重的办公室，我不推荐你
去比较)
如果现在没有"你认为"品质好的程式码，你就只能不断透过能力证明而且去创造
你要说服管理阶层，只能从管理阶层重视的价值着手
最后做个总结：
遇到code quality差的公司建议直接跳槽