資訊爆炸的時代，資訊的獲取變得非常容易，但也有太多無效的資訊。如何分析，過濾，篩選有效的資訊至關重要。對於開發而言，搜尋有用資訊，是提高開發效率的利器。

下面分享一些Stay在解決問題時的套路。包含分析需求，篩選，搜尋，團隊協作等一系列開發中可能遇到的問題。希望藉此套路能提升大家的開發效率。

分析問題

一個問題出現，必然有它的原因，場景，觸發條件。想要解決問題，首先需要冷靜分析。

WHAT WHEN HOW WHY

這個問題是什麼？它在什麼場景下發生？上下文是什麼？它是如何被觸發的？為什麼會發生？

我們要解決問題，需要弄清楚的是why。但是在徹底弄清楚why之前，我們可以通過一些線索來求證。而不是通過抓瞎來找原因。

假如你認真分析了WHAT WHEN HOW，順著那根線去找源頭，80%的問題都能找到原因，只要找到原因WHY，那問題很快就能解決。你甚至不需要通過google，向他人求助就能順利解決問題。同時，你每一次解決問題的方式都會被強化，直到成為你思考問題的體系。你會成為一個相當優秀的人。

舉個栗子：
問題WHAT： 我們有很多推送SDK，但是有個問題總是不好解決，當一臺裝置有多個帳號登入時，推送會亂掉。
場景WHEN： 發生於當用戶在同一裝置上登入多個賬號時。
觸發條件HOW： 如有ABC三個賬號登入過，當前登入為D，當伺服器推送一條訊息給A時，D卻收到了這條推送。
原因WHY： 我們藉助第三方平臺sdk來發推送訊息，sdk需要一個裝置唯一id(regId)來標識，在sdk眼裡是沒有賬號體系的，只有裝置regId。我們一般會將regId跟登入account繫結起來。當伺服器要推送時，會在db中查詢account對應的regId，呼叫雲推送sdk傳送單點訊息。但是如果登入另外一個account，但是regId又未跟之前的account解綁。問題就發生了。
解決方案

： 通過分析，我們知道箇中原因，那隻要保證我的regId和account是一對一關係就可以，當account在繫結regId時，伺服器先查詢是否有已繫結的account，如果有，就刪掉，繫結新的就可以了。
擴充套件1： 雲推送還給我們提供了tag方式進行分組推送，既然可以分組，那我把組的粒度控制到account可以嗎？理論上可以的，只要tag沒有限制。
擴充套件2: 單點登入如何實現（同一時間只能有一個account登入一個device，否則要通知下線），也就是說A不能同時在device1和device2上登入，後登入的要把先登入的擠下線。簡單說說方案，擠下線可以用token失效來實現，通知下線可以用推送。
擴充套件3: QQ的多型別裝置登入如何實現（裝置用很多種android，iPhone，iPad，Mac，Windows），允許A同時在android，pad，電腦上登入。簡單說說方案，account與regId做成一對多關係，但是要多加一個型別限制：phone，pad，computer。

學會分析問題比寫程式碼更重要。

藉助Wiki

通過WHAT WHEN HOW分析出了原因WHY，可能我們並不知道如何去解決。它不是一個業務邏輯錯誤，也不是自己知識體系中的節點。所以我們需要通過補充相關知識來解決問題。比如藥怎麼吃，SDK如何整合，微信公眾平臺支付介面，軟體如何使用。等等。這些都可以通過官方手冊來系統解決。

藥怎麼吃，有什麼副作用，不能和什麼混用。SDK需要如何配置，在哪些地方要做處理，什麼情況不能支援等。所有這些常見的問題，都會有一個官方的解釋。只要按照上面的來。80%的問題也能迎刃而解。即使你是個特殊問題，也可以通過官方論壇或者提交工單解決問題。

比如微信支付如何接入，友盟sdk如何整合，狀態碼為何返回error？這些完全沒必要去問其他人，直接找官方的wiki，sample，解決不了就去提交工單。假如你做一個SDK提供給其他人用，難道不會cover所有情況，提供詳細的wiki以及demo嗎？這都做不好，哪會有人願意來使用整合呢。(好吧，當我沒說)

遇到問題要耐心，千萬不要病急亂投醫，這樣反而讓自己變得焦躁，更沒法集中注意力去分析問題，解決問題了。

有什麼是搜尋引擎搞不定的嗎？

為什麼大家都用搜索引擎，有的人能搜出答案，有的人卻搜的都是要命廣告。

除了一個用google，一個用baidu

還有一個原因：鍵入的搜尋詞不一樣

想要搞清楚為什麼，首先得簡單瞭解下google baidu是如何運作的。

如果你自己搭過網站，寫過部落格，過不了幾天，搜尋引擎就來爬你的資料，將你所有的內容都收錄。然後通過一些關鍵字就能搜到你發表的文章以及網站了。當然如果是很常見的關鍵字，就會優先顯示權重或pr值高的網站。又或者你的文章被其他pr值高的網站抄襲了，你的網站就只能排在後面了。

那搜尋引擎是怎麼收錄網站的呢？一篇文章是如何儲存在伺服器的呢？之前在android上做過Lucene全文檢索引擎，我想在策略上是相似的。通過將文章分詞，拆解成一個個詞語，句子，分塊儲存在索引裡。當我們搜尋時，再將搜尋內容分詞，去索引中找到最匹配的內容提取出來，通過一些匹配度，權重排序，再顯示到結果上。當然搜尋引擎真正的實現要比這個複雜得多，也智慧得多。不過也可以不去深究。只要明白在搜尋時，鍵入的搜尋詞是相當重要的。

