程序员应该具备哪些素质

趁着这几天无事，好好总结一下从事软件开发以来的一些想法，这篇blog尝试从我自身的一些经历来谈谈程序员应该具备哪些素质。如有不足之处，还请不吝赐教！

下面，我将列出并展开所有我认为程序员必须具备的素质。

基础知识你也许是像我一样的自学者，没有数电/模电，编译原理，操作系统原理，网络与数据库等方面的知识，但是对于这些你应该尝试去了解、理解。当初跨专业考研之时学习的操作系统/网络/数据结构/数据库的知识于我现在的工作仍然有益，我有遇到过一些能力很强的人，他们做解决方案很强，但是debug能力说实话不大匹配其水平，原因就在于其不了解很多底层的原理。

对于C/C++程序员而言，其底层是操作系统和编译器，所以需要了解操作系统原理，汇编，编译原理等。

对于java/c#程序员而言，其底层是虚拟机和框架，也应该去尝试了解虚拟机的构成，GC原理等。

我在网上遇到很多c/c++，java/c#程序员，很多时候都发现前者更喜欢追根溯底，后者更在乎如何使用框架，无法评判那种态度更好，但是了解得更深入很显然是有好处的。

算法与数据结构推荐阅读《大话数据结构》，《算法导论》。

算法与数据结构怎么强调都不为过，虽然大部分程序员在工作中并不一定会用到很多高级算法，也并不会去参加ACM，但是理解常用算法应该是一种基本素质。

应该掌握的常用的数据结构：数组，单链表，栈，队列，二叉树。

应该掌握的常用的算法：顺序查找，二分查找；冒泡排序，选择排序，插入排序；深度优先算法，广度优先算法。

进阶数据结构：双链表，循环链表，双端队列，哈希表，跳表，大根/小根堆，哈夫曼树，排序二叉树，平衡二叉树，红黑树，B树/B+树，图，etc。

进阶算法：二叉排序树查找；快速排序，希尔排序，堆排序，归并排序，桶排序，基数排序；KMP字符串匹配算法 ，etc。

自学能力自学能力对于程序员来说非常重要，因为IT这行更新的太快了，几年不学习很容易就会被时代抛弃，国内尘嚣其上的“30岁转行论”有这方面的原因。我不是科班毕业的，大学学的是水利，和程序员什么关系都没有，一直以来都是自学，我将结合我的经历谈谈自学。

首先需要学习的是编程语言。我接触的第一门语言是Visual Basic，大部分理工科应该都有这样的一门编程课，或是vb，或是c，也有的是c++。这种课程对于大部分不感兴趣的人来说都是一种折磨，不过我对这种计算机按照我的意图来执行非常感兴趣，所以这样的课程很对我的口味。在课余，我会去图书馆借一些vb的书来看看，偶尔也会跟着书上的代码对照着敲代码。后来觉得vb功能有限，且无法理解vb之下的秘密，所以转而自学java，这次是在网上找的马士兵老师的java视频教程，跟着学习了一段时间。因为我的笔记本性能不够，臃肿的JVM运行的非常慢，转而学习C++。现在我在学C++11。

其次要学的是框架，库，API等，这时候你可以尝试做一些有意思的程序出来，通过这些学习基本上可以胜任某些方面的工作。

再次要学的是某个具体的方向，比如web，图形，图像，搜索引擎，机器学习等等专业领域，这些知识的学习应该是在日常工作中不断积累的。

这段时间的自学告诉我，凡事只要去努力去学习，都会有成果，所有看起来高大上的东西理解之后会发现就那么回事。此外，比较广泛的阅读了许多书籍，对我现在的工作仍然有利，许多事情是你首先得了解你才会去应用，很多好东西在书上在网上，你知道了才会在某个未来的时刻用上，如果你不知道那你只能错失良方许久。

学习是持久的，在实际应用中仍然会碰到你不熟悉的特性，会碰到坑，这时候你需要的是信息搜集与筛选的能力！

信息搜集与筛选在实际编程中，肯定会碰到各种各样的问题，有些是常见的问题，有些是莫名其妙的问题。

我的建议是首先尝试自己解决，次之看官方文档和讨论区是否有解释，然后再去搜索引擎/stackoverflow查找有没有相似问题的解决方案，最后再去社区（CSDN/cnblogs/oschina/stackoverflow等）提问。

强烈建议分享自己的解决方案和思考！

作为一个互联网/开源受益者，分享应该是一种基本美德，特别鄙视发布问题自己找到解决方案之后就结贴走人的程序员。

分享自己的解决方案与思考不仅仅是让像你一样的疑惑者受益，同时还是教学相长的一个过程，自己也会从中获益。

如何分享自己的思考，这时候你需要的是总结的能力！

总结能力总结使人进步 ！ 在网上看到一个段子，分享一下：

-“你有几年的工作经验，怎么写的代码这么差劲？”

-“5年工作经验”

-“呵呵，是1年经验当5年用了吧。”

决定我们是1年经验当5年用还是真有5年经验，最重要的就是记得总结自己碰到的问题，自己的想法，前辈的教导！

