2020年由於疫情的影響，大批次的公司破產倒閉，即使能堅持下來的，也是推出了很多財務削減和人員裁減計劃（也有美名為人員最佳化），這導致了大量人員的失業，當然也包括了我們這些做開發的程式猿。

疫情時間，為了能快速找到工作，很多人又開始四處尋找面試材料複習開始備戰面試，但就在複習的過程中有些人可能會發現，原來自己工作了這麼多年，水平可能都不及一個擁有三年開發經驗的新人。

那麼問題來了，同樣是開發，為什麼你不如別人？如何才能讓自己變得更加優秀？下面我將從三個方面闡述我的思考。

一、做事的藝術

在工作中，我們可能會碰到各種各樣的問題，如何優雅地處理這些事情，非常考驗一個人的能力。

1.嚴謹和一絲不苟的態度

有人經常這樣向我抱怨：面試造火箭大炮，工作擰螺絲。我想即便你是擰螺絲的工作，也務必要保持一絲不苟的態度把這擰螺絲的工作做好，否則你的這步沒能擰好，很有可能導致造出來的整個火箭還沒飛上天就爆炸了。

我覺得幹咱們研發這一行，嚴謹和一絲不苟的態度是必須具備的基本職業素養。因為可能就是你的一點小疏忽或者情況考慮不周，可能給別人帶來多大的麻煩和後果。

可能一、兩次地這樣坑別人，別人還能原諒你，幫你填坑。但如果由於你的不嚴謹和不認真的態度，導致三番五次地坑別人，時間長了即便你人再好，別人也不會再相信你，這樣你在團隊中就舉步維艱了。

2.把握問題的本質

在工作的時候，我們經常會遇到各種各樣的奇怪的bug。面對這些bug，不同的人處理的方式也是不盡相同。有的人是恨得咬牙切齒，恨不得和提bug的人幹一架；有的人則是非常淡定，一邊詢問bug的詳細情況，一邊靜靜地坐著打斷點、打日誌分析問題。兩者處理的方式不同，帶來的結果也不盡相同。

那麼當我們在開發過程中遇到問題時，我們該如何解決呢？我想核心的解決方法就是 把握問題的本質。

如何把握問題的本質，以下是我常用的方法論供大家參考：

瞭解問題的詳細情況，收集問題出現的條件和現象：只有瞭解問題才能解決問題；模擬問題出現的場景，對問題進行場景復現；將偶現問題轉化為必現問題，從中尋找規律；善用排除法，篩除干擾項； 斷點+日誌相結合進行問題跟蹤，深入原始碼探尋問題的本質。

一旦把握了問題的本質之後，一切便會迎刃而解。後面你需要做的就是找到方法，並解決它。你可以自己想辦法；搜尋網上有沒有人和你遇到同樣的問題；請教這方面熟悉的人...

3.事前永遠比事後更重要

事前埋下的坑，也許需要事後付出數倍的努力才能把坑填完。很多時候我們經常會忽視事前計劃、設計的重要性，往往是走一步看一步，等功能實現到一半的時候才突然發現這條路越走越崎嶇或者根本行不通，這個時候你是非常難受的。

繼續走下去，可能前面的坑會越來越多；不繼續走，重新想方案，專案延期，進度趕不上，要被問責。

因此在做任何事前之前，一定要自己要做的事情想清楚了再去做，避免南轅北轍的尷尬。

以下是我給出的幾點建議：

在做一些較為複雜的功能前，儘量做好設計。這裡的設計主要包括： 流程圖：把所有可能出現的情況都考慮進去，越詳細越好； 設計類圖：包括UML圖和時序圖等。好的設計往往事半功倍，這裡我推薦大家多學學設計模式； 效能設計和可拓展設計。養成良好的編碼規範，在關鍵的、難懂的地方多加些註釋，這樣可以避免長時間後的遺忘，導致程式碼晦澀難懂，大大增加維護難道和bug產生的機率。提高程式碼的質量，在實現功能的同時，注重程式碼的效能，對於一些常見的效能問題要爛熟於心。在問題出現任何端倪之前就立馬進行解決，即使不能完全解決也要預先想出替代方案。否則時間長了或者上線了之後，你可能需要付出數倍的精力才能解決，並有可能帶來非常不好的影響。

