微信号:programmer_club

介绍:程序员第一自媒体,与你探讨码农人生路上遇到的各类泛技术话题,定期为你推荐码农人生思考、感悟以及启迪!

说说怎么写clean code

2015-07-22 15:37 程序员之家

前两天参加了公司组织的一个培训,主题是“如何写出好的代码” ,刚看到这个主题,第一反应是又不知道是哪个培训机构来忽悠钱的!老大安排了,就去听听呗。

说实在的,课程内容没有什么新鲜的东西,就是讲讲如何发现代码的坏味道,如何重构函数,如何修改遗留系统的代码。这些东西从本科到研究生到实习到正式工作,也不知道看过多少听过多少了,话说本科的课程设计也和代码重构相关,私底下重构和设计模式方面的书也没少看,感觉应该没啥好培训的,不过两天的课程听完,打心眼里觉得来对了,意犹未尽!

课程结束了,感觉需要把这两天课程的内容回顾总结一下,加深一下印象。

关于代码质量。这是一个永远萦绕在程序员心头的问题,特别是在敏捷团队,code quality更是一个时常听到的词语,静态扫描,单元测试,持续集成平台上永远少不了这些东西,感觉有了这些工具,能看到一些报告,就对代码质量有交代了。其实呢,发现实际根本不是那么回事,规则流程有了,工具平台有了,代码质量并没有提高,反而,因为维护UT占了大量的时间,代码写的更随意,更不规范了。培训老师说了一句话挺对的“代码重构是个良心活”,一段代码很烂,不重构能work,重构好了,没人知道,重构出了问题,反而会引来各种抱怨,谁去干这吃力不讨好的事儿,系统中没用的老代码都不想删,何况去动正在运行着的代码呢。所以说,要想提搞代码质量,靠程序员的良心是不太行得通的,特别是交付压力很大的情况下,就是有这个良心也只能昧着良心check in了。那怎么办,要靠manager,只有manager关注这块儿,才真的能触动代码质量的提升,不求manager去review代码,manager哪怕是盯一下静态扫描工具产生的报告,稍微找负责人谈谈话,代码质量就能上去,敏捷搞得manager们只看User Story完成的情况,只看能不能持续交付产品了,选择性忽略了代码质量。当然了,程序员也不是一点责任都没有,程序员写clean code是职业素养,是一种习惯,很多时候,我们从刚开始就没有能够养成这种良好的习惯,现在要改变也很困难,所以程序员要培养编程价值观,要改变对写代码的认识,养成好的习惯。

再说说敏捷开发,这个不知道从什么时候从外企传到私企,从大企业传到初创公司改变传统软件工程的模式,我觉得真心是鸡肋,至少在中国的公司中是不能充分发挥它的价值的。敏捷开发作为一种为迎合当今快速变化的市场的开发模式,面向的是市场,而软件工程是有工程过程规律的,既然是一项工程,就要按部就班的搞,就得有规划,就设计,有实现,有验收,还要有工匠精神,对细节的打磨,一个环节也不能少,不会因为用了敏捷,就能神奇的缩短时间,历史证明,多快好省是不可能的,偷工减料,还能又多又好么!那为啥外国公司要搞敏捷呢,依我看,是因为外国公司和咱国内情况不一样,美国公司啥个情况,就拿我们公司总部,在硅谷,据B1回来的同事说那儿的工作状态:每周最多上四天班,周一下午才来,周五下午不见了,四天里怎么工作呢,上午咖啡下午茶,吃完午饭打个盹,把大部分脏活累活外包到中国印度,自己留着核心的慢慢磨,或者做做创新。这个状态下,敏捷起来确实能提高效率,因为有大把的时间可以挤出来。而国内的,本来就处在满负荷运转了,再搞敏捷,需求不断改,UT,TA各个sprint都要跟上,还有功夫去关注代码质量么?中央为什么要提中国特色,情况不一样,发展阶段不一样,生拉硬套别人的不好使。

扯远了,拉回来。

关于代码的坏味道。什么是好的代码?没人说得清楚,但我们能指出什么是坏的代码,《重构---改善既有代码的设计》这本书开始讲的就是这个,比培训课程里讲得更好更全。只要没有坏味道的代码,就是好的代码,问题是如何闻出代码中的坏味道,有一些量化的规定,比如,函数长度不能超过50行,参数不能超过7个,嵌套不能多于3层,圈复杂度不能大于10,不能出现重复的代码等。有了这些明确的标准,只要会数数,就一定能发现代码中的坏味道。当然了,数学再好也未必就能数的出坏味道,还得有节操。

关于高质量函数。到底为什么要写函数?封装变化,单一职责,隐藏细节,避免重复代码,提高可移植性等,太多理由了,以至于程序员出于本能就会说“这个地方写个函数处理一下”。当然了,本能是一个从刻意到随意的过程,想写出高质量的函数,刚开始也要刻意为之。创建函数三原则:单一抽象层次原则,单一职责原则,函数短小原则。

  1. 单一抽象层次原则:让一个方法中的所有操作处于相同的抽象层。比如描述业务流程的public方法,可以罗列调用几个私有的分步方法,只显示流程大体步骤。这样把程序划分成几个处于同一层次的方法,自然的产生多个包含许多小方法的程序,每个方法只包含少量代码了。

  2. 单一职责原则:函数应该做一件事情,做好这件事,只做这件事。这个原则更多的是针对助手函数,对于描述业务流程的顶层方法,很难做到一函数一件事情。有时候总是喜欢命名一些函数actionAndaction,其实就是懒得去抽开,当然也有为了省掉一个循环,在一个循环里做了两件事情,对于循环,看数据集大小,如果分成两个循环并不会太影响性能,抽成两个函数,代码会更清晰。

  3. 函数短小原则:函数越短,越不会出现嵌套过深,功能复杂等情况。

函数10个一:

  1. 每个变量只用于单一用途。

  2. 每一行代码只表达一件事。

  3. 一个循环只做一件事。

  4. 每个函数语句应该遵守单一抽象层次原则。

  5. 代码组织的一次只做一件事情。

  6. 一种变化导致的修改应该仅仅修改一处。

  7. 圈复杂度小于一十。

  8. 函数第一原则短小。

  9. 单一职责。

  10. 写代码时要有一颗谦卑的心

关于修改系统遗留的代码。这是个头疼的问题,特别是大公司的程序员,很多人刚入职就是从维护老代码开始,原代码的作者早就离职了,有文档的不多,有用的注释也不多,只能靠自己理解,而当需要改代码的时候,就犯愁了,不敢动。很多时候,程序员就会选择往老代码里塞新代码:加个判断,多写个分支,顺着原来的代码结构完成新的功能。可是这很容易把老代码变的更糟,怎么保证不要让老代码变的更糟呢,要对老代码进行隔离,可以采用新生方法,新生类,外包装方法调用老代码,外覆盖类等方式,这些在《修改代码的艺术》里讲得很详细。要时时提醒自己,拒绝软件的退化。

PS:程序员之家可以约稿了!回复约稿试试!

 
程序员之家 更多文章 我们这一代人的困惑 神剪辑,揭秘程序员加班内幕,不能看,看完想笑又想哭! 美国12位创新型程序员:让科技永远改变 8大排序算法图文讲解 你知道你的电脑 1 秒钟能做多少事情吗?
猜您喜欢 游戏编程十年总结 App Store审核条款更新:WWDC 2016重写版本 德国科技又一次震惊了世界,杀个鸡至于么..... 作为iOS程序员,最核心的60%能力有哪些? “万恶” 的 KPI