優秀的程序員和一般的程序員差別在哪？

11-24

我覺得優秀的程序員，不僅優秀在代碼上，更重要在思維等方面。

我認為一個優秀程序員是謹慎的，在有需求與任務時，會不斷的澄清需求與任務，並且多次確認想要的結果，而非悶頭聽著或者看著需求與任務列表。

我認為一個優秀程序員的思維是清晰的，在寫代碼時，他的腦海是有一系列詳細步驟的，即知道他在做什麼，而且寫下的每一步他都能清楚的知道在表達什麼。

我認為一個優秀程序員的思維是縝密細緻的，在出問題後，他會詳細的先研究問題出在哪裡，思考緣由，而非悶頭瞎使用printf大法，然後去撞大運，頭痛醫頭，腳疼醫腳，因為這樣解開了Bug其實連自己都心虛。而優秀的程序員即使解開了Bug，他也會擴展問題，並且思考是否其它部分是否也有類似的問題，只是還未體現，而且他也會詳細反思獲得的經驗。

我認為一個優秀程序員的編碼習慣是良好的，他的代碼讀起來是賞心悅目的，若遇到難理解的實現點時，他也會寫下清晰的注釋來幫助後來人理解，因為他知道代碼不僅是讓計算機執行，更是需要讓別人也理解的，因為項目開發是團隊合作，而非單打獨鬥。

與優秀程序員的合作是愉快的，而非覺得難處。

在我平時所見到的程序員中，如果純以編碼能力來看，個人覺得可以分為五類，依次是：

1. 拷貝型
拷貝型選手就是傳說中的「代碼拷貝員」了，他們對實現功能幾乎沒有思路，所作的事情就是從網上或是之前其他團隊成員寫的代碼中拷貝出片段，然後放到項目中，如果運行項目出現了期望結果，則表示任務完成。
這類人只會改代碼，卻不會寫代碼。他們大多對編程毫無興趣，只是希望以此糊口；又或是加入了平庸的團隊，無法感受到技術的魅力。

2. 新手型
當產品有功能需求時，由於經驗有限，程序員並不完全知道要如何實現這個功能，需要通過學習、尋找資料等方式來解決問題。
這種情況下的編碼過程，程序員的主要目標是「完成功能」，那麼很難有多餘的心思去考慮邊界條件、性能、可讀性、可擴展性、編碼規範等問題，因此代碼bug可能較多，穩定性不高。常常會發生開發花費1個月，改bug卻要改上好幾個月的事情。

3. 學習型
這類程序員對所在領域的語言已經比較了解，對於一般功能可以有較為清晰的實現思路，給出需求時可以通過自己的思路來實現，並且會一定程度上考慮邊界條件和性能問題。但僅此而已，他們對可讀性和可擴展性考慮很少，也沒有項目級別的考慮，主要是希望通過實現代碼來練手或是學習。
這類程序員最大的表現在於喜歡「創造代碼」，即使有現成的實現，他們也希望自己來實現一套，以達到「學習」的目的。他們不喜歡復用別人的代碼，看見項目中別人實現了相類似的功能，他們會以「需求不同」的借口來自己重新實現一套。這類人一般來說對技術有著較為濃厚的興趣，希望能夠通過項目來進行學習。
從項目的角度來說，這種做法最大的麻煩在於開發周期可能較長（相比直接使用現成的實現），並且會使得項目代碼膨脹，影響未來的維護。但這類程序員由於有興趣，如果好好培養或許會成為明天的牛人。

4. 實現型
這類程序員一般有較為豐富的經驗，由於寫得太多，因此不再追求「創造代碼」來進行學習，同時對所在領域可能涉及的很多第三方框架或是工具都比較熟悉，當接受到產品需求時，對功能實現方案已經瞭然於胸，因此他們可以快速的實現需求，並且對邊界、性能都有一定程度的考慮。因為能夠快速實現需求功能，經常會被團隊評價為「牛人」。但他們一般僅僅停留在「完成功能」級別上，對代碼的可讀性、可擴展性、編碼規範等考慮較少，對項目總體把握也較少（例如控制項目膨脹、方便部署等架構級別的東西）。
這類程序員最大的表現在於喜歡「開發項目」，卻不喜歡「維護項目」。他們產出的代碼最大的問題就是維護較為困難，可能過上幾個月回頭看自己的代碼都會暈頭轉向。因此即使是自己寫的代碼，仍然不願意維護，一般會苦了後來人。
因為介面設計的缺乏，當需求變更時，發現代碼要改的東西太多，然後抱怨需求變化，卻很少認為是自己的代碼問題。這樣的項目如果經過長時間的變更維護，最終會變得難以維護（一般表現在需求變更響應時間越來越長）甚至無法維護，最終要麼是半死不活，要麼是被推倒重來。