4.低調做人高調做事

Talk is cheap. Show me the code.這句話可謂是IT圈裡最朗朗上口的一句話。

咱們幹研發這一行的不同於其他職業，並不需要極力向外推銷自己來獲取更高的業績。我們絕大多數的研發人員都是務實派，靠的是一行一行碼出來的程式碼去實現自己的價值，少說話多敲幾行程式碼會更有價值得多。

我們做技術的不要成天拿著技術出來顯擺。要知道人外有人天外有天，比你技術牛逼的大有人在，沒必要整天要在技術上比個高低貴賤的，也不需要刻意讓別人知道自己有多麼厲害，因為你寫的程式碼就能證明你的技術水平，時間一長大家自然心知肚明。

5.幫助別人的藝術

在幫助別人的同時，還能讓自己對這塊的技術掌握得更加透徹，何樂而不為呢？

幫助別人，而不是施捨，這一點尤為重要。我們要樂於助人，但是也要注重方法。幫助他人是建立在相互尊重的基礎上的，否則你的好心幫助會被別人理解為同情施捨或者多管閒事。

因此我們在幫助別人的時候要注意以下幾點：

不要有幫助人的企圖，只有在別人需要幫助的時候才去伸出援助之手；給予被幫助人最起碼的的尊重；不要藉著幫助他人的名義去幹預被幫助人的成長，最好的幫助就是點到即止，剩下的順其自然。

二、學習的藝術

從事開發工作，無論你是在產品線上寫業務程式碼，還是在技術平臺進行技術研究，我們都不能放棄學習，放棄對新技術的嘗試。放棄學習就好比戰士上戰場弄丟了自己的槍，很快你將會被一浪又一浪的技術浪潮所淘汰。

1.學習和汲取他人的長處

對於大多數的人來說，發現別人的缺點很容易，但是發現別人的優點卻很難，這也是很多人不能快速成長的原因所在。

優秀的人總是善於發現別人的優點並加以學習。學習、模仿並最終超越是他們戰無不勝的秘訣。他們並不在於你身上有多少缺點，他們只在乎能從你身上學到多少東西。

他們不僅會向身邊的人學習，還會向以下幾個方面進行學習：

優秀的原始碼。這裡包括系統原始碼和優秀的開源專案原始碼；優秀的技術書籍、文章；優秀的理念和思想。

2.把握學習的廣度和深度

漫無目的地學習必然導致效率的極其低下，我們在學習之前一定要給自己設定一個目標：到底是想學習不同領域額的技能，成為一名全才；還是想就某一領域深入研究，成為一名專才，這就涉及到學習的廣度和深度的選擇了。

因為你不同的選擇可能導致不同的人生軌跡，就目前而言，大廠更偏向於某一領域的專才，而小廠更偏向於擁有更多技能的全才，當然這也不是那麼絕對。就選擇而言，大廠固然很好，但是又有多少人能進入大廠呢；小廠雖說待遇各方面都不敵大廠，但是小廠的機遇多啊，說不定哪天公司發展得不錯，你就能爬上領導的位置了呢。

所以無論你是選擇學習的廣度還是學習的深度，其實都是沒有錯的，唯一錯的就是你壓根就沒有思考過這事。

當然這裡的選擇也不是絕對的，每個人在不同的階段可能選擇的方向並不相同。當你初涉社會剛開始工作，你可能追求的是學習的廣度，但慢慢的當你對某一領域感興趣或者表現出異於常人的天賦時，你可能又會轉而追求學習的深度。

每個人的技術都有可能在某一刻達到瓶頸。如果現在的你翻開一年前你提交的程式碼，卻發現和你現在提交的程式碼並無差別時，這個時候你就要小心了，很可能你已經達到你的技術瓶頸了，這個時候考慮換一個學習的緯度可能是不錯的選擇。

