想成為計算機技術高手，一定要懂彙編嗎？
大概在另外一撥人的眼裡，成為計算機學科的高手應該是把數學學好。你們這群人都只是低端的碼農，只有把高等數學學好，精通概率、統計、隨機過程、抽象代數，熟練掌握各種建模方法，才是計算機科學的王道。再結合各種領域知識，年薪百萬輕輕鬆鬆。弄點高級演算法幾十億被收購瞬間財富自由。
技術只是技術本身，計算機發展了這麼多年，無數新技術層出不窮。每個人都靠著自己的專長在這個領域發家致富。有的人是因為懂客戶需求，有的是擅長做設計，有的人擅長把成熟的技術應用到傳統的學科之中。彙編只是這茫茫技術中的一種而已。
本質上來講，高手的本身並不是掌握了什麼技術，而是能夠幫助別人解決問題。一種技術只是解決問題的一種方法，而不是唯一的方法。如果解決這些問題需要精通彙編，那麼你一定需要掌握。如果想解決的問題並不需要了解彙編知識，你大可以不掌握。彙編知識與很多其他知識在知識本身這個層次上並無優異之分，只不過在計算機領域更底層一些。
最後，計算機的基礎知識，比如操作系統、資料庫、計算機網路、編譯原理，該了解的肯定要了解，該入門的要入門。
至於是否要精通，如果你發現在你成長的過程中遇到的瓶頸，是對於底層的了解，那你就應該精通。
一直覺得軟體行業有個很有意思的現象，就是絕大多數人都覺得越是懂底層的人就越是牛逼。
不巧個人十來年前初中時開始用8086/8088彙編寫一些小應用，後來大學到工作零零散散也寫點，談不上什麼高手。但一直感覺彙編說白了就是一堆的MOV/CMP頂著寄存器和內存做各式各樣晦澀的操作，外加INT各類硬體、系統中斷滿天飛，平時開發都是抱著一本手冊四處查各種中斷號及flag，熟練點的同事能背下中斷，再熟練點的能看機器碼如看彙編——一個同事經常自稱「看盡天下A（ASM）片，心中自然無碼（機器碼）」:)。
個人覺得彙編說白了只不過是門語言而已，和c/java/c++本質上沒有區別，只是你使用這門語言必須接觸CPU寄存器、需要更好的關注和規劃內存使用、需要了解各種硬體和系統級API（中斷）、需要寫更多行的代碼、更容易出錯、比高級語言更難寫出優美的程序……這些……在我看來，除了讓開發者更苦逼之外，實在看不出這門語言的好處。性能？現代編譯器下的C語言早已和ASM相差無幾。
如 @張運政 所說，要精通這門語言，確實需要比精通其他語言付出更大的努力，因此精通這門語言的人或許確實厲害，但這並不代表厲害的人一定要精通這門語言——充分不必要。
我更同意 @吳海波 的答案，編程並不只是操作系統和底層——如果只是這樣那軟體行業這幾十年無數大師們的努力等於白費了，編程語言本身、軟體設計、人工智慧、軟體工程、互聯網……等等這些都是讓編程變得豐富而有趣的元素。
是否懂底層不重要，在編程的路上堅持對美的追求，才是通往高手之路。
P.S.
這麼老的問題怎麼突然就火起來了，補充說明一下：
我無意貶低彙編，只是希望大家正視它——它並不神秘，也不是什麼高大上——沒有任何一門語言值得說高大上的。
但，術業有專攻，這點毋庸置疑。你拿Java在要求高性能的單片機上跑和用彙編寫個taobao同樣是扯蛋的事情。
編程是很美好的東西，而語言僅僅只是工具，在高手之路上，請不要被語言所羈絆。
P.P.S.
對不住讓大神刪帖了，我道歉。樓下幾位的答案也非常客觀理性，我都點了贊。
面向對象編程大師——Martin Fowler
EJB終結者，Spring創造者——Rod Johnson (programmer)
Java語言的革新者，《Effective Java》作者——Joshua Bloch
JSON發明者，《JavaScript: The Good Parts》作者——Douglas Crockford
Ruby on Rails發明者——David Heinemeier Hansson
Hibernate發明者——Gavin King
……
當然我相信大家也能舉出各種與彙編相關的大師，也許以上幾位也懂彙編（也許不懂），但至少他們所作的貢獻是彙編無關的。
作為一個遠遠不是高手的菜逼，工作兩年期間越來越明白一個道理：沒有任何一種具體技能（包括語言，開源工具使用，IDE使用等等等等）是「一定要學會」的。相反，高手們的技能永遠是強大的學習能力+飽滿的熱情與積極性+沒有拖延症的實踐精神-&>更強大的學習能力+拓展的知識面與技能樹-&>解決問題的方法論。
所以，成為一個高手的基礎是培養自己的學習能力，以及正視自己的性格弱點並改正他們。後者還好說，前者就需要不斷地學習鍛煉並打好必要的基礎了。並且，這個基礎也不是彙編語言，而是計算機組織與結構，網路通信等本科階段很多人混過去應付的課程。
反正我自己現在就在補課中，成為高手真是前路漫漫。技術高手不一定要懂彙編。但是可能懂彙編的技術高手可以比不懂彙編的技術高手能勝任的任務多一些。
不贊同@郭凜的回答。
當然，在當今流行的晶元架構下，只是寫MOV和CMP要寫過gcc，已經是很不容易的事情了。但是gcc並沒有覆蓋所有指令集的各個角落。比如，如果要充分利用SSE/MMX/AES-NI等相對比較新的指令集，常常還是需要內嵌彙編來救火的。再比如，如果到了手機上或者其他嵌入式計算設備上因為體系結構的不同，gcc就未必總是能做出最好的選擇了。再比如，如果到了有不同IO/DMA/匯流排架構的伺服器上，不了解底層的基本原理和架構邏輯，很多程序寫出來是很難發揮出硬體應有的威力的。這如果在公司里，對應帶來的就是資源的浪費和服務產品的成本劣勢。
當然，編程並不只是操作系統和硬體，但卻也脫離不了操作系統和硬體。Google的發展和成功有很多因素，但是他們的大部分工程師都知道一個cache hit和一個cache miss的性能區別恐怕也是很重要的因素之一。對計算需求的認識和計算應用的設計固然很重要，但是對計算實現的執行恐怕也是同樣重要的。Facebook經常會拿出來講的一句話是一個程序1%的性能優化，跑在整個集群上，往往為公司節省的是上百萬的成本開銷。
什麼是技術高手我不知道，也不太在乎。但是不關注細節的編程之美，恐怕更多是偷懶的花拳繡腿，在殘酷的競爭環境下怕是不容易站住腳的。
不知道你對技術高手的定義是什麼。在我看來，高手是在某個領域解決了某些還未被解決又重要的問題。懂不懂彙編不是一個判斷你是否是高手的標準，如果在你的領域需要它，或者在你的預判中需要它，那麼當然要學。但是如果不需要，你應該考慮下自己的精力問題。
就像把現代人放到原始森林中和動物競爭，已經毫無優勢可言，我們喪失了許多我們祖先賴以生存的根基。但是判斷一個的能力、作用，脫離他的時代、領域而談，是毫無意義的。我們的社會不斷的在發展，很多東西都只是臨時變數，具有生命周期，遲早要消失在歷史的舞台，重要的是去了解這個生命周期。
技術高手，不是指那些可以在一個領域上做得很好的人。技術高手說的是，在很多領域上都做得很好，然後再那麼一兩個領域做得屌爆了
我認為，要成為一個c++高手，是一定要懂彙編的。這裡的懂彙編並不是說要用彙編來寫程序，而是彙編級的調試。 在開發過程中，遇到的種種難以解決的AV異常，堆異常，堆溢出，藍屏等情況，用彙編來調試往往會有事倍功半的效果。
你的軟體在客戶環境崩潰，生成了dump文件給你，你分析的時候，懂彙編比不懂彙編會得心應手很多。
先說高手的定義，高手永遠是脫離不開他所處的環境的。在一個特定的領域內，能完成別人無法完成的任務，能解決別人無法解決的問題，能作出別人無法超越的成就的人，稱之為高手。
再說計算機技術，是一個籠統的說法，太博大了。發展到現在，我們圍繞計算機已經出現無數多的細分領域，比如語音識別，人工智慧，圖形圖像，機器學習，等等。這些領域內又出現無數的分支。有需要硬體知識有不需要硬體知識，有需要新材料知識，有需要生物學知識，等等。
但是我們卻沒有看到那一個學科，或是細分領域，因為編程語言而無法繼續研究。再美妙的語言，終歸是一個工具，而我們要做的是一篇文章。古今中外的有無數的文學巨匠，詩詞大家，並沒有因為他們寫文章詩歌時沒有用甲骨文，楔形文而否定他們的成就。
語言工具永遠不能，也不應該成為我們成為高手的門檻。語言不好用，工具不和手，我們可以從新選擇，沒有時我們可以創造。（很多腳本語言也是為解決研究領域內的某些問題才產生的，而多數原語並不是彙編）牛頓在研究宏觀物理學運動規律時創造了微積分。John W. Backus在解決工作問題時發明了fortran。
只要我們有一顆成為高手的心，並且不斷努力向前。我們就有機會成為高手。工具只是我們高手路途中的一個小插曲的小配件。（無意貶低任何語言，每一種語言都有其特定應用環境）
想成為高級廚師，一定要去自己種田嗎？
你可以不懂彙編，但是你得懂如何構建引導區代碼，如何進行低級bios操作讀入下一步的引導代碼，什麼是中斷，如何修改中斷向量表，x86中如何切換到保護模式/長模式，如何開啟分頁機制，如何構建四層頁表，如何處理缺頁中斷，如何從APIC通信獲得時鐘中斷，如何保存/切換上下文，如何設置緩存，如何閱讀處理器文檔，了解這些設計哪些還不錯哪些就是sb。這樣不懂彙編也行。
因果反了，現在要把彙編玩出花來各種CPU手冊編譯手冊是少不了的，那東西比什麼21天的可讀性差了不是一點兩點，其他的比如成就感低（別告訴我會有人拿彙編寫GUI，折騰半天連個能給妹子看的東西都沒有），圈外認可度低（至少我還沒見過誰能把HTML5和彙編都玩的溜的，拿到外面去大部分人只會抽抽鼻子罵聲「土鱉」），所以在篩去了大把湊熱鬧的人之後，玩彙編的相對於玩Java的人來說更深入的可能性就更大了。BUT，這不代表你學的深入就一定要懂彙編，相反，做前台的牛人一百個裡面估計也找不到一個會C及以下技術的，只能說要用到的話就努力的鑽，確定用不到的話就讓他們過去吧。
如果不是做kernel相關的開發，沒必要專門學，遇到問題的時候拎著手冊能看懂就好。比起掌握彙編指令來說，更重要的是理解CPU的體系結構，運作方式。
搞底層的最好知道一下，不學彙編，系統理解只是一知半解。
系統底層的C編程和應用也有很大不同，很多位操作的。
如果學了彙編，你會知道相應的位對應什麼標誌。
學吧！
樓上竟然也能吵起來。
知乎這屁大點地方一點學術氛圍沒有！
題主問的需不需要懂彙編而已!這年頭哪個逗比直接彙編寫項目？找個出來，老子喊他爹。
題主你好。不知道你所謂的高手是什麼層次，什麼境界，不過你想深入的話，懂，是必需的。
不懂彙編，基本你就不會懂計算機原理了，系統原理，寫不出什麼好代碼我只知道當年老美那些用彙編語言甚至是機器語言寫代碼的人後來都成為了計算機科學家
換個口味，彙編和高級語言的區別大概是修車和開車的區別，如果你只開不修，就沒太大必要懂，如果你覺得適當條件下，或者不可避免的要修修，那就學學。
另外，還看你對計算機高手的定義如何了，intel的工程師不僅懂彙編，彙編的硬體實現就是他們的工作；知乎的後台服務據說是用python寫的，他們大概不懂彙編。一般來說，兩者都不愧是高手，具體到個人，看你喜歡啥了。
曾經有過一段較長的時間是主職x86彙編，回想那段時光應該只能用「痛並快樂」來形容了
- 題目所言技術高手，實在是一個過於模糊的概念，計算機包括太多的程序語言和應用領域，彙編顯然不是一個評價是否為技術高手的標準
- 單純的彙編語法並不能夠作為一個計算機高手的標籤，因為語法並不複雜
- 能夠通過彙編語言去了解計算機運行機制也只是為某些人提供了更好地一種理解方式，但並不是所有技術高手都被要求必須有這個興趣或能力
想成為計算機高手不一定要懂彙編，但是計算機高手一定會對彙編有很大的興趣。
懂彙編還是必要的條件（能看懂相關信息），做程序profiling的時候很有必要。但是沒必要重新將彙編語言抬高到一個很高的寫程序的條件。
這個問題主要是」高手「這個稱呼不好定義。
什麼樣的人算計算機高手？有的人只會寫個flash小遊戲，但是賺了幾百萬算高手么，有的人優化產品的核心代碼，使產品運行速度提升好幾倍，算高手么？有的人精通軟體工程，提高整個軟體開發效率幾十倍，算高手么？有的人寫程序很爛，但是精通數學破解md5算高手么？有的人精通各種中間件，寫幾十行代碼就能完成別人寫1個月的工作，算高手么？有的人只會c++還不精通，但是輕鬆在各種場景使用個中高大上的演算法高效率完成工作算高手不？有的人數學不好，但是知識購廣，什麼活都能幹算高手不？這裡面有的人數學好，有的人對系統理解的好，有的人懂彙編，有的人不懂編程，都算高手不？
推薦閱讀：