5. 架構型
這類程序員比實現型更進一步，他們經驗豐富，對相關框架和工具等都很熟悉，「完成功能」「穩定性」「性能」這些已經不再是他們的追求，更優美的代碼、更合理的架構才是目標。
這類程序員介面設計大多建立在對需求變更的預測上，即靈活又不過度設計——可擴展性好；代碼細節也盡量多的考慮邊界情況、性能——穩定高效；代碼命名、注釋及邏輯分離都恰到好處，語義豐滿——可讀性較高；同時在開發過程中他們會不斷重構，對代碼做減法——保證項目可持續發展；等等。
但由於考慮問題較多，單從「實現功能」階段來看，完成速度不一定會比「實現型」要快。只是到了項目中後期優勢才會慢慢體現出來

也許還有更優秀的程序員我沒有見過，呵呵，歡迎大家補充

在我看來，沒有優秀程序員和一般程序員，只有程序員和碼農。

如果按排名第一的 @郭凜的答案來分類，那就是5是程序員，1234是碼農。

舉個栗子：

A：對於我們這種需要多方合作的項目，還是用git比較方便管理。
B：svn很牛逼的！我用了很多年了！
A：git的分支很方便，合併操作相當簡潔且沒有負擔。
B：svn也有分支！百度上說svn更適合企業！
A：git只有一個.git目錄來管理所有版本，在排除的時候很方便！
B：svn現在也支持單 .svn目錄了！

再舉個栗子：

A：為什麼我們網站的根目錄下面還有個.settings和.project文件夾？
B：我上傳時候直接用flashfxp一拖就上來了，沒看有什麼文件夾。
A：為什麼我剛才pull之後在項目庫下面多了個未命名.txt 文件？
B：嗯，那是我自己做筆記備份用的。

三舉個栗子：

A：為什麼Hero這個類有1萬行？
B：我覺得把所有功能寫在一個類裡面很方便啊！
A：為什麼這段代碼複製了4次？封裝成函數啊！
B：啊！有么？
A：這幾個類為什麼不用適配器模式？
B：什麼是適配器模式？

最後舉個栗子：

B：怎麼加一個Sprite到Node中？
A：Node.addChild(Sprite)
B：我要在加的時候設置層級關係！
A：RTFM！

碼農真正意識（而不是調侃）到自己是碼農的時候，TA才可能成為一個程序員。

而當TA成為一個程序員的時候，TA才有資格站在山腳下，憧憬著那那高聳入雲的峰頂，開始攀登。

同樣是程序員，優秀的程序員和一般的程序員差別在哪？

從以下幾點來談談差別：

1.思路
編程思路，是系統的計劃和設想，是程序員寫程序時的條理和線索。優秀的思路背後一定是不斷的積累。在熟知編程基礎的前提下，優秀的程序員會積累儘可能多的經驗，這份經驗讓他們更快的得出更好的思路。

2.解決問題的能力
解決問題的能力不是與生俱來的，還是要靠後天的經驗積累。在寫代碼的時候會遇到各種各樣的bug，優秀的程序員第一反應總是自己嘗試去解決這個問題，首先確定這個問題，根據運行時產生的崩潰信息或者編譯時出現的編譯錯誤，找到錯誤的根源。關於各類問題的解決，解決辦法總是能找到，只要願意主動尋求解決方案。

3.代碼優化能力
一般的程序員寫一個方法可能有幾百行代碼，寫一個類就想把所有功能實現，不考慮程序設計原則，也不考慮執行效率，更不去想如何讓我的程序質量更好。「代碼可運行」對一個優秀的程序員來說絕不是結束，而是開始。比如對於優化C語言來說，要選擇合適的演算法和數據結構、減少運算的強度等。優秀的程序員一定熟知各種演算法和數據結構，會靈活運用，致力於寫出更簡單、效率更高的程序。

4.全局掌握
優秀的程序員有意識地知道自己不應該再局限於簡單的技術問題，他們追求從全局上把握和設計一個較大的系統體系結構，從內核到外層界面，使用已掌握的技能解決問題，並且能夠考慮到系統的擴展性、安全性、穩定性等問題。

