《代码整洁之道》读书小结

最近晚间的加班暂时暂停了，大概已经整整一个月每天焦头烂额的写着业务代码，被各种逻辑搞的整个人都不大好了，好在是写的差不多了。

每当写了很多业务代码之后，我都会停下来反思一个问题，你的代码写的干净么，有需要重构的地方么。而这一次，因为一些临时性的需求变更，我自认为我写了一部分脏代码，这部分代码恰恰是bug的高发地段，而且也可能会带来后期维护的困难。那么如何来重构这部分代码呢？

在我写下这部分脏代码之前，我自认为也是用了一些能够用上的设计模式，但是随着临时性的需求变更不断增加，有时候贪图省事直接在原有代码的基础上修改了事，很明显这违反了开放闭合原则。

回到正题上来，回顾《clean code》这本书，正是帮助自己在反思的同时做好知识的回顾梳理，并且能够在重构中把学到的知识学以致用。虽然现在我还没有全部看完，但是也是可以从已经完成阅读的部分总结一点心得。

第一次看这本书是在几年前，可以说这本书对我编写代码的风格形成了很深的影响，而初读此书时也有种醍醐灌顶的感觉，哦，原来代码还可以这么写。

从命名谈起

当我们在写代码时，面临的第一个问题大概就是命名，你想创建一个类，需要命名；写函数，需要命名；甚至初始化一个变量，也需要给变量命名。但是一个好的命名和差的命名，可是有着天差地别的区别的。好的命名，让人扫一眼，就大概知道这个函数的作用是什么，甚至连大体会输出什么都知道，提升了代码的可读性。而差的命名会极大降低代码的可读性，让下一个阅读你代码的人，花费大量的时间。举个栗子：

privite func syncDataWhenConnect() {
    //doSomething
}

privite func syncData() {
    //doSomething
}

上下两个函数，很明显你看完第一个，会更明白这个函数的目的是什么，所以建议在书写函数的时候，尽量的使用动词，来准确的秒数函数的目的。

而给类命名则正好相反，再举个栗子：

AddressManager.php
MacAddress.php

上下两个类名，这里我写的有点争议，其实在不同的语境里两个似乎都可以完成可读性的使命，但是假设一个程序，有存储用户地址的类，也有外接设备mac地址的类，哪个更易懂？所以类名的命名，尽量使用名词，并且要求简单直接，是什么就是什么，尽量少用动词，动词的活，让我们所在的文件夹，让命名空间们去阐述吧。

虽然我上面反复提及了名字简短，但是只有很少比例的命名能又短又明确的阐述命名意义，所以如果是为了增加可读性，长命名也不是完全不可取，虽然很多人黑Objective-C命名是又臭又长，但是这种命名带来的便利就是你扫一眼便知道函数要完成的目的，以及需要的参数。长短之别，自己把握吧。

从简短代码谈起

编程界的那帮金字塔尖的大牛们一致认为，函数是越短越好，如果实在控制不住，请不要超过20行，如果不小心超过了，那么你可以考虑拆分你的函数了。

其实每次我去反思这点的时候，我觉得可有意思了，讲道理的说，我有可能做不到，为什么呢，因为水平不够，对语言的理解不够透彻，有很多更深层的语言特性，还不能熟练应用。所以只能在能够考虑到的范围内，尽量缩短自己的函数长度，向大牛们看齐。

这次的手环模块，因为有很多蓝牙的连接状态判断，写了很多Swich ifelse等判断，而ifelse因为业务逻辑复杂，还在初次编写的时候夹杂了很多嵌套，所以需要重构的地方还是很多的。

我们写代码，开发时间算20%，那么剩下的80%就是维护时间，什么样的函数易于修改，当然是短的函数，每次改动都能做到心中有数。

而提到了维护，那么测试又不能不提，很可惜，我还没有看全测试，平时的工作中因为很多是移动端的编码，view层占的比重很大，有时候疏于测试，好好理解，好好实践，再来写下一篇心得吧。