我是一名普通的软件工程师，不是什么技术大牛。这篇文章所提到的“七种武器”只是我这些年工作经验的一点体会和感悟，如果有错误的地方，还请大家指正。
（一）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的好奇心。
以上就是我总结的UNIX/Linux C 程序员需要掌握的“七种武器”，同时也很感谢你能耐心地读完这篇文章。如果这篇小文没有让你觉得浪费时间，而是对你有哪怕一点小小的帮助，我的目的也就达到了。如果你有一些好的观点，也非常欢迎你能分享出来。谢谢