5.學習先進的技術
一般的程序員到達一定境界後很難有突破。現狀會讓他們不自覺的產生編程無非如此的錯誤觀念。優秀的程序員看到世界最新技術就能馬上主動去了解、去學習並且掌握。計算機技術每經過幾年就會有一個質的飛躍。一旦脫離技術潮流，就很難趕上。優秀的程序員跟上每一步技術，在這個領域看得更遠，思維越開闊。

6.耐心
假如使一個程序實現某種功能有很多種方法，但在這些方法中，只有一兩種方法是最好的，優秀的程序員會花時間實踐，實踐後總結出那一兩種最好的方法。所以，要寫一個好程序是很需要耐心的，要成為一個優秀的程序員也是。

歡迎關注我的微信公眾號：九章演算法（ninechapter）,幫助你了解IT技術前沿，通過面試、拿到offer、找到好工作！

我覺得好程序員的標準：
1、要懂邏輯，這點其實挺難達到，很多很不錯的程序員其實邏輯能力不行，所以我覺得限制了他們更深一層次的發展。或者說限制了他們解決特別複雜問題的能力。
2、要有分析能力。這也是解決複雜問題不可或缺的能力。
3、要會自學，技術發展速度很快，如果沒有自學能力會被淘汰的。所以在中國英語要好，不然看不懂最新的技術走向。
4、要有良好的時間管理習慣和意識。
5、要有耐心，肯於付出。
6、要有良好的工作習慣。
7、會看且勤於看文檔。

我自己很多點都達不到，但是希望能努力，慢慢達到吧。

優秀的程序員寫的代碼極其優雅（少而精鍊，不多不少）
他們喜歡思考（生活和代碼的世界其實是相通的）
他們知道，他們寫代碼，不單單只是為了實現功能，更是為了解決用戶問題，實現價值。

最近看了一些關於程序員的職業發展思考的文章，然後聽了場公司一個寫了10年代碼的程序員的培訓，工作後也和蠻多的程序員合作過,程序員的自我修養如何修鍊，才能有比較好的職業發展路徑，站在PM的角度談下自己的想法僅供參考：
1.事情做得專業的前提是能關注到細節
我覺得細心謹慎是程序員最基本的修養和素質，邏輯能力啥的倒是更為上一層的事情。整天想好的演算法和架構是沒有用的，你知道當你跟產品經理說解了半天的bug是因為少了個分號的時候，產品經理心中鄙視的是多麼的波濤洶湧么。
如果連這些代碼基本的細節都不能注意的話，談何其他呢
2.尊敬每一個人就像尊敬代碼一樣
很多程序員是傲嬌的，覺得產品就是自己做出來的，其他的人都是輔助的。所以很多程序員心裡是看不上產品，測試的，也就造成很多溝通障礙。
首先上面這種人一定一輩子只能寫代碼，哪怕技術再牛。
我不太認同寫代碼只能寫到30歲，但是程序員30歲之後，要想有更大的發展，那麼做團隊管理，要麼做技術諮詢，才能讓自己的能力和積累的經驗擴大化，那麼這個時候，卓越的溝通能力往往成為關鍵。
3.用經驗堆砌出你的產品技術全局觀
這個就涉及到架構方面，產品經理提出需求，不僅僅想聽到的是這個需求可以做還是不可以做這麼簡單，而是如果可以做，那麼開發成本是怎樣的，會對目前的系統產品模塊造成哪些影響，有哪些的risk，如果不可以做，有沒有好的替代方案或者簡化方案。
如果在需求評估的時候，PM可以得到這些答案，一定會跪舔你的
當然，另一方面，如果在前期評估中，這些都沒有想到的話，後期造成的種種後果也是需要程序員自己承擔的。
4.做好情緒管理
理論上，程序員都是冷靜的。但是現實中，情緒衝動的也是蠻多的，我不知道這樣的性格會對寫代碼有何影響，但是因為情緒影響了判斷就不好了，例如因為需求反覆修改就索性說這個代碼實現不了這種事情，終究會對自己的信譽造成很大影響的。這種事情我經常遇到。。。
5.技術要做到精益求精
編程語言那麼多，多語言的程序員雖然搶手，但是如果是半瓶水的水平，估計也是沒人願意要的。
現在程序員非常多，是因為這個行業入門的門檻非常低，也就造成行業的水平參差不齊。做一個網站很難么，找個現成的框架，懂點資料庫，建個數據表，前端再找個現成的模板，修修改改一個網站就出來了。
但是滿足這樣就完了？那麼水平可能永遠就是這樣了，其實這其中每一個點都是可以研究的很深的，比如網站的大數據存儲，如何提供程序並行運行的效率，，未來計算機行業的技術分工會越來越細，任何一個方面的專家都是相當有用的
6、職業規劃，其實你沒的選
聽一個前輩講，自己也對職業也很迷茫過，後來索性去創業了，但是失敗的一塌糊塗，最後才明白，自己最會的還是寫代碼，最懂的還是Java，有時候其實你沒的選
7.Stay hungry ，Stay Foolish
技術是永無止境的，好的程序員必須保持對於新的技術敏感度，保持學習的熱情
同時看書學習可以更多的得到思維模式，可以在最快的時間發現問題的所在
如果沒有好的思維模式，很多程序員遇到需求了，先百度，看看有沒有相似的代碼，遇到bug再去百度下，看看別人是怎麼解的，這種永遠只是碼農而已
聽說一本好的程序書籍至少要讀12遍才能理解。。。

