老码农的自我修养：如何规划性的写出高质量的代码？分享给你！

 

1. 数据结构和核心算法

关于数据结构的重要性，大神Linus Torvalds讲过这样的话，我以为很是赞同：”Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” 

（低水平程序员总在考虑代码，高水平程序员总在考虑数据结构及其之间的关系）

数据结构考虑清楚了，核心的算法天然就出来了，这就是关于每一个类的每一个方法如何实现的问题。好比须要实现一个中位数查询方法，若是你前面肯定了数据 保存的格式是一个列表，

那么你能够考虑采用插入排序法；若是数据格式是自平衡二叉排序树（AVL），则只需直接返回根节点就能够了。

数据结构决定算法，因此你在考虑数据结构的时候，必定要尽量地使数据的结构和它的天然属性相匹配，否则后面的实现就会是一场噩梦。好比，你把一个 多层级的结构定义成二维数组，

看上去也靠谱，至关于在一个表格里维护一个组织结构图，但是当你作到部门增减的时候，本层级的数组元素移动自没必要说，下面各 个层级的元素移动就很容易乱套，

并且性能不好，可能你写了2000行代码还有不少边界条件会出错。相反，若是用一个孩子兄弟链表来表示这个树型结构，操做 起来就很是容易，可能100行都足够了。

2. 功能实现

思路肯定后，实现过程也须要大量的构思活动。碰到你比较熟悉有经验的领域，你天然能够轻车熟路，但不免会有一些你不太熟悉的技术须要尝试。有的同窗 比较排斥这种领域，

做为一个程序员，最大的挑战也是最大的乐趣所在，就是不断学习新的技术，没有这样的心态，很快就会落后。

好，那么遇到不熟悉的技术怎么办？个人体会是，先不要急着实现项目中的代码，本身另外维护一个测试项目，在里边边查文档边学习，边作一个小功能，把 全部须要在项目中实现的功能先在测试项目里跑通，

而后再写项目里的代码。这样作的好处是把单个技术问题和其余潜在的bug隔离开来，便于快速学习新技术。 不然，你直接在项目里写代码出错之后，要判断问题的源头都要多费好几倍的精力。

 

 

3. 测试

测试很重要，设计测试用例就像开发时设计数据结构同样，也是很关键的。在设计测试用例的时候，要把当时本身设计数据结构的思路所有忘掉，或者找别人 来设计测试用例，

否则会不禁自主地测试那些你已经考虑到了的地方。这样测试是跑通了，用户一用起来可能各类边界条件会处处出问题。

写到这里我又想到大神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首次发明最短路径算法的时候，他给出 的代码里没有一行注释，即便全部的变量命名都定义得准确而严谨，又有几我的能看懂他的算法呢？

因此，在重要或者复杂的地方，都须要详细地写一些注释，便于 看代码的人清晰地了解你的思路。

另外若是你想更好的提高你的编程能力，学好C语言C++编程！弯道超车，快人一步！笔者这里或许能够帮到你~

UP在主页上传了一些学习C/C++编程的视频教程，有兴趣或者正在学习的小伙伴必定要去看一看哦！会对你有帮助的~

分享（源码、项目实战视频、项目笔记，基础入门教程）

欢迎转行和学习编程的伙伴，利用更多的资料学习成长比本身琢磨更快哦！

免费学习书籍：

 

免费学习资料：