代码简洁性：高效工程生产力的关键
作者：Max Kanat-Alexander
发布日期：2017年4月4日
工程生产力工作者常陷入两种困境：要么与试图帮助的开发团队发生冲突，要么花费大量时间开发无人关心的项目。问题的根源在于，你看到的开发团队问题未必是他们意识到的痛点。
例如，你可能发现团队代码复杂到无法编写良好测试或轻松维护系统，但开发者真正感受到的可能是“每月只能发布一次，且全队需加班至晚上10点才能完成发布”。
错误做法及其后果
部分工程生产力工作者会选择忽略开发者反馈，直接开始重构代码。这种做法往往失败，原因包括：
- 管理层和其他开发者会产生抵触情绪
- 即使做出卓越工作，也会被视为与公司实际需求脱节
- 最终导致个人信誉丧失甚至职位不保
长期如此，许多工程生产力工作者会对开发者产生对抗心态，认为“只要使用我开发的工具就能解决问题”。但若开发者不使用你的工具，这些工具又有何价值？
正确解决方案
第一步：发现真实问题
不要做任何预设判断。与直接参与代码工作的多人交流，而不仅仅是管理者或高管。关键技巧包括：
- 避免直接询问“哪些部分太复杂”
- 询问情感反应：“工作中哪些部分让你感到烦恼？”、“是否有总是令人沮丧的代码？”、“是否有不敢触碰的代码区域？”
第二步：建立个人信誉
从收集的数据中，选择一个开发者已知、且你能在短期内（1-2个月）解决的问题并提供解决方案。关键原则：
- 解决方案不需要改变所有人的工作方式
- 最好选择他人尝试过但失败的问题，以此证明问题是可以解决的
第三步：渐进式改进
建立基本信誉后，开始解决开发者问题并实施你认为的最佳解决方案。重要原则：
- 不能一次性改变团队文化或开发流程
- 必须逐步实施，处理变更带来的“后果”
- 团队规模越大，推进速度需要越慢
处理阻力情况
当遇到资深成员的阻力时：
- 寻找盟友并建立核心支持小组
- 公开鼓励任何想要改进的意愿
- 如果9/10的人都想做正确的事，可以忽略那个大声反对的人
如果被完全阻止，可能是：
- 你的方法有问题（未遵循上述建议、沟通困难等）
- 阻止者确实不合理
在后者情况下，如果即使有支持者也无法取得进展，可能需要考虑更换团队。
文化转变的关键
通过渐进步骤提高生产力后，需要确保这些步骤朝着根本问题前进。最终需要改变人们编写软件的方式：
- 在适当时候提出重构：“重构这部分代码可以更轻松地实现X功能”
- 持续提出重构建议，同时继续工具、测试和流程方面的工作
- 重构坚持度对文化改变影响最大
当形成“工作时总会清理代码”或“代码质量很重要”的文化后，问题往往会自行解决，即使你不再主动参与。
核心原则
整个过程不是关于“建立共识”，而是：
- 发现人们知道存在的问题
- 提供他们能接受的解决方案
- 逐步解决代码库的真正根本问题
最重要的原则：解决人们知道自己有的问题，而不是你认为他们有的问题。
适用范围
虽然本文以负责整个公司或团队工程生产力为前提，但同样适用于工具、框架或子团队等较小范围。关键仍然是解决真实存在的问题，而不是你认为开发者应该有的问题。
许多工程生产力团队违反这一原则，花费数年开发开发者不需要、从不使用、甚至在其设计者离开后努力删除的工具和框架。这是多么无谓的时间浪费！
不要浪费你的时间。要高效。改变世界。