推薦一位IT精英的博客，博客地址：

zhuweisky - 博客園

不為繁華易匠心

做技術是需要匠心的。什麼是匠心？我們原本是有匠心的，我們如今還有匠心嗎？我們為什麼沒有匠心了？為什麼我們要重拾匠心？如何重拾匠心？

一. 做技術是需要匠心的

中國古時的玉匠，切磋琢磨，用繩與砂漿，費數十載心力，終將渾然璞玉製成傳世珍品，千年遺音在，猶見當年寂寞心。

日本傳統的刀匠，將千錘百鍊之鋼反覆鍛鑿、淬火、打造、磨製，每一處技至精微，每一處心入幽明——刀中有魂！

歐洲中世紀的石匠，在哥特式教堂的飛檐上雕刻出了靈獸狀噴水嘴，雖不為世人所見，仍一絲不苟——每一鑿中都有天堂！

米蓋朗基羅花四年雕刻出了震驚世人的《大衛》，曹雪芹批閱十載創作出了藝術巔峰的《紅樓》——任何偉大的作品背後都有一顆匠心。

二. 什麼是匠心？

匠心是對於作品而言的。

匠心是傾注於作品之中的精神、情感、乃至魂魄。

匠心發自於愛，是對作品視如己出的拳拳之心，是恆久忍耐又有恩慈。

匠心是出於這份愛的對於完美的追求，是追求中不避艱苦，是追求中自得其樂。

匠心是涵泳在作品之中的自我實現，是我與作品的相互完成，彼此造就。

在匠心看來，作品是我的至親之物，棲居著我的精神，安放著我的靈魂。

匠心即是愛心 + 恆心 + 一片苦心 + 七竅玲瓏心 + 出離心 + 寂寞心 + 金剛心 + 歡喜心 + 其人雖已歿，千載有餘情。

三．我們原本是有匠心的

我們原本是有匠心的。

當年Ken Thompson 和 Dennis M.Ritchie 一起在貝爾實驗室里苦心孤詣。

如今，沒有人不知道Unix意味著什麼，C意味著什麼。

他們的匠心也彰顯在Unix和C中令無數人為之驚嘆、感懷。

四．我們如今還有匠心嗎？

如今，我們再也難得見到「作品」問世。

甚至於「產品」也是少見。見得最多的則是「商品」。

對於我們而言，做什麼東西並不重要，重要的是做這個掙不掙錢。於是我們沖著掙錢做了各種項目，C/S、B/S、前端、後端、資料庫、Java、.Net、安卓——彷彿無所不知，無所不曉，十年之後回首，覺得自己已然是全才。

我們從事了大量的勞動，寫了幾十萬行代碼。我們的工資越來越高，並為此沾沾自喜。

可是，這樣的成就，無非是一個熟練工人的成就。

我們何曾擁有匠心？

五．我們為什麼沒有匠心了？

隨著大生產時代的到來，那種田園詩般的男耕女織、帶月荷鋤歸的工作方式，早已一去不復返。社會分工越來越細碎化，我們面對的是一個又一個的局部。在這之中需要的是規格化、標準化、量化和同質化。換言之，你所做的工作必須是合乎統一規範的，具有統一規格的單元，如此才能拼接到整體的工作中。因此，任何的創造性，任何私人性質的感情和精神的注入，歸根到底，只是錯誤的根源。 ——我們於何處安放匠心？

