《CleanCode》实践感悟（上）

距离首次阅读《Clean Code》已有两年时间。在这段时间里，我努力确保我的日常工作符合“Clean Code”的标准。我自己实践了书中的内容，从变量和函数的命名，到函数嵌套和调用方式，以及代码段之间的格式和注释。尽管我在测试和工程化方面的实践较少，但是在代码的编写上面“CleanCode”已经帮了我很多忙，让我更轻松的阅读自己的代码，提高工作的效率。

《CleanCode》这本书就是教你如何编写易于阅读的代码。

在工作中，编写一次的代码可能会被阅读10次、100次。易于阅读的代码真的很重要，因为大部分时间我花在阅读自己或他人编写的代码上，而不是写代码。代码格式、注释、长度，甚至一个换行都有可能影响你的阅读效果，从而影响你的工作效率。

命名篇

在工作中，经常会遇到像list、object、one这样的命名。说实话，如果在短的函数中还是能看懂的，但是这种命名一旦放在很长的一个函数中真的非常影响工作效率。例如：list1、list2、list3，这样的命名写着写着你都不知道哪个list是你想要的，即便是拼音都比这种命名要好，见名知意的命名真的非常棒！

我关注了一下这种命名，通常是使用IDEA快捷键根据方法名称等信息自动补全的，使用一些框架的list()，getOne()，这种方法IDEA自动创建的对象就是list，one，有的人懒得改也就一直用了。但是随着项目的维护，代码中出现了越来越多的list，为了方便就list1234随便的写下去了。

如果时间真的很紧这样写也无可厚非，但是这给后续的维护带来了相当大的阻力。公司如果没有一个好的规范，或者严格的代码审查，真的也没啥办法，毕竟确实不建议随便改别人的代码……

函数篇

函数的长度

你见过最长的方法有多少行呢？说实话20行我就有点接受不了了，如果是工具类方法还好，一般不会去改动，但如果是业务代码真的很让人头疼，如果再结合上list这样的命名+没有注释，debuff叠满，这样的代码维护起来真的想骂人。CleanCode建议使用短小的函数，我在实际编写的过程中也体会到了这样做的好处。

用一个个短小的函数去封装你的代码逻辑，最后把他们组合起来，这样在后续的维护中你不需要在你的大脑内存中存放篇幅过长的代码上下文，只需关注要变动的局部代码，并且短小的函数更利于代码的复用。我认为这真的非常重要！在实际工作中，有一个项目被我陆陆续续的维护了一年多，在“Service for Customer”的规则下能继续让人轻松的维护全靠短小的函数。

函数命名

诗一样优美的代码基本没有，shi一样的代码倒是很多，虽然看自己之前写的代码也会觉得像shi一样。

写诗确实不行，但在我眼里优秀的函数就是用短小的函数 + 见名知意的方法名组合成的一张说明书，比如“获取学生ID，找到学生选修的课，求出学生的平均成绩”能用英语写成这样我觉得已经非常棒的一个函数了，如果我看见我的嘴角会压不住的。

可能刚开始还能写这样的“说明书”，但是随着后续的维护可能你可能无法得知得知产品的一些细节，这就增加了维护“说明书”的成本，甚至导致你无法用“说明书”表述完整这段功能，最后只能是补丁套补丁。

注释篇

最大的误区就是给所有函数都加注释，我们用优秀的命名规则写出来的代码已经是一张“说明书”，这时候就不需要过多的解释了。注释这东西写得好帮助你理解代码，写的烂会误导你，降低你的阅读速度，影响你的开发效率，而且在维护代码时没有几个人去维护注释。

今天给A同学代码写个注释 //计算学生平均成绩 此时代码只有5行， 2个月后B同学把这段代码逻辑改成“计算学生必修课的平均成绩”，代码现在是10行，但是没改注释，4个月后C同学需要用到这段代码，第一时间会以为它是//计算学生平均成绩 如果不仔细看并按照注释去使用了，自测的时候发现，哎算出来的值符合逻辑，ok没问题。结果可想而知，测试提BUG，C同学改BUG，断点调试煎饼果子来一套，最后得出结论这个注释是乱写的。当然这只是一个例子，垃圾注释带来的问题实际上比这更多。