分享職場生活、職場攻略、領導同事相處技巧和創業資源

文|洪生鵬

01主動嘗試解決問題

因工作需要，被叫去當面試官，其中一位女求職者給我留下深刻印象。當我問她，“你平時開發過程中，要是遇到問題時，你是怎麼解決的？”她的回答令我甚是驚訝，“我技術一般，遇到不懂的，都是直接找同事幫忙的，他們都很願意幫我。”

有人願意幫忙，說明你人緣不錯，只是遇到難題就直接尋求他人幫忙，人家能幫你也只是一時。碰到難題，自己沒有事先思考，這是很不明智的。自己先思考，學會自己嘗試尋找解決方案，實在解決不了再找他人幫忙。才是上策，而不是到處問答案。

02有效地提問問題

有效地提問問題，是解決問題的前提

關於提問，自古以來就備受人們青睞，有學就有問，有問方顯學。學而不思則罔，思而不學則殆，大概就是這個道理，有提問，說明有在學習。帶著問題學習，更專注於學習，越學會越來勁，越學越精進。我們印象更深的，可能是孫中山先生的“不懂就要問，哪怕捱罵也值得”。是的，敢於提問是我們學習進步的一大渠道。需要注意的是，不是什麼都得問，孫中山先生是在背誦了課文，自己先思考後不懂時再提問的。

職場上，要是事情都要別人講得很明白才懂得怎麼去做，那別人也不太願意把事情交給你辦，也不太相信你能辦好。

自從開了公眾號，不少同行一起討論Android問題較多。作為一名移動開發者，Android的兼容問題多姿多彩，不同型號的機子更可謂獨自異彩。

有的讀者提問問題比較隨意：

• 為什麼我的按鈕點擊事件沒有響應？我已經安全按照你提供的代碼編寫的，求救啊！
• 為什麼我運行了你的demo，界面一面空白，可以幫我看看嗎？
• 按照你說的，編譯出錯了，你能幫忙看下嗎。
• 使用你的demo，這個異常怎麼解決？
• ……

提問問題，請把問題的場景描述清楚，什麼情況下出現，最好有關鍵代碼片段。這樣一來，方便定位問題。如果你只是花幾分鐘隨便把問題一拋，我就得花30分鐘，甚至更多的時間來分析理解，有時最後還沒有答案。

對於開發環境出現的問題，請自行先用搜索引擎搜索解決。開發環境問題，能自己通過引擎搜索解決的問題，請自己先動手。不要抱著這樣的心態，“我是新手，我剛入門，麻煩大神幫我解決一下”。這個理由，貌似不錯，可是，誰不是從新手進階來的。

關於基本問題的，能獨立解決的，請先自己動手。1939年我們偉大的毛主席在延安生產動員大會上作了生動而深刻的講話，“自己動手，豐衣足食”。

在你無法通過搜索引擎找到答案時，清晰地提問，自己已做一定的思考的提問情況下，恭喜你，你已經接近解決問題的邊緣了，因為你學會了獨立思考，有自己的思考。

比如我對某官方的sdk 使用中的疑惑，需要請教官網技術支持的幫忙的。知道官網技術支持一般都很忙的，針對一對多的情況。個人覺得這是一種不錯的提問方式，當時我是這樣問的：

立即收到技術支持的回覆

ok問題順利得到解決了。

向人家請教問題，態度誠懇，尊重對方這點很重要。提問問題，我們不是在排話劇，並不需要什麼開場白，什麼

• “你好，在嗎？”，
• ”請問你有空嗎？”，
• ”我可以問你個問題嗎？”，
• ”幫我看個問題好嗎？”這樣的，

說了幾分鐘還沒進入正題，還沒把問題描述清楚，讓人家猜。這不是你猜我猜的遊戲。你要的是解決你的問題，我們都希望自己的問題解決了，也不用佔用對方太多時間。這才是我們想要的。

程序員基本功

以我作為一名移動開發者來說，我希望開發者這樣向我提問：

問題標題有針對性

標題指明環境、錯誤時機、現象。如：
較差的標題（×）：發現一個兼容性bug（標題過於廣泛，讓人有點懸）
較好的標題（√）：華為 某某機型上出現調用初始化時導致崩潰的兼容性問題求解

問題描述詳細

