除了技术，我们还能拼什么？

今天在网上看到了一篇大神的博客，感觉非常好，值得我们静下心来思考。大神的博客地址：http://notes.stay4it.com/

接下来是大神博客的内容：

信息爆炸的时代，信息的获取变得非常容易，但也有太多无效的信息。如何分析，过滤，筛选有效的信息至关重要。对于开发而言，搜索有用信息，是提高开发效率的利器。

下面分享一些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)

问机器，你要尽可能简单，并且自己做好分词。最好不要搜索句子，别放标点，语气词，助动词这些无意义的字。并且每个词之间加上空格来手动分词，避免被错误分词的可能。

可以参考这篇知乎来看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会尝试再写一篇文章来分析-提问的艺术。