如今，商品成為了一切物所具有的普遍的形式。沒有什麼不是商品。商品是以交換為目的的。我們生產任何勞務、產品、或服務，都是為了交換，為了換取一般等價物，即貨幣，即金錢。因此，錢成為了衡量一切的準繩。如今不乏偉大的商品誕生，可是偉大的作品卻乏善可陳。商品需要的是批量生產，需要對消費者投其所好，當然商品也需要創意，可是那不是匠心！在一個由商品拜物教統治的時代，我們於何處安放匠心？

世界如此繁華，匠心未免太奢侈了！我們在喧嘩與騷動中度日，有太多的追求，太多的比較，太多的你追我趕，太多的惶惶終日。每天有看不完的新聞，刷不完的微博，做不完的手頭工作。我們為無盡的事情發愁，疲於奔命。匠心未免太奢侈了！早在我們出生的那一刻，我們就開始照著大家來活，大家都在讀書，大家都在考學，大家都在找工作，大家都在結婚，大家都在買房，大家都在炒股，當我們跟著大家忙忙碌碌的時候，匠心自始就已沉淪！

六．為什麼我們要重拾匠心？

假使我們沒有匠心，我們將不會在工作中獲得真正的快樂。因為我們不能自覺自由地工作，我們的工作是boss定義的，而不是自己定義的。如此一來，我們就與我們的勞動之間切斷了血肉聯繫。我們的勞動成為了壓迫我們、奴役我們的異己力量。我們淪為被迫勞動。我們真正的生活在下班之後開始。我們不停地抱怨：要不是為了幾個臭錢，我才不要干這些。如何才能回歸到那種田園詩般的勞作之中——我們必須重拾匠心！

唯有在擁有匠心之後，我們才能走向真正的自我實現。馬斯洛將人的最高層次的需求定義為自我實現。一個自我實現的人，一個將自己的才能發揮到最大限度的人，才是那個獲得最大心理滿足的人。現實生活中唯有少數精英才能夠成為自我實現人。但是這並不妨礙我們追求自我實現。一個有著庸碌之心的人，是不可能走向自我實現的。唯有重拾匠心，我們才能佔有工作的全部意義，才能不避艱苦、精益求精，與自己的作品相互完成，彼此造就。

七．如何重拾匠心？

對於如何重拾匠心的問題，恐怕要留給每一個人來思考。而且是一個需要始終思考的問題。

在這裡我並不想給出答案。

只希望能在這篇文章中能夠看見你，看見我，看見大家。

能見眾生便是如來，不易匠心方得始終。

參考閱讀：

程序員的出路之一

——————————————————————————————————

優秀的程序員是PM+程序員，普通的就只是程序員。中間是一個PM的差距。

懶惰、缺乏耐性、傲慢，是程序員的三大美德

http://c2.com/cgi/wiki?LazinessImpatienceHubris

優秀的程序員是一個善於和產品溝通的人，能知道為什麼要這樣做並能提出合理建議以及準確實現功能需求

通常在於把職場和生活中的事情做到極致的能力。我多年的實踐表明，只要你能把一個乃至若干個通常的技術做法推進到極致，並能給企業帶來價值，那麼無論你是多大年紀，你已經獲得了職場的主動權。

【太長不讀版】

「把通常的做法推進到極致」，這個來自極限編程的準則，能解決程序員在職場和生活中所面臨的種種問題，並且能把其在職場和生活中的體驗帶到極致。

要想把事情做到極致，需要「戒貪、專註和反饋」的心態。

【完整版】

「在不同公司做技術的感受有何不同？」

「你為何搞編程道場？」

「靠技術吃飯在職場到底能走多遠？」

「工程師嚮往的到底是什麼樣的文化？」

「如果職業生涯再來一遍，你會怎麼規劃？」

「一些企業開始『優化』35歲以上的員工，技術人如何應對這種35歲現象的挑戰？」

最近我在思考身邊朋友所提出的上述問題。

回首工作過的24年，我最初從程序員開始做起，後來轉為測試工程師，又轉為項目經理，最後轉為現在的軟體開發諮詢師，先後經歷了4個角色。所服務的公司從國企開始，轉為若干外企和私企，最後又轉為現在的外企，先後經歷了6家公司。

現在所從事的軟體開發諮詢工作，雖然不再編寫大量的代碼，但所涉及的內容都是與軟體開發技術有關，所以還算是技術人一枚。如今，這枚技術人已經47歲，超過上面提到的35歲一輪了。

