谈谈程序猿解决这个问题的能力
解决这个问题的能力，程序猿立业之本。
一般写文章我不会特意去写，而是有感而发的时候刚好又有时间我就会去写写文字。本想推些技术文章的。但写技术文章又非常耗时，写得太浅显又没有技术含量。写多了恐怕大家也没耐心去看（不就是懒么。给自己找这么多借口）。公众号这么多，你又能看的了多少呢？小巫这个公众号不会像某些网红那样每天都想破脑袋去写文章，也不期望这个公众号能给我带来什么。毕竟以我的尿性我让我每天写鸡汤文我自己都会恶心。好了，进入今天这篇文章的主题，跟大家谈谈程序猿解决这个问题的能力。
为什么会想写这篇文章？
前面我写过一篇关于独立思考的文章-你是怎么思考的？[1]，大家感兴趣可以去看下。关于独立思考。我认为每一个人都应该要有。作为一个成年人，非常多事情都要别人讲得非常明确才懂得怎么去做，那别人也不太愿意把事情交给你办。也不太相信你能办好，你也非常难掌控自己的命运。今天的这个主题尽管讲的是程序猿解决这个问题的能力，事实上也还是讲独立思考的能力，由于解决这个问题的能力也是源自你是否会独立思考。之前写过一些文章，有的同学想让我写写在鹅厂的一些经验，事实上说真的。在鹅厂工作也是因人而异的，无论在哪里工作终于还是取决于你是怎么赋予工作的意义，每天纠结自己工作反复繁重，纠结工作技能得不到提升。纠结薪水满足不了自己的欲望，纠结这纠结那是毫无意义的。问题的根本也不在于这些，而是你是否足够沉得住气去提升自己。假设你连日常工作的一些问题都解决不好，你也别期望自己能在非常短的时间内提升非常高的水平。还是那句话，就算你有十年的工作经验，假设你仅仅是一年的工作经验用了十年，那真的怪不得别人比你厉害了。人到中年的时候那真的有危机了。
吐槽一些开发人员白纸一般的脑袋
之从做了SDK开发人员之后。每天帮助用户解决各种各样的问题。那我真的有理由相信为什么国外的月亮会比国内的月亮圆了。由于国内的一些开发人员真的让我非常方啊。国内的开发人员复制黏贴的能力是一流的，嗖得一声就能把功能实现，感觉好厉害的样子（皮皮虾。我们走）。集成我们提供的SDK的时候。也是嗖的一声遇到问题不知道怎么解决。
小白开发人员A：为什么升级弹窗提示不了？我已经全然依照文档集成了啊，求救啊。
。
小白开发人员B：为什么集成热更新SDK之后。修复不了我的问题？
小白开发人员C：集成SDK之后，编译出错了。谁能帮忙看下。
小白开发人员D：怎么开启混淆啊。。。
小白开发人员E：为什么没有mapping文件。
小白开发人员F：为什么接入SDK之后，没有看到log。
小白开发人员G：这个异常怎么解决？
很多其它。。。
尽管标注的是小白开发人员，但我也遇到非常多工作好几年的开发人员相同这样问问题，这个已经不是经验上的的问题了。换个角度思考一下，假设别人向你这样问问题，你会理睬他么，说真的我还不如利用这些时间多修几个bug，非常多开发群终于都会沦为水群就是这个道理。
大家都有当小白的经历，人生这一辈子不懂的事情太多了，那你总不能让别人牵着你走，作为一个程序猿要对得起程序猿这个称号，作为一个project师，你能否体现自己project方面的能力。假设连主要的解决这个问题的能力都没有。那还是尽快放弃当程序猿。这一行当没你想得这么好玩。
如何才算具备解决这个问题的能力
我先说一下我的一家之言吧，说这些并非为了吹嘘自己能力有多强。仅仅是把我看到的和想到的东西用文字说出来，至于别人怎么去解读我是无所谓的。
第一点：主动尝试解决这个问题
程序猿的解决这个问题能力不是天生的，自然得靠后天的经验积累。我们工作中会遇到各种各样的问题。比方须要去跟踪调试产品所产生的bug，又比方说使用第三方组件所遇到的一些问题，再比方说使用一些插件或者IDE所产生的一些编译问题。
这个时候第一反应不是去别人那里寻求帮助。而是自己尝试去看去解决这个问题。首先得确定这是一个什么样的问题，对这个问题下一个定义，看它是自己编码上的问题，还是一些编译上的问题。再或者是第三方库引入的问题。确定之后，你可以依据执行时产生的崩溃信息或者编译时出现的编译错误，找到错误的根源。假设是代码上的问题事实上是非常好定位的，我们仅仅须要依据错误的堆栈找到出错的地方，然后你再去看这部分代码的处理逻辑，仅仅要不是特别复杂的业务处理，基本上能非常快解决。
假设是编译时出的问题怎么办？你先看具体的编译错误是什么，看自己曾经是否有遇到过。是否可以确定是什么环节导致的编译错误，比方是开发环境版本号问题，或者是插件的版本号问题，又或者是代码导致的编译问题，这类问题仅仅要逐个排除相信也可以轻松解决。
那假设是业务逻辑导致的问题怎么办？那我就建议你自己依据需求又一次梳理清楚业务逻辑，可以通过debug来验证你的结果，又或者可以通过日常写单元測试用例来保证业务逻辑的正确性。关于各类问题的解决，解决的方法总是能找到，就看你是否足够耐心去寻求解决方式。
第二点：学会提问
刚才说的第一点。对开发人员能力有一定的要求。并非全部开发人员都可以做到这一点。那假设依靠自身能力解决不了问题该怎么办？没错。就是向别人提问，但这里要注意一下提问的技巧。就不要像我所吐槽的白纸一般的开发人员。关于提问的技巧非常多人都在提，感同身受最深的应该是那些为开源项目做贡献的开发人员了，仅仅要一开源就必然会有非常多人过来问问题。提issue。以我作为SDK开发人员来说。我希望开发人员这样向我提问：
- 首先态度诚恳，平等尊重（这非常重要）
- 问题标题有针对性
标题指明环境、错误时机、现象。如：
较差的标题（×）：发现一个兼容性bug（太宽泛。全然没有点进来看的欲望）
较好的标题（√）：Vivo X5上xxx SDK调用初始化时导致崩溃的兼容性问题求解- 问题描写叙述具体
问题描写叙述具体。可以方便其它用户帮您定位问题。尽量提供具体的环境、错误时机、堆栈、日志、现象、截图等等。
可以參考例如以下格式：
【问题描写叙述】
描写叙述出现故障的环境：Android版本号、设备型号、网络状态、SDK版本号等等
描写叙述为了解决这个问题作出的一些尝试。比如Google查到的相关资料
【错误堆栈】
贴出由Bugly分享出来的错误堆栈（分享链或截图）
这里有一篇文章也推荐大家看下- 提问的智慧[2]，想提高自己解决这个问题的能力。首先得学会如何提问。
第三点：经验总结
我们日常遇到的问题就相似打怪升级一样。你解决的问题越多你的能力就会越强，经验自然也会越来越丰富。但人的脑袋不可能记住全部事情。将自己遇到的问题沉淀下来对以后自己查阅也有非常大的帮助，就不必每次都要去Google，自己也可以有一个索引库。
常常自己总结。也可以提高自己的写作能力。以后写文章、ppt总结提炼自然也难不倒你了，也是一举两得的事情。还有你以后求职面试过程中。提及自己这方面的能力的时候。也可以为自己面试加分哦。
第四点：知识经验传承
精神哥说过：不总结哪来的经验，不分享经验有何用？
一个人能产生多大价值取决于他的影响力有多大，之前看到有人在我们内部论坛提问说提高影响力有什么用？你看看马云就能知道有什么用了。他说一句话比你说上百句都管用，毕竟人家的影响力在那里。
非常多微商都常常拿马云来说话。尽管马云自身没说过这些话，但为什么别人拿马云来忽悠人，不拿你来忽悠人，这就是影响力的作用。我们程序猿做知识经验的传承。不仅可以提高你自身的影响力，还可以帮助你提升逻辑思维能力，由于你须要去总结提炼，你须要将问题梳理清楚，而且要将知识点描写叙述得可以让别人更easy接受。
你的经验尽管是你自己的，但假设你的经验可以帮助到别人。那你的价值就不一样了。
总结
笔者在写开发文档的时候，常常都会去思考怎么让开发人员通过这个文档更加轻松的接入我们SDK，怎么样设计接口会更符合开发人员的思维，多提几个为什么可以帮助自己让自己的思考更加完好，这篇文章是笔者入行这两三年的一些思考，也希望可以帮助到广大开发人员可以清楚认识到自己在这方面的能力，最后谢谢大家可以看到这里。
[1] . http://www.jianshu.com/p/e698fea61a39
[2]. https://github.com/tvvocold/How-To-Ask-Questions-The-Smart-Way