Clean Codo 如何写整洁的代码（一）

Clean Code

顾名思义 就是整洁的代码。或者说清晰、漂亮的代码。如果是写代码的不论前端 后端都希望能写出人模人样的代码。
这个话题就和哈姆雷特一样 每个人看法不一。
这里主要针对自己这几年来的经验来展开。

代码大部分是用来维护的，而不是实现功能

怎么理解这句话。代码大部分是用来维护的，而不是实现功能

• 写功能只占整个生命周期的很短的时间 大部分时间都是在维护代码。

这个原则适用于大部分的工程。我们的代码 一方面是编译好让机器执行。完成功能。另外一方面 写给边上的同事或者后来者看的。要长期维护的。大部分项目应该都不是短命鬼吧 (好像虽然也不一定)
大部分情况下 如果不能写出清晰好看的代码，可能自己一时爽快。后续的维护付出的代价和成本 远远高于你的想象。
所以首要目标。是写的清晰

优秀的代码大部分是可以自描述，好于文档和注释

开源项目里面的代码 注释很少。但是你读起来就很爽。读完源码了 基本他的功能设计就清晰明了。认真命名和清晰的流程控制，代码本身就可以当作文档使用。

相反注释并不能让写得烂的代码变得更好。如果别人只能依靠注释读懂你的代码。一定要反思代码哪里有问题。 不是让你们不要写注释奥！！！！

比较适合写注释的场景:1 public interface 给别人明确发布你功能语义。输入输出 并且不需要关注impl。2 功能容易有歧义的点，或者涉及比较深层专业知识的。比如写了一个 client 各种config的参数意义。

设计模式只是手段 代码清晰才是目的

之前自己犯过的错误 和现在碰到的同事的问题。
各种抽象 各种工厂、继承。想找到个实现山路十八弯。一个功能里面大部分类是抽象类或者接口，找不到一两句实现的代码。整个读起来不顺畅。他的想法:保留合适的拓展点 克服掉所有的硬编码。

我有时候看来，也许他的代码过度设计了。因为实现没那么多。然后在同一个公司 大家的水平参差不齐。无论你用了怎么高大上的设计，如果大多数人都很难理解或者读起来很费劲。很有可能是一个失败的设计。

Code review

公司嘛 很多情况下都会用PR来做CR。应该重点关注什么？代码的格式。业务逻辑 代码风格？其实除了基本功能需要的逻辑合理没有bug外，我们更应该关注代码的设计和风格。比如 一段方法是不是应该属于一个类，是不是有很多相似的功能可以抽离出来公用。 代码是否过于冗长难懂等。

集体CR算是比较推荐的方式。很多时候 团队内部比较高的开发者能比较容易的发现代码存在的较大设计缺陷。提出改进意见或者重构方式。

勤于重构

好的代码一般都不是一蹴而就的。即使一开始设计的代码很优秀 也有可能随着业务的快速迭代。被改的面目全非。

为了避免重构带来的负面影响(delay 需求或者带来的bug).需要做到

• 掌握常见的无痛重构技巧
• 小步快跑 改一点测一点 一方面减少merge的痛苦。一方面减少上线风险
• 建立TDD 做好单元测试 即使改坏了也保证功能可用 保证自己修改的部分被覆盖
• 掌握IDE自动重构。