?

（一）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++編程知識，成為一個優秀的程序員關注博主。

總結

以上是生活随笔為你收集整理的C/C++工程师需要掌握哪些技能？他们的工资这么高，是有原因的！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。