我在2016年拿到Scrum Master和PO的認證後，就去ThoughtWorks的印度辦公室做ThoughtWorks University的新講師，輔導公司新入職的應屆畢業生做軟體開發項目。期間我問指導我們這些新講師的老講師Susie Marshall：「在ThoughtWorks做開發，是否有Scrum Master？」

她說：「沒有。在ThoughtWorks開發團隊中，任何人都可以認領Scrum Master應做的事情。咱們更像是在做極限編程。」

極限編程是美國程序員Kent Beck在1999年提出的一種軟體開發方法。它的核心理念就是「把通常的軟體開發的做法推進到極致」，以便讓軟體開發能夠達到低成本、低缺陷、高產出、高回報的效果。這也是這種方法名字中「極限」的由來。

根據24年的實踐經驗，我領悟到，「把通常的做法推進到極致」這條來自極限編程的準則，不僅幫助很多ThoughtWorker實現了"追求軟體卓越」，比如推出了第一個持續集成工具Cruise Control，並撰寫了《持續集成》這本經典之作，還能解決程序員在職場和生活中所面臨的上述問題，並且能把其在職場和生活中的體驗帶到極致。

這種方法把什麼做到極限了呢？比如，在軟體開發中，測試是一個通常的做法，一般都會在程序員編寫完代碼後，由測試工程師來進行測試。Beck把測試這個通常的做法往前推，即在程序員編寫代碼前，先編寫單元測試代碼，然後再編寫生產代碼，讓測試運行通過。這樣就把測試推進到極致，能讓程序員通過自動化單元測試更快發現自己的代碼是否有功能性缺陷。

再比如，在軟體開發中，代碼審查也是一個通常的做法，一般會在程序員編寫完代碼後，由一兩位資深程序員來審議代碼的質量。Beck把代碼審查這個做法再往前推，即在程序員編寫代碼前，再另外找一個程序員和他結對編程，在編寫代碼的過程中隨時做代碼審查。兩人在結對編程過程中，還能互換角色，相互做代碼審查。這樣就把代碼審查推進到極致，能讓程序員在結對編程中更快地發現自己的代碼是否有問題。

再比如，軟體開發一般需要把一個大系統分解為若干模塊，每個模塊分別開發。等各個模塊完成代碼編寫後，再做集成測試。Beck把集成測試這個做法往前推，即在編寫代碼的過程中，每過幾小時就要進行一次自動化的集成測試，把集成測試推進到極致，能讓程序員通過自動化集成測試更快地發現自己的代碼是否有集成的缺陷。

「把通常的做法推進到極致」的準則，如果運用到軟體開發中，就是極限編程。如果運用到日常生活中，就是極限生活。

有人會問，」這和工匠精神是不是一樣？「我認為兩者還是有一些差異的。工匠精神一般指把一門手藝做到精益求精、盡善盡美。其中的那門「手藝」一般不是普通人所能掌握的。比如做拉麵、做辣醬、做鎚子手機，普通人都做不來。而「極限生活」中的「通常的做法」，都是普通人能做的。比如上面提到的「測試」、「代碼審查」和「集成測試」，普通軟體開發人員都能做。下面將提到的「吃得好」和「珍惜時間」，普通人也能做到。

極限編程中所描述的種種極致的做法，能讓軟體開發達到低成本、低缺陷、高產出、高回報的極致效果。那麼極限生活也能達到這樣的極致效果嗎？

根據我最近5年的親身實踐，答案是肯定的。比如，「吃得好、吃得精、活動少」所造成的營養過剩是許多人所面臨的問題。身高180厘米的我5年前體重曾經達到85公斤，腰圍達到二尺八。後來我把「吃得好和吃得精」向反面推進到極致，改為吃素，是那種能吃「肉邊菜」的方便素，不會麻煩身邊的人。5年堅持下來，體重能夠控制在75公斤左右，腰圍減到二尺五，同時也修鍊了下面要提到的「戒貪」的心態，情緒變得更加平和。

再比如，很多人都在感慨「時間都去哪了？」，會在上下班的地鐵里珍惜時間來看書。我在聽了吳伯凡老師在《得到》App直播中介紹的柳比歇夫的《奇特的一生》一書之後，仿效柳比歇夫，從2017年4月24日開始，每天記時間開銷日記。每件事情的耗時精確到分鐘，將珍惜時間推進到極致。至今兩個月做下來，我知道如果在北京平均每天用在上下班的時間是兩個半小時，每日平均睡眠大概是七個半小時，寫這篇博客總共花了7小時40分鐘。我知道每天的時間都去哪了，今後要在哪裡節省時間。這種珍惜時間的極致體驗讓我感覺活得很踏實。

