標題說的有點玄乎，在網上看到的1篇文章，提到了1些大牛具有的幾種素質（或說應當養成的習慣），值得反思。

　　部份原文以下：

　　為了了解那些大神級程序員和普通程序員的區分，采訪了很多世界高端科技公司的軟件工程師。發現這些給世界帶來巨大影響的的工程師們最少有以下幾個共同的思惟模式：

勇于去研究自己不懂或不熟習的代碼

　　1般程序員都不愿意去研究自己不曾接觸過的代碼，很多人都沒有嘗試就放棄了。如果你常常去研究你沒有接觸過的代碼，你就會愈來愈熟習不同的代碼結構和設計模式。現在程序員很容易就接觸到優良的開源代碼資源，可以很方便的就下載下來做1些改動或調試，去研究為何代碼可以這么寫。

　　除代碼以外，很多人對陌生的工作內容也會感到抵牾。每次換工作的時候，可能都會遇到新公司的工作內容和之前工作的內容不1樣的情況，以致于剛開始的時候，工作效力沒有之前那末高。

　　其實，所有程序員都是在學習的進程中成長的。在1個陌生的領域，沒有人可以從1開始就是大神。如果你想在你工作的領域，變得愈來愈強，不管是寫代碼，或是與人溝通或其它的技能，都是需要投入大量時間去學習的。

精通代碼調試

　　很多人在寫代碼的進程中，常常會有的1個問題就是：為何寫出來的代碼不能運行？為何運行的結果不是我想要看到的？

　　幾近所有的程序員在寫代碼娿進程中，都不是1遍就可以寫好的。但是大神級的程序員會很快的就明白自己代碼的問題。這是1個很重要的能力，需要在工作中日積月累。那末怎樣去調試好代碼呢？以下幾個方法，看文章的你可以鑒戒下：

　　1.無妨先猜想1下到底產生了甚么。

　　2.假定你的猜想是對的，想一想你的猜想會致使程序有甚么樣結果。

　　3.試著視察這些結果有無異常的地方。

　　4.如果你沒有發現異常，那末說明你的猜想就是對的。

　　5.如果你發現了異常，那末說明你的猜想是錯的，接下來換1個猜想試試。

　　對大神級程序員來講，這個進程在腦海中就是電光火石的1瞬間。只要你解決的問題足夠多，你做出來的猜想就會越準確。

　　至于如何發現異常？就需要有1套屬于自己的工具或方法了。最簡單的就是在代碼里輸出日志來判斷。但是這是比較笨的辦法，需要去接觸1些高級的工具或直接帶有Debug功能的編輯器。

重視能夠節儉時間的工具

　　最近打敗人類的AlphaGo（阿爾法）每天可以進行上百萬局的下棋訓練，人類1萬個小時的訓練卻需要10年之久。也就是說，電腦運行幾分鐘，可能就等于人類工作好幾年。這么1比，人力的思惟好渺小。。。

　　高效力的程序員都把時間花在制作工具上，很多程序員也認為工具是很重要的，但是他們并沒有花時間去制作、整合自己的工具。但是，團隊最出色的員工會耗費了他1/3的時間在工具制作上，這些工具可以用來發布代碼，監控系統，和能讓他們花更少的時間去做更多事情。

　　總之，不要花時間去做沒成心義的事情。

優化你的迭代速度

　　假定1下你要花12秒鐘去搜索某個函數是在哪里定義的。再假定你每天做這個動作60次，那末你每天就要花12分鐘去搜索函數定義。

　　如果你用1個好1點的編輯器，每次找到函數定義只要2秒鐘，那末你每天就會節儉10分鐘。每一年你就能夠節儉40個小時。

　　如果你能找到3個這樣的場景去優化1下，那末你每一年可以節儉1個月的時間，想一想這1個月你可以做多少成心義的事情啊。

　　再假設你在調試1個App的毛病的時候，改完1次代碼都需要重啟1下App，然后點擊4、5次才能看到毛病有無改好。那末你是否是可以先花幾分鐘設置以下，讓App1啟動就轉到顯示毛病的頁面呢？

　　所以千萬不要小視這些瑣碎的細節，改良它們對你的回報是巨大，細節決定成敗啊。

系統性的思考方式

　　當你在寫代碼的時候，很容易就認為只需要依照需求實現了指定的功能，這個代碼就能夠算是寫完了。但是這其實只是滄海1粟。任何沒有發布到生產環境的代碼都不會產生任何價值的。

　　如果想寫出真正有影響力的代碼，需要從全部系統去理解屬于你的工作：

　　1.你的代碼和其他人寫的代碼在功能上是甚么關系？

　　2.你有無好好測試你的代碼？或其他人是不是很容易測試你的代碼？

　　3.為了部署你的代碼，線上生產環境的代碼是否是需要改動？

　　4.新的代碼會不會影響到已運行的代碼？

　　5.在新的功能下，你的目標用戶的行動是否是你所期望的？

　　6.你的代碼有無產生商業上的影響？

　　這些問題都不是很容易就可以回答的，但是在寫代碼的時候，你需要明白你的代碼最后會不會得到你想要的結果。

　　上面談到的幾點，很容易就能夠想到，但是你做到了嗎？

　　共勉。