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

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

　　“@老码农的自留地 ，最近出于学习目的写一个治理系统，越到后边，越以为自己前边的代码写得烂。先辈，我想让代码写得更好一点，能不能谈谈你的履历，给我指点一下！”

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

　　首先要说明的是，我写这篇博客并不代表本人以为自己的代码写得有多好。事实上我很清晰自己的水平，作为一个做应用系统的程序员，和那些做框架做系统的大牛基础就不在一个条理。而且纵然在应用条理，我的水平或许也只能算二三流，只是由于热爱编程以是一直在起劲而已，但不管怎么说，能做自己喜欢的事情我已经很知足了。以是我稍微窜改了一下问题，针对“以为自己前边的代码写得烂”这个重点，把这位朋侪问的怎样“让代码写得更好一点”改成了“怎样写出让自己满足的代码”。

　　言归正传，我自己的体会是写代码很像写作文，最先写之前的构想历程是最要害的。记得高中的时间，有位语文先生给我教授的履历是，至少花三分之一的时间来构想，重复斟酌中央头脑、各个段落的大意，文章的脉络，主要的修辞手法，等等。把这些要素都想清晰了，写起来就可以一气呵成。

　　我以为写代码也是一样，思绪是最要害的。假定接纳的手艺平台、框架、工具等已经确定了，那么在最先下手写之前，花三分之一以上的开发时间去把所有的数据结构及其相互关系思量清晰。例如需要界说几个类，类和类之间的关系是怎样的，每个类里都有什么属性，每个类提供一些什么样的要领，等等，这些是最焦点的。这些数据结构要思量得尽可能细，好比功效实现可能没问题，可是性能上不理想，这就说明你的数据结构设计还需要革新。这些细节要重复思量，交织磨练，直到自己以为很周密了为止。在此基础上，再注重实现的细节、测试用例、代码可读性，就应该可以写出让自己满足的代码。详细说明如下：

　　关于数据结构的主要性，大神Linus Torvalds讲过这样的话，我以为很是赞许：”Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” （低水平程序员总在思量代码，高水平程序员总在思量数据结构及其之间的关系）

　　数据结构思量清晰了，焦点的算法自然就出来了，这就是关于每个类的每个要领怎样实现的问题。好比需要实现一其中位数查询要领，若是你前面确定了数据生存的花样是一个列表，那么你可以思量接纳插入排序法；若是数据花样是自平衡二叉排序树（AVL），则只需直接返回根节点就可以了。

　　数据结构决议算法，以是你在思量数据结构的时间，一定要尽可能地使数据的结构和它的自然属性相匹配，否则后面的实现就会是一场噩梦。好比，你把一个多层级的结构界说成二维数组，看上去也靠谱，相当于在一个表格里维护一个组织结构图，可是当你做到部门增减的时间，本层级的数组元素移动自不必说，下面各APP软件个层级的元素移动就很容易乱套，而且性能很差，可能你写了2000行代码另有许多界限条件会堕落。相反，若是用一个孩子兄弟链表来表现这个树型结构，操作起来就很是容易，可能100行都足够了。

　　思绪确定后，实现历程也需要大量的构想运动。遇到你比力熟悉有履历的领域，你自然可以轻车熟路，但难免会有一些你不太熟悉的手艺需要实验。有的同砚比力排挤这种领域，好比我好不容易才掌握了Struts 2，向导又让我去学习Grails框架，我就会以为很不爽，或许看了看就挑出它的一堆问题，然后能躲多远就躲多远。可是我要说，这样的心态会阻碍自己不停提高手艺水平。作为一个程序员，最大的挑战也是最大的兴趣所在，就是不停学习新的手艺，没有这样的心态，很快就会落伍。

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

 1/2    1 2 下一页 尾页