随便扯扯,程序员应该具备哪些素质
趁着这几天无事,好好总结一下从事软件开发以来的一些想法,这篇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的传说已经渐隐渐逝了。
团队协作包括沟通能力,接口协商,版本控制工具的使用等方面。容易出现的是相互推诿责任,对别人的请求不耐烦等,这于团队协作毫无益处。
高效的团队协作应该是模块间接口稳定,基础类库一致,框架代码共享,版本更新信息及时,沟通反应快速有效。