3.持續不斷地學習

技術在日新月異地不斷變化和發展著，前幾年還比較流行的技術，可能沒過幾年就被人們所拋棄。當革命性的突破技術取代舊的技術時，這是歷史巨輪不斷向前發展、不可阻擋的趨勢。

不要以為你現在掌握的技術就能夠養活你一輩子，我們需要對技術的發展保持著極大的敏銳觸覺。一旦你所掌握的技術逐漸被新技術所替代時，你就要小心了，可能留給你學習的時間不多了。

4.利用好學習的工具

利用好學習的工具，能夠極大地提高我們的學習效率。

這裡我主要介紹關於自學一門技術可以利用的工具：

專業性的入門書籍。對於新手和小白而言，我還是建議大家先找幾本專業性和權威性最強的書籍作為自己的入門指南。因為書本講解得更詳細也更成體系，對於入門而言還是相當不錯的。專業領域較強的技術論壇和部落格。在這裡我們可以學到很多書本上所沒有的一些前沿技術的資訊和技術交流心得。這裡推薦掘金和思否。開原始碼託管平臺。在上面擁有海量開源的專案，其中也不乏許多優秀的開源專案可以供我們學習和參考。學習和借鑑別人優秀的程式碼和設計思想，能讓我們快速提高自我的coding能力。這裡我主要推薦Github和Gitee。關於如何使用開原始碼託管平臺，可以參考我之前寫的一篇文章：《你真的會使用github嗎？》。

三、提問的藝術

我們每個人都不是萬能的，都會遇到很多我們不懂的問題，需要向別人進行求助。但是並不是每個人的問題都能夠得到別人的答覆，這完全取決於提問者提問的水平。

這裡我先模擬一個場景：當你在github上使用了某人開源的輪子時，遇到了問題需要向作者提問或者提issue，你會怎樣進行提問？

提問者A：大佬幫幫忙，我在使用xxx的使用遇到問題了，請問怎麼解決啊？提問者B：老哥，我說xxx小白，在使用你的xxxx搞了一天了都沒有執行得起來，能不能幫幫忙，我實在沒辦法了。提問者D：請問怎麼解決，......（以下省略數百行的日誌）提問者E：你這xxx根本不能用，......（以下省略約一百字的抱怨的話）提問者F：您好，我在使用xxx的xxx版本的時候，遇到了xxx問題。下面是我出現問題時的現象（....)以及日誌(....)。我是這樣xxx,然後xxx,最後導致xxxx。我出現問題的裝置型號是xxxx，在xxxx上沒有出現問題，是不是xxxxx導致的？

上面6個人提問的方式是完全不同，我想可能只有提問者F才能夠最終得到別人的答覆並順利解決問題，下面我將幫你逐一分析原因：

提問者A是很多人經常犯的錯誤，那就是隻丟擲了問題，並沒有給出問題出現的現象和依據，這會讓被提問者無從下手，沒有絲毫回覆的慾望。畢竟你是求別人幫你解決問題，而不是領導發號施令。提問者C的問題就是說得太多，沒能精確描述問題是什麼。這樣表述不清的提問只會讓被提問者滿臉的問號，然後直接回復：？？？。提問者B是很多初學者（學生）常犯的毛病，沒有明確的問題，沒有明確的解決預期，有的就是祈求式的求助，甚至連要幫什麼忙都沒有表述清楚。對於這種提問，絕大多數人是不予理睬的，因為他們並不想把時間浪費在一個什麼都不明白的菜鳥身上，畢竟他們不是你的老師，沒有義務教你基礎知識。提問者E就不用多說了，這種提問明顯不是衝著解決問題的目的來的。對於這種不友善，懷有敵意的提問，我想大部分人的反應不是去幫忙解決問題，而是在想：這人不會是傻*吧？

分析了上面人的提問方式後，我們可以總結出如下幾個問題時的技巧：

首先明確問題是什麼；優先自我思考解決，解決不了再向別人尋求幫助；清晰地描述問題；問題解決及時反饋並表達謝意。

