我眼里的代码质量和重构

By HW-LF

CleanCode这个概念第一次闯入我的认知还是之前bob大叔的那本书，后来在公司从UK安全事件逐步到可信变革的大潮中，cleancode这个概念越来越热，逐渐变成了软件变革部分的核心。我也在年初被卷入了变革组里，负责在产品线内对CleanCode进行解读和帮助各产品落地，并在总体组内负责软件重构部分的解读。

CleanCode到底意味着哪些要素，众说纷纭，四五月份产品线组织研讨的时候，我抛出了一个模型，大家认可度还可以。后来这个材料逐渐扩散开，我已经在两三个不同场合不同的材料中看到，但是解读各不相同。所以还是把我的理解发出来，供大家参考。

这个图里的几个台阶，并不是时间上的先后，更多是从代码质量的范围和对团队能力的要求高低上来分了几个level，这些level也不存在进阶的概念，比如代码整洁不代表漏洞风险就可控了，架构做好了也不代表代码细节就做到了整洁。这里的分级更多代表产品团队和个人能力的分级。图的左边是公司可信变革的核心思想：已知问题不重犯+新问题有效应对+可持续的角度来看，对应是什么样的代码和软件。

作为一个软件团队，满足需求完成功能开发，这是基本门槛。在功能可用后，客户所希望的就是没有漏洞风险。无漏洞风险不代表完全没有漏洞，而是已经消除所有的已知漏洞，并且有确定性的漏洞管理机制来确保风险可控。代码整洁则是从团队内部的角度出发，通过规则约束减少犯错出问题的概率，同时带来员工成长、问题定位效率等收益，外在的表现是质量属性和维护效率的提高。架构要优雅，指的是我们的代码在可以预见的一定时间内，面对新的需求可以巧妙地快速交付，面对新的问题可以优雅地解决或规避。可以说，代码的价值更多体现在当下，架构的价值更多聚焦在未来。但人不可能预知一切，当业务的发展，需求和问题的变化越来越大时，一个产品是否具备持续新陈代谢，不断进化的能力才是保持竞争力的关键

目前正在进一步提炼和思考的，是每个台阶上的描述。这部分是希望从每个级别的对应外在价值上来给出一些表征。因为软件的内在质量与实际业务是强相关的，控制面产品的插件式架构是个good idea,但是在高性能的转发面可能就是瓶颈，所以不存在一个统一的评估和表述模型，只能给出一些参考性的内容。但是所有的这些内在属性，最终都要体现外在的价值，归结到产品的质量与效率上来。比如代码整洁带来的效果就是新员工学习上手快，问题定位快，等等。如果能提炼出这些表征，那么一方面软件人员可以用来参考去说服不懂代码的商业主管来投资，另一方面也避免在对外交流的时候，只能讲重构减少了代码量这样的低价值收益。所以这方面如果哪位有什么想法和建议，欢迎随时找我讨论！