問題描述詳細，可以方便其他用戶幫您定位問題。儘量提供詳細的環境、錯誤時機、堆棧、日誌、現象、截圖等等。

不妨參考下面的格式：

【問題描述】
描述出現問題的環境：Android版本、設備型號、網絡狀態、SDK版本等等
描述為了解決問題作出的一些嘗試，例如通過搜索引擎查到的相關資料 

【錯誤堆棧】
貼出具體的日誌Log

03解決問題的能力

解決問題的能力，是程序員立業之本

《禮記》中“博學之，審問之，慎思之，明辨之，篤行之”，就明確提倡我們在學習的過程中，要多提問，多思考，多行動。辦法總是要比困難多，只有不斷地學習，解決問題，我們的技術水平才能提高得更快，對自己才會越來越有信心。

學習過程中，要懂得善於充分利用網絡資源，但請不要做拿來主義者，對於他人的解決方案要學著借鑑和吸取。

他人的解決方案要學會轉換成自己的，只有自己掌握了才是真的學會了，千萬停留在表面的層次。

能通過搜索引擎解決的問題，自己應該多搜索相關類似的，基礎的書籍還是必備的，針對新手，這樣的你就可以系統性的學習，免得遺落一些知識點。

經過搜索後還是沒有結果後，這是我們就應該像孔子的不恥下問一樣的。主要是要把問題描述清楚，建議有異常日誌，相關片段代碼，截圖，畢竟有圖有真相。

儘量不要問題只提一點，描述不清楚，讓人想回答都無從下手，只能靠猜測，相信這也不是你想要的結果。把問題描述清楚了，也是一種能力。沒把問題描述清楚的，有時還得反過來問你，

這樣一問一答，雖然溝通看上去挺高效的，但其實並不適合，時間週期就會比較長，少則30分鐘，多則1小時了，甚至更多。

記得有位群員，一進群就直接拋出半截問題“ 大神們，幫我看看，這是什麼情況？”，就拋個錯誤日誌，日誌裡很明顯提示184行出錯，他自己不去定位184行到底是啥錯誤，又不貼出184行處理了什麼邏輯。非得人家問他184行是什麼，他才貼出來。更奇怪的，這次人家幫他解決了，下次他還提出類似同樣的問題。

別人幫忙解決了，請不要把它扔一邊去了，自己沒有思考為何會這樣，有沒有其他的方法可以解決的。善於總結，比較分析，針對一個問題，思考不同解決方案，下次碰到類似問題就能自己解決了。

在提問過程中，要是條件允許，能加上自己思考的整理，說不定你在整理的過程中你自己就發現問題所在，腦子一下子豁然開朗了。

有些問題，能配上圖的儘量配上，有圖有真相，儘量不要讓他人去想象，一個好的問題提問者，你確保提問的問題描述是否清楚，能做到言簡意賅是最好不過了。

你提問的過程要是能附上如下信息那就更好了：你已經做了什麼？你做了哪些思考？哪裡做不出來？調試過哪裡不行，不要簡簡單單拋一句某某類型手機不行，對於你說的某類型手機，我也沒用過。

建議把自己掌握的東西再分享出去，互相交流，或許能收到更大的收穫，其他同行能幫我們指出其中的不足。

剛做程序員時，編程基礎比較薄弱，有次領導安排的任務，自己未曾接觸過，心裡沒底，總擔心不能按時完成任務，會被炒了魷魚。於是上班路上想，下班回去也再想如何解決。不怕你笑話，我很怕被老闆炒魷魚，即要是走也是我自己走。

編程真的不是一件容易的事。在編程的路上，我們總會遇到各種各樣的難題和bug，對於有些bug，我們有時會一時束手無策，而領導又再詢問進度，我們會沮喪，鬱悶，甚至洩氣。遇見多了越能明白這個道理，不過想想，這倒是個機會，請靜下心來，耐心點，有些小bug可以自己獨立解決，靠自己的力量取得小成慢慢樹立自信心和獨立自強的意識，不僅能鍛鍊我們不斷解決問題的能力，而且還能鍛鍊我們的耐心。假以時日，相信你也能在項目中獨當一面。

以上只是個人的看法，說這些並不是為了吹噓自己能力有多強，只是把我看到的和想到的東西用文字說出來，希望對你有所幫助。

【END】

閱讀更多 洪生鵬 的文章

關鍵字: 職場 工作這一年 解決問題