工作3年之余，發現精力會隨著很多事情而降低，以前覺得很有激情很有興趣的東西，可能會慢慢變得“無關緊要”了。不知道這是一種所謂的灑脫，還是一種懈怠。總之我會努力克服現在的狀態，讓自己的業余時間再充分利用起來。加上最近得了一個“准專家徽章”，為了對得起這個徽章，也為了擺脫前面的懈怠，我要堅持寫下去。
之前在網絡上，一群伙計在那兒討論關於CC++程序員是否應該對匯編語言有一定的掌握程度的問題，當然我作為一名CC++程序員也參與了討論。對於這個問題，我有我自己的觀點，可以說是親身的感受和經歷以及經驗之談。於是，抽這個中秋假期有時間，跟大家分享一下。當然，首先聲明一下，本文只代表我個人的觀點，您願意接受，我感欣慰；不願接受，就當我在這裡唱獨角戲。技術上的東西，每個人都有自己的一套方法，沒有對錯，還是我一貫的觀點：我只吸收對我有用的，無用的就當看小說吧。
首先，就本文標題而言，為什麼強調是“某種匯編語言”。我想，大家都知道，匯編語言只是所有平台匯編語言的統稱，這樣說來，不同的平台就會有不同的匯編語言，即不同的匯編指令、不同的機制等。這裡所謂的某種，即在自己經常工作的平台下的匯編語言。
其次，對於是否應該掌握這個問題上，反對掌握的觀點大致有以下幾點：
1、對於普通軟件開發人員來講，關注於上層實現，關注於功能和產品才是主要，匯編也用不到。
2、很多的CC++程序員不懂匯編，也成為了某公司某項目組主程序、核心研發，因此匯編可以不學不用。
3、絕大多數CC++程序員還是在做上層開發，絕大多數項目也是上層開發，不了解底層也能賺到大錢，而且是更多的錢。
4、做底層，比如：逆向、破解、寫病毒等，很多致力於這層的程序員，感覺整天昏天暗地，無數的重復勞動也沒賺到大錢，覺得沒意義。
5、對於做C#、java、WEB等領域的程序員們，大多數不會去關注底層實現，他們照樣過得很好，以此類推，匯編也是可以不掌握的。
6、匯編語言幾乎是不跨平台的，於是就算你掌握了某個平台的匯編，但你在匯編語言上，例如語法、機制等還是有局限性。
我就暫時列舉這麼幾種反對的觀點，可能你還有其他的看法，歡迎你的回復。至於支持掌握的觀點，也就是我個人的觀點，我個人是站在支持一方的。所以下面就是我針對上面幾種反對的觀點的看法以及我個人的體會。
從上面幾種反對的觀點來看，可以總體分為幾個關鍵點：利益、收入和興趣。我不打算將這三個關鍵點分別進行針對性闡述，因為它們之間都是息息相關分不開的。對於利益和收入上來講，的確是有很多公司的高職位且收入不錯的程序員並不了解匯編和底層，這樣也不代表他們沒有能力，而往往他們是非常有能力的人。這樣一來似乎和我個人的支持類的觀點有所沖突，但我認為這個沖突可以用追求二字來化解。為什麼可以用追求來化解呢？因為追求可以是任何領域、任何方向、任何目的和任何標准的，因此也就是我前面所說的，歸結到根本，掌握不掌握都沒有對錯。那我就說說我作為一個程序員的感受吧。
我們進入這個行業，從事了編程工作大多數程序員都是編程開發做起的）。我相信很多程序員的初衷，都是對編程開發有很大的興趣，興趣驅使著我們熬夜，驅使著我們研究， 驅使著我們進步。對於CC++程序員，我相信興趣占有很大的比重。那麼，我們來舉幾個例子：
你應該看過《深入C++對象模型》這本書吧，這是一本非常細致和美妙的書，我想你應該有這樣的感受。那麼在此基礎之上，你有過更多的思考嗎？這本書裡都是以實例和理論來進行講解的，實例是以C++語言進行描述的。於是你是否有想知道在具體的編譯器和平台下的這樣一些疑問：
1、this指針是怎麼傳遞進成員函數的？成員函數和普通函數以及靜態成員函數有何區別和聯系？
2、透過語法，成員函數和類在內存中有什麼聯系？對象和成員函數有何種聯系？
3、函數間的調用原理，是怎麼實現的？
4、__cdecl、__stdcall、__thiscall和__fastcall這幾種函數調用方式，在本質上有什麼區別？具體是怎麼實現的？
5、虛函數、多態和繼承在本質上的體現，以及這些機制在底層是怎麼實現的？
除此之外，你在學習和使用CC++的時候，我想你還會在乎一些細節，例如：
1、遞歸函數一定會導致低效？編譯器針對遞歸函數會不會有什麼樣的優化？你怎麼知道這些優化細節？
2、對於這句代碼：int b = a > 0 ? 100 : 200; // int a; 編譯器會有什麼細節上的優化？這句代碼會有比較並跳轉的過程嗎？
3、對於這樣的代碼：
- #include <stdio.h>
- int a = 10;
- int main( void )
- {
- printf( "%d", a );
- return 0;
- }
在VC下，開啟全局優化，全局變量a還存在嗎？你怎麼通過本質的論證來證明？
4、對於：float a = 100; int b = a / 30; 在VC下，你會不會懷疑這兩句代碼背後會存在函數調用？如果有，調用了什麼函數？為什麼？
5、對於__declspec( thread ) int g_nNum = 0; 你知道g_nNum++;這句代碼背後的具體實現機制嗎？
6、對於調試，你會怎麼根據自己記錄的程序崩潰時的堆棧現場及其它信息來錯誤跟蹤查找呢？
7、對於開發游戲來說，你怎麼知道外掛是怎麼修改游戲程序的，修改了哪個地方呢？
8、你要怎麼熟悉編譯器的優化細節，怎麼寫出適應它的代碼，怎麼寫出比它優化得更好的代碼？
還有很多這樣上層開發的例子，這裡就不一一列舉了。從上面列舉的這些疑問，我想作為一名CC++程序員，熱愛編程開發的程序員來講，你都想知道其中的原委。作為上層開發者，是應該關注上層的功能開發和產品方面的東西。但是我個人覺得，本著技術，本著這份熱愛，本著自身的技術發展，了解更底層一些，有助於上層開發的通透性，以及全局的掌控力度。從我個人的感受來講，當把握了關鍵細節以及全局設計之後，任何地方出了問題，都能很及時的反應並予以追查和處理。在當前的編譯器技術上，已經非常強大了，很多細節可以放心的交給編譯器來優化和處理。但是我想，編譯器不是萬能的，人才是最智能的。掌握不是必然，但掌握了會更好。
對於初學者乃至工作了一定時間的程序員，對於CC++，很多處於CC++語法的層面，在語法上的條條款款使用得得心應手，問其本質，可能就缺乏一二了。我個人的經歷來看，在掌握語法之後，在向下關注一下語法背後的具體實現，會通透很多。你會在內存上、數據上和程序的各種底層運行機制上會有深刻的認識。這也就是為什麼去海邊玩兒，還要潛水去看看海底世界。錯過了海底，你會失去很多精彩，而這些精彩我想也是作為程序員應有的追求之一。
對於java、C#以及WEB類領域的程序員，我想匯編可能相對遙遠一些。在這方面的關注也會相對少一些，但結合前面的觀點，作為程序員這個角色，都是讓自己的程序在機器上面跑起來，那麼我想這之間的諸多底層的疑問可以作為程序員的一種興趣來研究。目的也是為了讓自己更通透，更熟悉自己的平台。我不知道怎麼表達通透二字，就我個人的感受就是，能夠從現象聯系到本質實現，並且能夠從本質實現勾勒出一幅很清晰生動的圖像在腦子裡，一切都一目了然盡收眼底。有點居高臨下，望長城內外，惟余莽莽的那種寬廣的感觸。
對於本身就處於底層開發的程序員來說，無可厚非，掌握匯編就是必須的了。但是澄清一點，本文的觀點更多的是從興趣和通透性上出發，對於底層開發者可能會覺得底層有一定的枯燥，特別是整天破解、逆向等工作，非常多的體力活，從我幾年的業余破解和逆向經驗來看的確是這樣的。但是我覺得，破解和逆向只是領域之一，我之所以破解和逆向，很多時候是處於興趣和為了對上層進行更本質和合理的解釋。所以，上層和底層結合，才是我的根本目的，也是本文想推崇的一種思路。
綜上所述，我的觀點是CC++程序員乃至程序員，不管是作為興趣還是工作，掌握或者了解一下匯編都是有一定必要的，但不是強制性的，也正所謂需求和追求不盡相同罷了。因此，不要問別人到底是否應該關注一下底層，掌握一下某種匯編語言，答案很明顯。
號外：如果想更多的了解掌握了匯編的好處，可以看一下本博客裡的C/C++ inline匯編語言》版塊的文章。
