信息爆炸的時代，信息的獲取變得非常容易，但也有太多無效的信息。如何分析，過濾，篩選有效的信息至關重要。對于開發而言，搜索有用信息，是提高開發效率的利器。
下面分享一些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)
問機器，你要盡可能簡單，并且自己做好分詞。最好不要搜索句子，別放標點，語氣詞，助動詞這些無意義的字。并且每個詞之間加上空格來手動分詞，避免被錯誤分詞的可能。
可以參考這篇知乎來看google tips。如何用好 Google 等搜索引擎?
搜索引擎之外的好幫手
有些網站是不允許搜索引擎爬的，比如一些BAT的開發文檔，論壇等，如果說微信支付調試不成功，百度推送總有error code，那么你要做的是去官方的wiki或者討論區里用站內搜索來找答案。這種問題你去問人，對方碰到過的概率極低，所以別浪費時間啦。還有一些第三方lib出問題了，可以拿包名去github上找出處，看看有沒有更新，或者去issues里翻翻有沒有類似的問題。
國內現在有很多好的技術分享站，從個人代表(郭霖，鴻洋，大頭鬼，胡凱等)到優秀技術文章協同收錄站(掘金，干貨集中營，codeKK, AndroidWeekly等) 有時候甚至都不需要google，有問題直接就在這些網站就能找到高質量的知識分享。經常瀏覽上面的文章，擴展自己的眼界，找自己感興趣的知識來補充。是非常省時間的事。
要注意的是，如果只mark，不實踐。那它只是一個知識節點，沒有與你的知識體系交織到一起，很快你就會遺忘它。別信自己會先收藏再消化的鬼話。
又如果說你的鳥語比較好，那會如有神助啊，google，stackoverflow，github都會成為你解決問題的好幫手。有些時候中文難搜到的，用英文很快就能找到。中文google的概率也比百度高一些。如果是搜demo或lib，eoe, csdn算是個選擇，不過大多數也是從github上翻下來的，如果你想實時更新，盡可能還是英文的好。把lib的包名在github搜下就出來了。
其實最重要的幫手是你的知識體系。如果你想構建它，一個是通過文章分享來逼迫自己將知識節點吸收轉換成你體系的一部分。一個是高效的思維方式更快的去轉化吸收。
可以參考這篇文章更形象的理解如何構建知識體系。長期接受碎片化信息，會有什么后果？
不要寄希望于找到一行都不改的源碼
當然，能找到完整的解決方案最好，皆大歡喜。但如果簡單的搜索之后，還沒找到最優解，那就得停下來分析下。基于目前的調研，把得到的信息匯總下。
WHAT WHEN HOW WHY，我們知道需求的前因后果，是否還需要完善，或者更好的方式去傳遞給用戶。通過搜索或wiki，我們知道目前可行的解決方案有哪些，需要多少工作量來完成它。
別一上來就想著搜個源碼直接用，也不要一開始就去畫UI。Stay一般是這樣規劃的：
- 先想清楚產品到底要一個什么樣的功能，這個功能對產品來說是否真的那么重要，有沒有什么更能放大這個效應的做法。
- 與產品討論，理解他們通過APP想表達的訴求，將它們轉化成真正的需求，并畫出流程圖與產品反復確認。
- 需求理解好了，可以先拆分調研相關技術點。先不要急著去表達這個功能實現不了，這個效果要花時間。不妨客觀的分析下（反正都要實現，為什么不把它做的好一點呢）
- 有個大抵的了解之后，團隊在一起討論下，采用什么具體實現，誰來實現。(務必讓每個人都對代碼有整體上的認識，不要各自維護自己的小模塊，不利于成長，也不利于團隊)
- UI一般都要比業務邏輯改動的頻繁，所以最好不要急著畫UI，只要有一個大致的UI框架就可以了。先把業務邏輯完善（網絡交互，cache，點擊事件，跳轉）如果有盈余，可以寫unit test來測試C層或者P層邏輯的正確性。沒問題了再寫UI實現。
- 剩下的具體實現呢，如果沒有現成的代碼可以用，可以再拆分成幾個task。先自己將tasks通過workflow串在一起，不管是流程圖，還是TODO偽代碼都行。再針對每個task來搜對應的解決方案。
- 所有技術問題不可能是無解，只要耐心，肯定能找到解決方案。別怕麻煩，別圖省事，碰到的每一個問題都是你進步的階梯。如果真不能解決，那就換個折中的解決方案嘛，溝通灰常重要的！
很多人都希望問一個最優解，這并沒什么不好。可是衡量一個優秀的技術人員并不是看他有幾個G的源碼庫啊。都能不厭其煩的去問別人問題，為什么不能好好靜下來分析處理問題呢？
快速提升的秘訣
最后，說個快速提升能力的秘訣：分享。當有人碰到問題求助與你時，別怕麻煩，你會的盡量去分享，不會的盡量去思考，他人的問題以后也可能變成你的問題，只要你動動腦子，幫助分析，遲早對方會解決這個問題，也意味著你也解決了這個問題。多劃算的事兒啊，不用寫代碼，不用debug，動動腦子你就多了一個儲備的解決方案。
最后
以上這些套路并不一定準確，或許你還有更好的方式。技術更新越來越快，當我們很難跟上節奏的時候，不妨停下來。常思考，常實踐，尋找一種高效的方式來補充知識體系。如果看到這里，你開始思考了。那這篇文章的目的就達到了。
其實我還挺想說說提問的技巧。為什么有的人發問題，沒人理睬。但有的人只要說一句話就能引發討論呢？這個現象有一定的參考價值，Stay會嘗試再寫一篇文章來分析-提問的藝術。
實踐案例：
擴展閱讀：