要想做到「把通常的做法推進到極致」，需要下面的心態。

戒貪

貪心會耗散你寶貴的注意力，讓你分辨不出哪個通常的做法值得被推進到極致。比如我在20多年前在國營單位做IT人員的時候，雖然早已發現這個單位並不適合我的個人發展，但是當時貪圖國營單位的穩定，在這個單位糾結了7年多才提出辭職。那時一個人如果從國營單位辭職就會被稱為「下海」。我在下海前這7年多的時間裡，在貪圖安逸的心態下，從沒有將哪個通常的做法推進到極致，導致下海後一無所長，很長一段時間難以找到稱心的工作。

專註

沒有了貪心，就能靜下心來發現自己的一個喜好和優勢。然後在這個點上專註下去，把它做到極致，實現單點突破。比如，我在3年前用裸辭來戒貪，決定要找到一件值得專註的事情。在讀書的過程中，我發現「編程操練」是程序員刻意練習編程的好辦法。於是就專註於這個點，把這種做法向前推進到極致。我找到一些願意免費提供場地的公司，辦了30多次免費的線下「編程道場」活動。這些經歷讓我通過編程掌握了不少設計模式和測試驅動開發方法，促使我完成了《馴服爛代碼》的寫作並出版，並在編程道場中結識了不少好友，有些好友成為了我軟體開發諮詢的客戶。戒貪之後的專註，令我有機會將編程道場做到了極致。

反饋

在「把通常的做法推進到極致」的過程中，你的做法並不一定都是正確的。需要不斷收集反饋，並持續調整。比如我最初在撰寫《馴服爛代碼》的第一章時，使用了類似幾何學的邏輯推導的方法來論述測試驅動方法的有效性。將草稿發給機械工業出版社的楊福川老師審閱後，得到了「難以閱讀」的反饋。這個反饋促使我開始思考如何才能以吸引讀者的方式來組織該書內容。

我受上面提到的編程道場匠友們的反饋的啟發，最後把書的內容演進成寫兩位程序員用結對編程的方式來進行編程操練。該書出版兩年後，得知參加編程道場的中國礦業大學的劉凱欣同學把編程操練推薦給了她的朱老師，並促成學校開始了敏捷軟體開發的課程，這令我大為欣喜。上面所說的這些反饋，都幫助我將寫書做到極致。

「把通常的做法推進到極致」，用在軟體開發中，就是極限編程。用在生活中，就是極限生活。現在看看本文開頭的那些問題是否能用極限編程和極限生活來解決。

「在不同公司做技術的感受有何不同？」

我如今在ThoughtWorks公司做技術，能夠實現「把通常的做法推進到極致」，比如測試先行、持續集成和結對編程，這是一種極致的體驗，是最大的福利。我以前所在的其他公司，都沒有這個福利。

「你為何搞編程道場？」

開始是為了寫書。現在想來，是在實踐」極限生活「。

「工程師嚮往的到底是什麼樣的文化？」

我嚮往極限編程和極限生活的文化。

「如果職業生涯再來一遍，你怎麼規劃？」

首先建立「戒貪、專註和反饋」的心態，然後持續地做出「把通常的做法推進到極致」的職業規劃。

「一些企業開始『優化』35歲以上的員工，技術人如何應對這種35歲現象的挑戰？」「靠技術吃飯在職場到底能走多遠？」

我多年的實踐表明，只要你能把一個乃至若干個通常的技術做法推進到極致，並能給企業帶來價值，那麼無論你是多大年紀，你已經獲得了職場的主動權。

文／ ThoughtWorks 伍斌來源：極限編程與極限生活

優秀的程序員，會盡量避免犯這篇文章里提到的這些錯誤：

苦果：像專家一樣思考，像外行一樣實踐

周鴻禕寫過一篇文章：以色列軍隊是世界上最好的孵化器

文中提到：以色列軍隊中有一種很特別的現象，基礎訓練給所有士兵設定了許多必須服從的條條框框。但當你成為一名下級軍官以後，就需要學會自己思考解決問題。另外，即使基礎訓練使你具備了執行任務的基本條件，但要完成任務，必須要發揮自己的創造力。