如何選用正確的關鍵字來搜尋呢？很多人搜尋時描述的非常生活化，比如xxx怎麼實現的，xxx支援xxx嗎，xxx可以做xxx嗎。哎，搜尋引擎終究是機器啊，不是人工檢閱啊，你使用的無關詞彙越多，越會分散匹配度。最後得出的結果差強人意。

假如你寫文章來分享你的解決方案，會如何取名，填相關keywords？肯定會盡可能的去描述它對吧。反過來其實也一樣。用最簡單的關鍵詞描述你的問題，比如(retrofit multi upload) (retrofit refresh token) (recyclerview onitemclick) (database encrypt) (android webview openFileChooser doesn’t work) (okhttp post 304)(retrofit progress update)

問機器，你要儘可能簡單，並且自己做好分詞。最好不要搜尋句子，別放標點，語氣詞，助動詞這些無意義的字。並且每個詞之間加上空格來手動分詞，避免被錯誤分詞的可能。

搜尋引擎之外的好幫手

有些網站是不允許搜尋引擎爬的，比如一些BAT的開發文件，論壇等，如果說微信支付除錯不成功，百度推送總有error code，那麼你要做的是去官方的wiki或者討論區裡用站內搜尋來找答案。這種問題你去問人，對方碰到過的概率極低，所以別浪費時間啦。還有一些第三方lib出問題了，可以拿包名去github上找出處，看看有沒有更新，或者去issues裡翻翻有沒有類似的問題。

有時候甚至都不需要google，有問題直接就在那些優秀部落格和收錄站就能找到高質量的知識分享。經常瀏覽上面的文章，擴充套件自己的眼界，找自己感興趣的知識來補充。是非常省時間的事。

要注意的是，如果只mark，不實踐。那它只是一個知識節點，沒有與你的知識體系交織到一起，很快你就會遺忘它。別信自己會先收藏再消化的鬼話。

又如果說你的鳥語比較好，那會如有神助啊，google，stackoverflow，github都會成為你解決問題的好幫手。有些時候中文難搜到的，用英文很快就能找到。中文google的概率也比百度高一些。如果是搜demo或lib，eoe, csdn算是個選擇，不過大多數也是從github上翻下來的，如果你想實時更新，儘可能還是英文的好。把lib的包名在github搜下就出來了。

其實最重要的幫手是你的知識體系。如果你想構建它，一個是通過文章分享來逼迫自己將知識節點吸收轉換成你體系的一部分。一個是高效的思維方式更快的去轉化吸收。

不要寄希望於找到一行都不改的原始碼

當然，能找到完整的解決方案最好，皆大歡喜。但如果簡單的搜尋之後，還沒找到最優解，那就得停下來分析下。基於目前的調研，把得到的資訊彙總下。

WHAT WHEN HOW WHY，我們知道需求的前因後果，是否還需要完善，或者更好的方式去傳遞給使用者。通過搜尋或wiki，我們知道目前可行的解決方案有哪些，需要多少工作量來完成它。

別一上來就想著搜個原始碼直接用，也不要一開始就去畫UI。Stay一般是這樣規劃的：

1. 先想清楚產品到底要一個什麼樣的功能，這個功能對產品來說是否真的那麼重要，有沒有什麼更能放大這個效應的做法。
2. 與產品討論，理解他們通過APP想表達的訴求，將它們轉化成真正的需求，並畫出流程圖與產品反覆確認。
3. 需求理解好了，可以先拆分調研相關技術點。先不要急著去表達這個功能實現不了，這個效果要花時間。不妨客觀的分析下（反正都要實現，為什麼不把它做的好一點呢）
4. 有個大抵的瞭解之後，團隊在一起討論下，採用什麼具體實現，誰來實現。(務必讓每個人都對程式碼有整體上的認識，不要各自維護自己的小模組，不利於成長，也不利於團隊)
5. UI一般都要比業務邏輯改動的頻繁，所以最好不要急著畫UI，只要有一個大致的UI框架就可以了。先把業務邏輯完善（網路互動，cache，點選事件，跳轉）如果有盈餘，可以寫unit test來測試C層或者P層邏輯的正確性。沒問題了再寫UI實現。
6. 剩下的具體實現呢，如果沒有現成的程式碼可以用，可以再拆分成幾個task。先自己將tasks通過workflow串在一起，不管是流程圖，還是TODO虛擬碼都行。再針對每個task來搜對應的解決方案。
7. 所有技術問題不可能是無解，只要耐心，肯定能找到解決方案。別怕麻煩，別圖省事，碰到的每一個問題都是你進步的階梯。如果真不能解決，那就換個折中的解決方案嘛，溝通灰常重要的！

很多人都希望問一個最優解，這並沒什麼不好。可是衡量一個優秀的技術人員並不是看他有幾個G的原始碼庫啊。都能不厭其煩的去問別人問題，為什麼不能好好靜下來分析處理問題呢？

快速提升的祕訣

最後，說個快速提升能力的祕訣：分享。當有人碰到問題求助與你時，別怕麻煩，你會的儘量去分享，不會的儘量去思考，他人的問題以後也可能變成你的問題，只要你動動腦子，幫助分析，遲早對方會解決這個問題，也意味著你也解決了這個問題。多划算的事兒啊，不用寫程式碼，不用debug，動動腦子你就多了一個儲備的解決方案。

最後

以上這些套路並不一定準確，或許你還有更好的方式。技術更新越來越快，當我們很難跟上節奏的時候，不妨停下來。常思考，常實踐，尋找一種高效的方式來補充知識體系。如果看到這裡，你開始思考了。那這篇文章的目的就達到了。

其實我還挺想說說提問的技巧。為什麼有的人發問題，沒人理睬。但有的人只要說一句話就能引發討論呢？這個現象有一定的參考價值，Stay會嘗試再寫一篇文章來分析-提問的藝術。

歡迎技術討論，開發交流