今天有位朋友在微博上问我这样一个问题： “@老码农的自留地 ，最近出于学习目的写一个管理系统，越到后边，越觉得自己前边的代码写得烂。前辈，我想让代码写得更好一点，能不能谈谈你的经验，给我指点一下！” 我在回复里刚写了几句，就意识到140个字很难把我的想法说清楚，本着知无不言言无不尽的好为人师精神，我决定把我的回答写成一篇博文。 首先要说明的是，我写这篇博客并不代表本人觉得自己的代码写得有多好。事实上我很清楚自己的水平，作为一个做应用系统的程序员，和那些做框架做系统 的大牛根本就不在一个层次。而且即使在应用层次，我的水平大概也只能算二三流，只是因为热爱编程所以一直在努力而已，但不管怎么说，能做自己喜欢的工作我 已经很满足了。所以我稍微篡改了一下问题，针对“觉得自己前边的代码写得烂”这个重点，把这位朋友问的如何“让代码写得更好一点”改成了“如何写出让自己 满意的代码”。 言归正传，我自己的体会是写代码很像写作文，开始写之前的构思过程是最关键的。记得高中的时候，有位语文老师给我传授的经验是，至少花三分之一的时 间来构思，反复斟酌中心思想、各个段落的大意，文章的脉络，主要的修辞手法，等等。把这些要素都想清楚了，写起来就可以一气呵成。 我觉得写代码也是一样，思路是最关键的。假定采用的技术平台、框架、工具等已经确定了，那么在开始动手写之前，花三分之一以上的开发时间去把所有的 数据结构及其相互关系考虑清楚。例如需要定义几个类，类和类之间的关系是怎样的，每个类里都有什么属性，每个类提供一些什么样的方法，等等，这些是最核心 的。这些数据结构要考虑得尽可能细，比如功能实现可能没问题，但是性能上不理想，这就说明你的数据结构设计还需要改进。这些细节要反复考虑，交叉检验，直 到自己觉得很周到了为止。在此基础上，再注意实现的细节、测试用例、代码可读性，就应该可以写出让自己满意的代码。具体说明如下：
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隔离开来，便于快速学习新技术。 否则，你直接在项目里写代码出错以后，要判断问题的源头都要多费好几倍的精力。
|