不少人會看重上面這段話後面提到的創造力，在這裡我感觸更深的是「基礎訓練給所有士兵設定了許多必須服從的條條框框」這句話——這說明先約束、先有諸多規矩，是日後能發揮創造力的基礎，這和我們中國練書法要求先一絲不苟練習楷書，到有一定基礎了才能修習行書乃至草書是一個道理。

在中國IT行業的「好工程師」應該是什麼樣的？有哪些客觀標準可供自我評估？這個回答中，列出了軟體工程師能力自我評價表（37條）。優秀還是一般，看看37條做到了多少。

在構建之法——現代軟體工程這本書的第三章軟體工程師的成長里，作者寫了一節技能的反面：

推薦：來吧，IT小小鳥（持續不定期更新）

優秀程序猿和普通程序猿相比，他們可以在高強度的壓力下仍然快速寫出高質量的代碼

我覺得真正的牛人：

1，能多分析著名軟體的架構，比如 linux kernel, glusterfs, moosefs, dhfs, nginx等等，最好多看看源代碼；

2，能多研究底層細節；比如GNU系列工具，C/C++語法細節

3，多寫代碼，尤其是能吸收開源軟體中的好想法；

先到這

兩個字足以說明「喜歡」

優秀程序員至少包含如下特性：

一個健康的身體。健康的體魄是優秀程序員的必備基礎，趕緊鍛煉去，別擼了。
持續學習的能力，跟上節奏。發現身邊還有不知道Python是什麼的程序員，你敢說他能優秀起來？
能讀懂自己代碼的能力（什麼，自己寫的代碼讀不懂？很多時候一般程序員讀不懂自己半年前寫的代碼，所以寫代碼的時候要儘可能以簡單易懂的方式來編寫，還要有一顆重構的心）
把編程當生活的一部分（優秀與一般區別在於下班幹什麼）
不裝逼（裝逼遭雷劈），優秀程序員並不等於是每個領域都很牛逼的程序員，不懂就不要裝了

原文：優秀程序員與普通程序員在行為上的差別-博客-雲棲社區-阿里雲

優秀程序員的行為：

拿到任務，就開始仰望星空或天花板上那盞高懸的電燈棒，狀如老僧入定
忽而皺眉，忽而展顏一笑，忽而手舞足蹈，忽而在紙上指指戳戳，忽而口中念念有詞，忽而長吁……感覺有點神經病啊
桌子上擺的是代碼大全、設計模式、敏捷實踐之類的書籍，並且沒有灰塵
chrome或firefox的書籤欄里分門別類，類別多於10個，8個以上是技術相關的
容不得破窗戶，看見別人的爛代碼就想改過來
隨手就能在白板上畫出軟體的流程圖或者時序圖……
項目做完了，別人在打遊戲、看視頻、忙著回復QQ、向剁手族前進，他在想：這樣重構好呢，還是那樣……
你發現他總能說出些你不知道的技術來……
看這廝的代碼比看你自己的還好懂……
老得你叫他吃飯……

普通程序員的行為：

拿到任務就開始噼里啪啦敲鍵盤，一天寫了好幾千行代碼
沒事兒就被測試MM叫過去溝通……
都早上10點多了還想著昨晚的球賽，10點半就琢磨中午要吃拉麵、扯麵、刀削麵、牛肉麵、旗花面、臊子面、窩窩面還是炒細面……
過了一陣子，看到自己的代碼，感到很驚奇，認為是別人寫的……
回家就看電視、打遊戲、看球賽
周一上班不知道要幹啥，遲遲進入不了角色
哇，能Run啦，搞定啦
這誰寫的代碼，這麼爛……算了，管它
問別人問題的時候多，別人請教你的時候少
世界上最遙遠的距離不是生與死，而是你親手製造的 BUG 就在你眼前，你卻怎麼都找不到她……

作者：阿里云云棲社區 - 知乎

著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。

親們阿里云云棲社區已開通專欄，歡迎關注閱讀：我是程序員 - 知乎專欄

本質區別是能否：從人的角度理解問題（需求）-&>從人和計算機的角度思考問題（設計）-&>從計算機角度解決問題（實現）。

把上述每個子句中的"角度"的定語（人、計算機）不同方式排序組合一下即是各種不同類型的程序員。

優秀程序員：
0. 喜歡，任何年齡段都能拿到不低於同齡人還算體面的薪酬
1. 保持一定的手速和代碼出貨量，持續寫，10年、20年、40年...
2. 罵自己之前寫的老代碼，參與設計、架構