## 前沿

经常感觉到自己解决问题速度好像比部分人快一些，不要脸的来总结一下自己解决问题的思路和方法，排名不分先后，适合你的才是最好的。看官，有啥觉得不妥之处或者有其他好的办法，底下评论走起。

我个人博客主页：https://www.cnblogs.com/qiuzhaohai

 ## 第一种 良好的代码规范

良好的代码规范这个是我自己以往项目经验总结出来的，我经历过三四十个项目，自己从头负责到尾的项目也有八、九个吧，其中包括 iOS 项目、Web 端项目、H5 端项目，项目大小也不同。其他的就是要么帮忙部分功能开发，要么就是帮忙改 Bug。

一般来说在项目初期或者不复杂的项目，因为代码规范导致 Bug 产生的情况比较少。但是项目一复杂，开发到了后期，有时候因为没有良好的规范，导致项目出现愚蠢却又难找的 Bug。比如说在已经封装完的函数内继续开发功能，由于局部变量命名不规范，导致用错变量，但是又因为时间问题，必须提交代码，或者必须部署代码，你没仔细检查，这时候导致 Bug 出现。

所以良好的代码规范很重要，当然，比如虽我个人对代码有一些洁癖，但有时候因为粗心也会犯错，所以在代码规范基础上，还需要仔细 Review Code。

## 第二种 打印或打断点

这个应该挺多人都会用，不过用的好不好就不知道了。我基本上遇到 Bug，简单粗略的先定位到自己觉得是 Bug 出现的代码行，打印或者打断点（有可能会同时打印或打断点多处地方），然后一步一步调试，查看数据是否按照想要的方向走。快速定位 Bug 出现的位置，这个就需要靠经验和代码熟悉度了，当然初学者想积累经验也必然要学会调用打印或者打断点。

在思考 Bug 出现的原因时候，如果是认为某方法没走，我会在方法执行前后打印字符串标记一下，比如说在执行方法前打印 “before”，执行方法后打印 “after”，可能比打断点更直观。如果是认为某个数据有问题，我们可以打印数据，或者打断点到这个位置查看数据情况。

## 第三种 对照

由于项目配置。可以使用对照法。

比如项目配置问题，如果是把之前成功的项目配置拿出来比较有哪些不同的地方，如果发现有一些不同的地方，但是又看不懂是干嘛的，把那些配置一个一个 copy 过去尝试一下。

当然比如说是否版本差异问题也会从这方法找到答案。

我这里有个 Mac 上的文件对照软件可以分享给大家，叫 Beyond Compare。


## 第四种 日志采集

这个我用的比较少，之前在开发关于蓝牙 App 的时候使用过，由于在 App 与蓝牙设备通信的时候，时间短，速度快，你打断点可能由于停留过长，问题没发生了，打印的话数据太多会被清屏。这时候你可以采集日志，你可以建立一个日志类缓存收发数据，你也可以操作文件存储。需要时候把这些数据拿出来对照是否传输正确的数据包。

## 第五种 谷歌、百度

哈哈，我也经常使用的一种。虽然谷歌百度很简单，输入点回车就行，但是还是有些人用不好。我自己一般想了解自己错误的原因，我一般要么直接复制错误提示；要么就是思考怎么更加准确描述的话术，定位问题。准确的话术，能节省很多时间，这点非常重要。

在我自己刚开始进入职场时候，百度，谷歌查一些问题的解决办法，带我的技术大牛都会可能也没法直接给我解决，但是他那时候通过百度很快就查到了解决办法。可能那时候我比较稚嫩。

技术网站国内的话，搜索时候就多关注一下几个，csdn，掘金，简书，博客园，segmentfault等，然后就是该门技术常用的社区之类的，比如 iOS 开发就是 cocoachina 等。

国外网站就是 stackoverflow，V2EX（这个需要翻墙，就当作国外的吧。啥？你连翻墙都不会，那这个行业不太适合你）。

## 第六种 休息片刻，马上回来

有时候你解决问题实在没思路，不一定是你解决不出来，可能当局者迷了，这时候最好转移注意力，或者休息一会儿，放放松。等一会再继续编程。

我一般会 smoke 一下下，或者转移一下注意力。如果因为是昨天加班太晚，我会申请休息一会儿，不然心脏实在受不了。

## 第七种 查阅官方文档

当你发现方法使用的不对，但又不知道怎么用，或者框架出现问题，又或者第三方库使用出现问题。你可以查阅官方文档，或者查阅它们的github仓库，去看他们仓库上的 issue 等等。

比如之前 苹果官方不让使用 UIWebView，要求使用WKWebView，之前使用的第三方就需要去适配。简单的话升级一下版本就能解决，有些第三方没升级了，那怎么办，我觉得其他人也会遇到这个问题，因为我使用的第三方基本都是主流，很多人在用的，所以直接翻了他们仓库的 issue，果然很多人遇到过这个问题，他们也给出了解决办法。

## 第八种 重构换一种思路

当你发现这个 Bug 解决不来或者需要花费特别多的时间，那你可以换一种思路去实现，我觉得思路没有好坏，能完成你的需求，都是好办法。当然前提是要想出另一种思路。

如果实在没有解决的方式，多去尝试尝试几种可能能解决的方式，说不定运气好，就解决了呢。敲代码有时候也得看运气，平时多烧烧香，拜拜佛，哈哈。

## 第九种 与人交流

这需要分几种：

* 一是在技术群里面和人交流讨论，技术群都是同行，他们很多能给你一个思路或者答案，在技术群天天潜水，该到了露头时候了，hhh。

* 二是问你公司大佬或者和开发同事交流，公司大佬解决问题有一手，厚脸皮问，大不了后面请吃一顿饭，增进了感情还解决了问题，血赚。当然碰到脾气不好的大佬，被骂骂也没啥的。同事分两种，一种是同水平的，交流一下，说不定他会，或者他能启发你；还有一种是后端同事，让他多处理点东西，方便你行事。以后多给的零食吃吃。

* 三是找产品，可能你发现很难去实现的需求，或者不可能实现的需求，那么就是找产品打他一顿，偶不，是一起商讨是否可以换一种展示形式或者砍掉。当然这种是下策，因为已经评出来的需求，之前没去拒绝或者商讨，这是不对滴。

## 第十种 储存解决方案

比如说你解决了一个比较难的，或者少见的问题，你就把解决方案保存下来，我一般会存储到印象笔记，遇到需要百度或者谷歌的问题时候，先到这个方案库里找找看之前有没有解决过。这些都是宝贵的财富，有时候你都不一定能百度，谷歌搜索到你之前看到过的文章。

## 第十一种 独自头脑风暴

自己一个人放下手中的事情，找个安静的环境，比如会议室，坐在那边思考。要有针对性思考，抓住问题本质，然后一步一步去剖析问题，最后找到一个突破口。

你可以拿笔和纸或者拿一个减压神器，可能会更有思路。

## 总结

先就这么多，后续有想到好的解决思路在补充上去。解决问题思路其实很重要，我接触了很多门语言，学校接触的 C、C++、C#、shell，汇编，工作时候接触的 OC、Vue、CML、Angular，其实我总结这些思路大部分的编程语言开发都能用上。说不定其他行业也能用上。[掩面而笑]，可把我牛逼坏了。