代码要写三遍

代码要写三遍

• 第一遍，捕获需求

• 第二遍，优化设计

• 第三遍，调优性能

“捕获”需求而不是“实现”需求

因为“实现”需求，假设的是需求都是确定的，但现实是，需求往往是在落地过程中得到反馈逐步确定的。而“捕获”需求，从一开始就接受需求是不确定的，往往在实现落地过程中会有细节变化。“捕获”需求要求工程师要从技术可行性，逻辑完备性，变更风险控制角度来审视需求，发现和确认遗漏捕获的细节。写技术方案应该被看作一种捕获需求的工具。同时要求工程师采用一种最小化反馈周期的做事方式。一个采用这种做事哲学的工程师，他懂得用最小可交付粒度来切割它的工作，如果是一个后端工程师，那么他应该按前端接口的粒度去交付，尽快获得来自前端和测试的反馈。而不是所有工作堆积到临近deadline才一起交付，然后面对一大波返工。

捕获需求阶段不过度考虑优化设计

这里讲的优化设计是指不改变功能前提下，提升代码可读性，降低程序员认知负担，使得后续维护和扩展更方便。捕获需求阶段不过度考虑优化设计。因为第一，不确定的需求，不提前做优化设计。第二，即使是比较确定的需求，如果后续修改可能性比较小也没必要过度优化设计。我的经验是，如果代码不是很难理解，可以容忍他上生产环境，接受一波来自用户的检验后，再思考如何优化设计。

设计糟糕的代码会让你的同事难受

一个团队一起工作，一些基本的设计原则要遵守的，一个团队最好要使用同一种框架来做事，因为每个人都不可能维持一年365天24小时可用，分分钟都有可能要求别的同事去改你的代码，如果你的代码让人很难读懂，那么他只能在你休假的时候打电话去打扰你了，这样大家都不好过。所以代码上线后，也不要忘了持续优化设计。

可读性 > 性能

长期来看，几乎所有的代码都是要改的。容易被读懂的代码更容易被修改而得到性能优化。性能优化要如果没有数量级的变化就不知道为它牺牲可读性。因为硬件性能一直以摩尔定律的速度提升，所有的软件不做任何改变都能从硬件升级中获得红利。

测试防护网是一切的基本

既然代码注定要被多次修改，那么如何保证不破坏原有功能呢？答案只有一个：自动化测试。我们常说为了短期快速完成而走的临时方案是技术负债，长期来看，几乎所有的代码在刚刚诞生的那一刻都是负债。那么有没有什么代码在他诞生的一刻就是资产呢？如果有，我觉得就是自动化测试。只要代码后续还需要改，自动化测试就是保障我们不改出毛病的保障。设计良好的自动化测试，无疑会占据我们的开发时间，但它能保证我们的进步都是可叠加的。结硬寨，打呆仗。这是我喜欢的做事哲学。