老码农:如何写出让自己满意的代码

开发 项目管理
要想写出自己满意的代码,首先不要急于动手,要先仔细想清楚思路性的东西,尤其是数据结构,然后 在实现过程中大胆尝试小心验证,设计好测试用例,确保代码的可读性,就可以在代码中表现出自己的最高水平。但毕竟各人水平是有差异的,自己满意并不等于其他人欣赏。我对此的看法是,不求尽如人意,但求无愧我心,足矣。

今天有位朋友在微博上问我这样一个问题:

“@老码农的自留地 ,最近出于学习目的写一个管理系统,越到后边,越觉得自己前边的代码写得烂。前辈,我想让代码写得更好一点,能不能谈谈你的经验,给我指点一下!”

我在回复里刚写了几句,就意识到140个字很难把我的想法说清楚,本着知无不言言无不尽的好为人师精神,我决定把我的回答写成一篇博文。

[[85645]]

首先要说明的是,我写这篇博客并不代表本人觉得自己的代码写得有多好。事实上我很清楚自己的水平,作为一个做应用系统的程序员,和那些做框架做系统 的大牛根本就不在一个层次。而且即使在应用层次,我的水平大概也只能算二三流,只是因为热爱编程所以一直在努力而已,但不管怎么说,能做自己喜欢的工作我 已经很满足了。所以我稍微篡改了一下问题,针对“觉得自己前边的代码写得烂”这个重点,把这位朋友问的如何“让代码写得更好一点”改成了“如何写出让自己满意的代码”

言归正传,我自己的体会是写代码很像写作文,开始写之前的构思过程是最关键的。记得高中的时候,有位语文老师给我传授的经验是,至少花三分之一的时 间来构思,反复斟酌中心思想、各个段落的大意,文章的脉络,主要的修辞手法,等等。把这些要素都想清楚了,写起来就可以一气呵成。

我觉得写代码也是一样,思路是最关键的。假定采用的技术平台、框架、工具等已经确定了,那么在开始动手写之前,花三分之一以上的开发时间去把所有的 数据结构及其相互关系考虑清楚。例如需要定义几个类,类和类之间的关系是怎样的,每个类里都有什么属性,每个类提供一些什么样的方法,等等,这些是最核心 的。这些数据结构要考虑得尽可能细,比如功能实现可能没问题,但是性能上不理想,这就说明你的数据结构设计还需要改进。这些细节要反复考虑,交叉检验,直 到自己觉得很周到了为止。在此基础上,再注意实现的细节、测试用例、代码可读性,就应该可以写出让自己满意的代码。具体说明如下:

1. 数据结构和核心算法

关于数据结构的重要性,大神Linus Torvalds讲过这样的话,我觉得非常赞同:”Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” (低水平程序员总在考虑代码,高水平程序员总在考虑数据结构及其之间的关系)

数据结构考虑清楚了,核心的算法自然就出来了,这就是关于每个类的每个方法如何实现的问题。比如需要实现一个中位数查询方法,如果你前面确定了数据 保存的格式是一个列表,那么你可以考虑采用插入排序法;如果数据格式是自平衡二叉排序树(AVL),则只需直接返回根节点就可以了。

数据结构决定算法,所以你在考虑数据结构的时候,一定要尽可能地使数据的结构和它的自然属性相匹配,不然后面的实现就会是一场噩梦。比如,你把一个 多层级的结构定义成二维数组,看上去也靠谱,相当于在一个表格里维护一个组织结构图,可是当你做到部门增减的时候,本层级的数组元素移动自不必说,下面各 个层级的元素移动就很容易乱套,而且性能很差,可能你写了2000行代码还有很多边界条件会出错。相反,如果用一个孩子兄弟链表来表示这个树型结构,操作 起来就非常容易,可能100行都足够了。

2. 功能实现

思路确定后,实现过程也需要大量的构思活动。碰到你比较熟悉有经验的领域,你自然可以轻车熟路,但难免会有一些你不太熟悉的技术需要尝试。有的同学 比较排斥这种领域,比如我好不容易才掌握了Struts 2,领导又让我去学习Grails框架,我就会觉得很不爽,大概看了看就挑出它的一堆问题,然后能躲多远就躲多远。可是我要说,这样的心态会阻碍自己不断 提高技术水平。作为一个程序员,最大的挑战也是最大的乐趣所在,就是不断学习新的技术,没有这样的心态,很快就会落后。