需求分析与文档编写一个项目的流程大致为：需求分析 –》 估计进度 –》 设计架构 –》 编码实现 –》 Debug –》 测试 –》 Release 。其中coding，debug，test可能会反复迭代。

可以看出需求分析是决定项目的第一个关键部分，有些公司是由专门人员进行需求分析，但是作为程序员，应该要了解需求，确认需求。

文档包括很多方面，需求文档、设计文档、测试文档、使用文档、注释等，贯穿软件开发的所有流程。良好的文档不仅仅是对项目的负责，同时也会有利于项目的维护。

在项目注释中，强烈建议添加：TODO ， FIXME ， HACK ， XXX 等标签以帮助实现逻辑。

架构能力推荐《架构之美》

在我刚入职的时候，每当接到一个任务时，我都迫不及待的去在IDE中敲代码，这种渴望很强烈，很有成就感。但是一个前辈告诉我，你首先应该做的是架构设计，充分考虑所有可能的情况并记录下来之后再去coding，我记下来了但是在没有教训之前仍然没有很强烈的体悟，后来我便后悔了。在某个项目中，我很快的写出了原型，然后洋洋得意地在这个原型上像打补丁一样扩展各种功能，最后在新加的某个功能上栽了跟头，这个功能完全没办法凑进去 。所以，作为程序员，我们需要拟制住自己的编码冲动以及修改代码的冲动，先架构设计，然后再编码。

架构期应该给各个模块/类之间涉及一套相对合理稳定的接口，实现是易变的，接口不应该频繁变化。

我认为开发任何一个模块，首先要做的是理解需求，然后做架构设计，再然后布置基础设施（包括log，复用的宏，工具代码等），接着进行编码实现。

代码编写推荐阅读《编写可读代码的艺术》、《代码整洁之道》。

这个不用多说，没有代码就没有软件。想追求卓越，应该让我们的代码更优美，性能更好。

代码编写功底包括变量命名，函数拆分与提取，面向对象的特性应用，跨平台意识，多线程的同步，等。

这种能力是在日常coding中积累而来的，多做总结。

Debug能力推荐阅读《软件调试》、《格蠹汇编：软件调试案例集锦》。

没有不出现任何bug的一次性成型的代码，debug是经常会出现的场景。

debug应该尽量的少，同架构设计一样，碰到问题应该首先看代码，能直接找出来问题最好。如果看不出来，就需要专业的debug能力了。

bug的场景包括：逻辑错误，程序crash，内存泄露。

bug的范围包括：单模块，多模块；单线程，多线程；单进程，多进程；单机，联机。

bug的频率包括：100%出现，容易出现，很难出现。

可见debug的范围之广，bug总是如影随形。

很多时候我会抱怨，oh，见鬼了，这太莫名其妙了，在我机器上都不会出现，等等。我现在明白拿到反馈的bug我该怎么做了：首先闭嘴，然后重现问题，接着缩小问题范围，最后借助调试器或者log找出问题原因。

代码阅读能力说实话这一段我写的很伤感，因为要写“read the fucking source code”实在是太fucking了。

对于接手一个遗留项目，你需要的不仅仅是勇气，还有耐心。对于一个拿到的项目，首先要做的应该是先跑起来，作为用户去使用，了解它的功能；接着阅读设计文档，了解设计意图；再然后如果有版本控制历史的话，可以尝试从早期版本进行代码阅读；再然后是从main函数起大致走一下流程，了解关键route；再然后是对感兴趣部分进行单步深入；最后是通读代码，可以先将功能性代码比如log，hashtable等标记为已读，从头文件看代码间的联系，弄懂各个类/函数的职责。

说实话，对于具有一定强迫症的同学来说，阅读其他人写的代码应该是挺痛苦的，这时候有时间的话不妨对这些代码按你的标准进行重构。

重构能力推荐阅读《重构，改善既有的代码设计》。

不管是重构别人写的代码，还是重构自己写的代码，好像都不是什么令人愉快的体验。重构，不仅可以使得架构更加合理，而且使得程序更加健壮。

重构，按我的理解分为两种。

一种是自顶向底的重构，这需要对项目具有彻底的理解，才能高屋建瓴的对模块/接口/类/函数进行重新划分，再将以前的代码逻辑填充到新的框架下。

另一种是自底向顶的重构，这种方式是对某些代码进行优化重构，并且保证不影响实现，在重构部分区域之后调整局部结构，最后达到整体重构。

工具的选择与积累作为程序员，都应该有一套自己使用的得心应手的工具，这样会事半功倍。

这些工具包括：IDE，编辑器，辅助debug的工具，检测系统/程序状态的工具，版本控制工具，文件比较工具，性能分析工具，make/cmake等等。

团队协作现代软件工程单打独斗基本上不大现实了，像传说中的汇编写wps的求伯君大牛那样独自搞wps的传说已经渐隐渐逝了。

团队协作包括沟通能力，接口协商，版本控制工具的使用等方面。容易出现的是相互推诿责任，对别人的请求不耐烦等，这于团队协作毫无益处。

高效的团队协作应该是模块间接口稳定，基础类库一致，框架代码共享，版本更新信息及时，沟通反应快速有效。