1.明確問題是什麼

在提問之前，首要任務是要搞明白自己到底要問什麼，訴求是什麼，這是對被提問者最起碼的尊重。

什麼都沒搞明白就稀裡糊塗地跑去問別人，這會讓別人覺得你很唐突無知，給人留下非常不好的印象，這也會直接導致別人不願意幫助你解決問題。

為什麼這麼說？因為別人要想幫你解決問題，還得先搞明白你的問題到底是什麼，你的訴求是什麼，然後還需要幫你分析問題出現的原因，最後才能幫你想出解決的辦法，這花費的精力和代

價實在是太大了。要知道這不是在學校或者醫院，沒人會願意這麼大費周折地幫你。

所以，要想自己的問題能夠得到別人的答覆和幫助，你必須想明白你要問的問題到底是什麼！

2.優先自我思考解決

像這樣不經大腦思考就草率的發問只能得到草率的回答，或者根本得不到任何答案便會石沉大海。其實我特別不建議大家在QQ群或者微信群裡向別人問問題，因為懂的人可能不屑於回答（覺得這樣的問題太low了，即使回答對了也體現不出自己的厲害），不懂的人即便回覆你了也沒有任何價值，反而有可能會把你帶偏了。

因此要想得到別人高質量的答覆，必須擁有與之相匹配的高質量的問題才行，這樣別人才會願意幫你解決。所以並不是什麼問題都是值得向別人提問的。

我們在提問之前，一定要有自己的思考，優先嚐試自己解決問題。下面是我提供的幾個自我解決問題的途徑：

斷點+日誌相結合進行問題跟蹤，深入原始碼探尋問題的本質並予以解決；仔細通讀作者編寫的使用手冊，不要拉下每一個細節（切忌想當然），試著自己找答案；在FAQ裡找答案。如果有開源地址的話，建議優先在Issue中查詢是否有相關的問題，並借鑑其中的解決方法；在網上搜索相關問題（條件允許的話，優先使用google，百度太坑，搜到的大多千篇一律）；向你身邊精於此道的朋友諮詢。

如果經過以上5種方法你都沒能解決問題，這個時候你再向別人進行提問，我相信你一定能夠把問題解決。因為帶著思考向別人提問題，才更能夠得到別人高質量的答覆。如果可以的話，你可以直接把自己想的幾個解決方法闡述出來，這樣別人可能會更願意幫你解決，畢竟大家都喜歡做選擇題，而不是論述題。

3.清晰地描述問題

有這樣一部分人，每次遇到問題需要向別人求助的時候，經常表現的是舉足無措，慌張地描述了一大堆看上去和問題有關又或者無關的話，滔滔不絕口若懸河，問得被提問者一臉懵逼。

面對這樣的問題難免會讓別人頭大。講了一大堆卻分不出主次和主要矛盾，就連問題是什麼都沒有搞得很明白，別人怎麼幫你解決？

因此我們在闡述問題的時候，需要注意以下幾點：

問題描述要言簡意賅，儘量控制在50字以內。問題描述要條理清晰，把握主要矛盾。與問題無關或者相關性較低的話就不要說了。建議問題中包括如下幾部分的內容：問題描述；使用版本；如何重現；期望的效果；出錯現象（截圖或者影片）；裝置資訊（環境）；附加資訊（可以是日誌或者原始碼連結等）；

4.問題解決及時反饋並表達謝意

現實生活中常常有這樣一部分人，在得到別人幫助了之後，連一句問題是否被解決的答覆或者感謝也沒有便消失得無影無蹤，這會極大地打擊被求助者的積極性。

因為問題久拖未決會讓人灰心，他們渴望看到問題被解決，並從中得到幫助別人帶來的滿足感，這點非常重要。否則下次再有人向他提問題時，可能就不太願意幫忙了。

所以，在問題解決後，向所有幫助過你的人發個說明，讓他們知道問題是怎樣解決的，並再一次向他們表示感謝。