我对clean code的理解

本文谈论的clean code要求并不高(常规水平)，我觉得对于日常开发来说能达到:

• 变量命名清晰简洁、
• 函数功能较为单一，逻辑清晰，能复用的情况下做到不同函数职责设计合理
• 简单场景能简单用到常用设计模式
• ...

以上这些能做到,写出的代码就已经算得上是中上水平了(不要求用一些高阶方法或者什么巧妙方法，甚至没有完整看过代码整洁之道或者重构这种书籍也可以,能正常写整洁代码就可以了),对此有的公司可能要求会更高。

类似于写字，不要求每个人都能写出非常漂亮的字，至少看起来要工整这个要求并不过分。

说来也奇怪，在我看来，clean code应该是编写程序时自然附带的一个要求，不然在阅读自己的程序或者需要修改新增功能的时候总是会感觉困难重重。不过在我从学校到工作的过程中，尤其是在学校，大家可能会知道有代码整洁之道或者重构这种书籍，但是大家往往会把他当作一种额外技能来看待，是属于更高层次的要求，能注意到并且真正学习的同学总是在少数。

以我自己为例，我在学校也只是知道有类似的图书，简单翻看过，但是并没有认真阅读过，平时写代码也是比较随意，像是leetcode这种算法题流程稍微端点的还好，阅读起来不是也别困难，加上些许注释就行了。但是对于论文算法的编写，基本都是瀑布式的外观，因此每一个模型都是一个文件，代码重复率很高(当然还有其他设计也不合理,真要抽函数也没法实现复用,只能优化单个文件结构)。

进入公司后，也是过一段时间公司可信的浪潮才波及我们部门，然后逐渐开始完善了commiter机制(变了好几次)，流水线设置CodeCheck,然后也收到了很多同事对于我的代码的修改建议。这些经历使得我逐渐开始重视自己写的的代码是否符合规范，我觉得整洁的代码也确实能够更简单的阅读理解并且扩展修改功能，总体上当然是利于日常开发设计的。

不过对于企业来说，投入可信的确是一件需要花费不少成本的事，这一点我在企业以及部门里也是有所体会。首先重构代码就是一件短期内只有投入没有回报的事(有可能投入还很高)，与其重构某个模块的代码，倒不如开发或者优化一个功能带来的收益高，产品经理或者部门领导在和客户沟通时会更乐于和客户说我们新增了什么功能，而不是我们代码很整洁(或者重构的更合理了)。因此在部门里虽然会有鼓励重构代码的倡议，除非是有代码扫描的硬性指标，其余都是鼓励在工作之余完成的，之前部门颁发的项目奖，设计模块重构的基本都是某某同事用工作之余完成的，而绩效考核也会更优先考虑新做的需求而不是代码重构(除非重构规模大并且难度高)。

对于我们公司来说，最近做可信确实也投入了很大的成本(尤其是ICSL安全送检)，据说其起因是以前有外部客户吐槽代码写的烂(当然只主因不是这个)，并且公司也想要打造安全可信的形象以吸引外部客户。之前公司里讨论热烈的一个帖子就有同事质疑：公司成功的项目里有哪个项目是因为可信而成功的？暂且不追究这个同事在公司的职位是哪个分工，这个发言倒是非常现实(公司反对的声音还挺大的，主要是流程重，卡指标，一刀切，部门需要投入巨大的成本短期内解决过去产生的所有的历史问题)。。。烂代码和好代码如果能实现同样的功能，那么重构无疑增加了不少成本。

在我看来，所谓的成本大概分为两类：一类是以前的代码，重构优化需要投入很多成本，属于历史债务的偿还；另一类则是设置门禁检查以及commiter机制，对当下以及未来的代码做审核，这个属于长远投资，这两种都是必要的。如一开始所讲，我觉得整洁本身就是写代码所应附带的一个属性，尤其是对于公司的开发人员来说，更应是基本技能，只不过之前没有特别重视，并且烂代码也确实会对业务的开发以及演进造成阻碍。总体上倡导可信是一件好事，并且没有什么代码是一写出来就真正的clean的，随着时间推移，代码腐化很正常，到了一定程度就需要重构，这属于正常的演进。只是公司出于成本来说比较排斥这件事，有时候即使不得不做也会把压力给到开发人员(比如之前讲的要求在工作之余进行)。

不过对于一个自然流程来说，只想要获取收益，却不想承担损失，是一个需要纠正的问题。