C/C++工程师需要掌握哪些技能？他们的工资这么高，是有原因的！

 

（一）C语言

作为一名C程序员，熟练掌握C语言是最基本的一项技能。关于如何学好C语言，以及C语言话题的讨论，网上有很多经典的文章。很多人工作一段时间以后都自认为自己的C语言水平已经很高了。可实际在工作中，接触的东西也多了，开源项目多了以后，才发现自己的C语言能力太一般了。宏函数千变万化的写法，指针百花缭乱的用法…等等。写代码时，应常常问自己：这个行为是C语言规范定义的吗？如果是，是C89还是C99？我现在用的编译器支持吗？如果不是C语言规范定义的，那么在程序运行的这个平台，行为是确定的吗？所以建议大家平时可以多想想这些问题，查查资料，相信一定会对C语言有更深的理解。

（二）UNIX/Linux系统编程

在UNIX/Linux系统上开发程序，掌握系统编程API是必不可少的技能。而这方面的经典书籍都是一些大部头的英文著作，让人望而生畏。首先可以先找一本口碑不错的中文书先看一下，了解一下都有哪些种类的API。这样以后用到时，再去精读经典英文著作里的相关章节，或是查man手册。此外，如果有时间，可以学习一下经典的开源项目，了解这些开源项目是如何使用这些API的。举个例子，Redis是很多人推荐的一个很不错的学习C语言的开源项目。在阅读代码时，会看到保存数据到文件时会用到fsync函数，再去深入地了解一下这个函数的作用。这样比单纯地去看那些著作效果要好很多。

                                     

（三）网络编程及相关知识

关于网络方面，以下三点是必会的技能：

a）网络协议。在日常的工作中，大家接触和使用最多的无疑是TCP/IP协议族。此外，由于工作领域不同，也可能用到其它的协议。比方说，做电信相关的程序开发，平时可能接触SCTP协议会更多一些。对于这些协议，掌握最基本的知识是必须的，其它的边边角角知识可以等到用时再查。举例来说，TCP协议的“三次握手”，“四次挥手”，“TIME-WAIT状态”这些基本的知识点要弄明白，其它的边角知识学完老不用忘得也快，还是用时google一下效率更高。

b）Socket编程。Socket编程的经典书籍一点不比讲系统编程的书薄，所以可以选一本相对薄点，口碑不错的精读一下，这样基本就掌握的百分之五、六十了。另外有时间还是看一下经典的开源代码。这里还拿Redis举例，Redis里关于处理网络连接和通信的代码量不大，而且基本涵盖了所有常见的UNIX平台，看完以后一定受益匪浅。

c）协议分析工具。TCPdump、snoop（Solaris平台工具）、wireshark等这些工具不仅能帮助我们抓取数据包，还能分析数据包，这对debug网络程序有非常大的帮助。所以，我们至少要掌握这些工具最常用的功能。此外，对于开放源代码的工具，我们更是可以从代码中学到很多知识。举例来说，做短信相关的项目，可以从wireshark的分析短信协议的代码里学到很多东西，这可以帮助开发者对短信协议有了更清晰的理解。

                                  

（四）脚本编程能力

一提到脚本编程，大家首先想到的可能就是Bash shell脚本编程了。不错，在Unix/Linux上，Bash shell也许就是用的最广泛的脚本编程语言。应用开发工程师主要用Bash shell做两个方面的工作：a）用于编写监控服务脚本；b）写一些简单的单元测试脚本，比如循环发一些命令，等等。但是Bash shell的功能远远要比这些强大。一些高手用Bash shell编程语言写出了很好玩的游戏，也有人做出了很cool的网络应用。所以建议大家有兴趣可以多了解一下Unix/Linux的这层“壳”。当然，你也可以选择学习Python、Perl、Ruby等。不过相比这些语言，Bash shell至少你不用自己去安装，而且它能做的事同样很强大。

（五）操作系统及CPU体系结构

也许有一天，你会碰到这样的情景：你的程序在Solaris上会发生core dump，在Linux上却运行的好好的。经过一番艰苦的debug，最后得到的原因是两种操作系统对线程的调度策略不一样，这会使一个对全局变量没有加锁就访问的bug在Linux上很难出现。所以你需要尽可能地去了解你使用的操作系统，这样无论对写程序还是debug都会有很大的帮助。比如，你需要了解进程的内存布局，这样你就知道栈和堆到底在内存的哪段空间，为什么内存写越界有时会core dump，有时没事。

除了操作系统，了解CPU的体系结构也是一门必修课。比方说，SPARC CPU要求字节对齐，而X86 CPU则没有这个要求。又比如SPARC CPU是大端模式，而X86 CPU是小端模式，这就要求你对像位域这样的定义要格外小心。你还要了解你使用的CPU的汇编语言，至少能大概看懂。因为有些时候，当你从C代码中找不出bug的原因时，就需要你“透过现象看本质”，从汇编代码层面看看到底发生了什么。

（六）编译器和调试器

“工欲善其事，必先利其器”。编译器负责把源代码生成可执行文件，而调试器则是在程序出现bug时，用来“降妖除魔”的不二神器。以大家最熟悉的gcc和gdb为例子。

gcc有很多编译选项，除了要熟悉像-O，-g这些最基本的选项，建议大家可以多了解一些其它不常见的选项。因为这些选项很可能帮助我们找到程序的一些bug。举个例子，在比较新的gcc版本里，增加了-fstack-protector这个选项，而它可以帮助我们检查到缓冲区溢出这种bug。此外，你还可能碰到这种情况，一个bug总是发生在程序优化后的版本，而不会出现在没经过优化的版本。所以，多了解你的编译器，你就可以更好地了解你的程序是如何生成的。

                  

一个程序员不可能不碰到bug，而这个时候，调试器就是最好的工具。可以说，在遇到bug时调试技巧和手段是否丰富是衡量一个程序员的能力和水平的重要参考。除此以外，gdb另一个重要用途就是分析程序的core dump文件。程序的core dump文件好比一桩刑事案件的“犯罪现场”，而gdb则是刑侦官员用来在现场提取线索的工具。对gdb越熟悉，就越能从core dump文件提取有价值的信息，也就越有助于我们定位到程序bug的“root cause”。

（七）DTrace/SystemTap

DTrace是由Sun的几位才华横溢的工程师开发的，最开始只支持Solaris操作系统，现在FreeBSD和Mac OS X也都支持了。Linux上类似的工具有SystemTap，也有人把DTrace移植到Linux上，不过效果似乎并不好。简单地说，DTrace可以几乎不会在对整个系统有任何性能影响下，让你了解你的程序所发生的一切。这对分析程序的热点（“Hot spot”），了解程序的执行流程，定位程序bug都有很大的帮助。有些时候，DTrace可能是你唯一的工具。举例来说，有个程序只发生在生产环境，而在实验室环境无法复现（当然，理论上任何bug都可以复现，只是我们没有找到复现条件。）。你不可能在你怀疑的代码打上断点，然后用gdb去调试。这时你只能借助于DTrace，通过它去了解程序到底是如何运行的，当时的变量值是什么。此外，DTrace还可以帮你了解操作系统的kernel，这会满足很多geek的好奇心。

希望你有一天也能成为优秀的C/C++工程师，共勉！

学习C/C++编程知识，成为一个优秀的程序员关注博主。