程序員請不要忽視調試技術
想寫這篇文章已經很久了，但是一直不知道如何開始，因為調試技術這個東西本身不像編程語言，C++/C#這種簡單的東西，大家想做些什么，查查類庫，查查msdn，寫出一些功能，皆大歡喜。
調試技術本身就很枯燥，如果沒有一定定力的兄弟，看看可能就覺得犯困，沒勁，沒成就感。但是想想程序員，每天寫代碼一小時，可能調試的時間至少也需要一小時，當然，寫到這可能你不同意，覺得你自己不是這樣的，你不需要調試，對，我說的只是一般情況，不排除有高手，口水戰也沒社么意思，直接忽略這種情況。
不知道為什么，國內研究調試技術的人不是很多，可能大家都覺得這些基礎的東西沒意思，大家都在研究雲計算，研究設計架構模式吧，我等無法企及的高度。呵呵，不扯了，開始重點的：
據我所知，在軟件開發過程中有些及其重要的環節都需要調試技術，而且國外對這方面研究的也很多，我也不想說誰浮躁，但是這些基礎的技術確實值得我們研究。
舉個例子：
你公司開發的產品，在客戶那邊crash了，客戶的環境不允許你訪問，客戶不知道問題是怎么發生的，他說他喝了杯茶，回來就發現問題的。
你想，你妹的，你還拉屎呢？
其實這個時候就需要調試技術了，怨天尤人是沒有用處的，最好的方式就是分析日志，查看.dump文件，但是你能看得懂么？學學調試技術吧，學學反匯編吧，其實這些東西都是作為程序員的基本功，別告訴我你會雲計算，在這個時候，對客戶一點用都沒有。
下面說說主流的調試技術：
由於調試技術比較接近系統底層，所有他和系統的架構，比如X86, ARM，有緊密的關系，常見的架構是X86，而且和OS相關，常見的OS是linux和windows。
windows 平台的調試工具比較多，高手用windbg比較多。
linux不用說，用GDB的比較多。
寫幾個demo考考大家的調試水平：
When you are using recursive definitions of this type, each alias is translated as soon as it is used.
For example, the following example displays 3, not 7.
0:000> r $.u2=2
0:000> r $.u1=1+$u2
0:000> r $.u2=6
0:000> ? $u1
Evaluate expression: 3 = 00000003
Similarly, the following example displays 3, not 7.
0:000> as fred 2
0:000> r $.u1= 1 + fred
0:000> as fred 6
0:000> ? $u1
Evaluate expression: 3 = 00000003
The following example is also permitted and displays 9.
0:000> r $.u0=2
0:000> r $.u0=7+$u0
0:000> ? $u0
Evaluate expression: 9 = 00000009
總結
我寫這篇文章的意圖是想說明，作為程序員，除了必要的算法，語言，系統，必要的調試技術也是基本功，而這項基本功在國內沒有引起足夠的重視，希望你可以看到我這篇文章。