在《技术人员如何拥抱变化》一文中阐述了技术人员从多个角度在技术上达到拥抱变化的能力。在《从Simple Design入手代码易修改》中着重讲述了Simple Design中如何做好，让代码具有应对变化的能力。我们现在聚焦代码可读性对应对变化的影响。
在Code Review时，经常有小伙伴提出以下类似问题：
“这段代码方法名起的不好”
“这个变量不明白实际意图”
“某个接口没有按照规范命名”
...
这些都是代码可读性不强时的一些表现。被Challenge的同学要么接受反馈并探索好的实践方式，要么开始为自己辩解开拓。一次Code Review可能很多被可读性问题的讨论把时间占据了。
那要不要关注代码的可读性呢？
实事求是一点的话还要区分场景。
如果是一次性代码，一次写完，这辈子都会回在看的，那怎么写都可以。
如果是团队性代码或者后续经常翻看修改，那么就需要关注可读性。
为什么团队性项目更需要关注代码的可读性？
团队性项目往往是在开发复杂的软件。复杂的软件具有以下特点：
1. 需求不确定；
2. 需求推出者对需要的产品有一个认识的过程。
3. 产品本身也是一个进化的过程。
需求不确定、认识、进化的过程都会发生变化。
而十几年前在敏捷的十二条原则中的第二条就已经描述了如何面对这些变化：
"欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化。"
为了获得竞争优势，需要沟通，控制各种成本。在一番权衡之后，最终决定坚持变化。
变化就真的发生了，作为开发人员如何应对这些变化?
团队中的所有人员都期望能够达到以下的状态：
有了变化，开发人员能够保证质量的同时快速完成。
有了Bug，开发人员能够保证质量的同时快速修复。
但是解决办法绝对不是仅仅意识到要沟通、要协作、加班这么简单。而是要提升开发人员的自身能力。
为了能够实现快速完成和保证质量，首先是善用工具，其次是修改代码。
如果工具或者某种设计思路能够快速完成，最终还是要回到人为修改代码上来。
读代码和写代码的过程时间分配是10:1。人要先读代码，再修改代码。读代码的速度影响了修改的速度。下面是一次实际修改过程。
一次实际修改过程
我们不难想象修改易读代码和可读性差的代码是的状态。下图形象的表达了衡量代码质量的唯一有效标准：WTF/min。
衡量代码质量的唯一有效标准：WTF/min
绕了一大圈，其实就是： 可读性强的代码，在我们做复杂软件开发时更有利于开发人员拥抱变化，抓住商机，实现价值。。
既然修改、添加代码是可读性对我们很有帮助，那么绝对不是修改时才去关注代码结构、类名、方法名、变量名。而是在代码开发的时候就维持好可读性，并作为一种团队开发的常态。
最后，我们再来回顾下Code Review是关于可读性问题的讨论，其实是值得，只有有了这样的过程，团队代码风格才能逐渐统一，修改起来也就更加顺畅。可读性问题被真正解决了，后续Code Review在可读性问题上讨论的时间才会减少。最终，团队才能离真正离拥抱变化更进一步。
最后，怎么让代码具有良好的可读性？
留下一些线索：
技术部分：
IDE特性: [短时间让你扔掉鼠标的Intellij IDEA的插件](https://www.jianshu.com/p/14e9fed878fd)
语言特性
代码结构
Simple Design
设计原则
设计模式
非技术部分：
接受反馈
走出舒适区
刻意练习
有句古老的谚语，能够帮助我们聚焦提升自身技能解决问题：
“愚弄我一次，应感羞愧的是你。再次愚弄我，应感羞愧的是我。”
这也是对待软件设计的态度。
网友评论