好,那么遇到不熟悉的技术怎么办?我的体会是,先不要急着实现项目中的代码,自己另外维护一个测试项目,在里边边查文档边学习,边做一个小功能,把 所有需要在项目中实现的功能先在测试项目里跑通,然后再写项目里的代码。这样做的好处是把单个技术问题和其他潜在的bug隔离开来,便于快速学习新技术。 否则,你直接在项目里写代码出错以后,要判断问题的源头都要多费好几倍的精力。

3. 测试

测试很重要,设计测试用例就像开发时设计数据结构一样,也是很关键的。在设计测试用例的时候,要把当时自己设计数据结构的思路全部忘掉,或者找别人 来设计测试用例,不然会不由自主地测试那些你已经考虑到了的地方。这样测试是跑通了,用户一用起来可能各种边界条件会到处出问题。

有人会推崇TDD的方法,先设计好测试用例,然后在开发过程中确保所有测试通过。我个人不喜欢这种方法,虽然承认从开发质量管理和长期维护的角度来 说TDD是很有必要的,但我个人尝试的结果是,设计完测试用例后,想到开发的目标不是实现功能,而是为了跑通测试,就感到毫无乐趣可言。这一点我自己也觉 得很矛盾。

写到这里我又想到大神Linus说过的另一句话:”Regression testing” What’s that If it compiles, it is good; if it boots up, it is perfect. (“回归测试”?这是什么东西?如果代码能编译就是好的,如果它启动了,那就是完美的。)

当然了,大神水平摆在那里,他有资本目空一切,咱确实没资格仿效。但是我还是觉得TDD也有TDD的问题,测试是很重要,但把它摆到驱动开发的高度,就有点本末倒置了。这个是我自己的一点看法,本人对TDD了解得不深入,如果有谬误之处,请多多指教。

4. 代码可读性

要想自己满意,代码的可读性一定要好。要做到一年后甚至几年后你拿到自己写的代码,还能很容易看明白当时的思路和实现。这就涉及到命名和注释的问题。

命名就像超市里的商品标签一样,要让看得人一目了然就知道这是个什么东西,比如你的员工类里有两个属性分别是到岗日期和离职日期,把它们定义成date1和date2就没有多少可读性,而定义成dateOnBoard和dateQuit就比较清晰。

注释也是很重要的,它可以用来说明一段代码的作用,算法的设计思想,或者是方法调用的参数格式要求等。有人觉得命名就是注释,代码本身就为自己代言 了。我觉得这种说法用来强调命名规范的重要性是很好的,但是因此说不需要注释则有失偏颇。试想,如果Dijkstra首次发明最短路径算法的时候,他给出 的代码里没有一行注释,即使所有的变量命名都定义得准确而严谨,又有几个人能看懂他的算法呢?所以,在重要或者复杂的地方,都需要详细地写一些注释,便于 看代码的人清晰地了解你的思路。

最后总结一下:要想写出自己满意的代码,首先不要急于动手,要先仔细想清楚思路性的东西,尤其是数据结构,然后 在实现过程中大胆尝试小心验证,设计好测试用例,确保代码的可读性,就可以在代码中表现出自己的最高水平。但毕竟各人水平是有差异的,自己满意并不等于其他人欣赏。我对此的看法是,不求尽如人意,但求无愧我心,足矣。最后再啰嗦一句,技术水平是可以慢慢提高的,但是好的编程习惯需要从一开始就养成,它会让 你在前进的道路上事半功倍,受益终生。

责任编辑:陈四芳 来源: 博乐在线
相关推荐

2022-02-08 19:33:13

技巧代码格式

2015-09-28 10:49:59

代码程序员

2019-06-24 10:26:15

代码程序注释

2020-10-18 07:21:34

CPU代码执行效率

2020-07-15 08:17:16

代码

2013-06-07 14:00:23

代码维护

2020-05-11 15:23:58

CQRS代码命令

2021-09-01 08:55:20

JavaScript代码开发

2021-11-30 10:20:24

JavaScript代码前端

2023-07-16 22:34:55

2020-09-30 11:14:24

AI码农架构

2015-05-12 10:15:15

程序员

2022-02-17 10:05:21

CSS代码前端

2021-01-04 07:57:07

C++工具代码

2020-05-19 15:00:26

Bug代码语言

2019-09-20 15:47:24

代码JavaScript副作用

2020-12-19 10:45:08

Python代码开发

2022-03-11 12:14:43

CSS代码前端

2022-10-24 08:10:21

SQL代码业务

2018-10-17 22:01:06

点赞
收藏

51CTO技术栈公众号