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

2017/03/25 读书笔记

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

每当写了很多业务代码之后,我都会停下来反思一个问题,你的代码写的干净么,有需要重构的地方么。而这一次,因为一些临时性的需求变更,我自认为我写了一部分脏代码,这部分代码恰恰是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层占的比重很大,有时候疏于测试,好好理解,好好实践,再来写下一篇心得吧。

Search

    Table of Contents