通常我们区别一个人是新手还是老手，可以看一下几个方面：

• 新手，百度的主要是语法。老手，Google的基本是解决方案或者疑难bug。

• 新手，一顿操作猛如虎，一旦发测全是bug，甚至有需要颠覆设计来修改的。老手，先想，甚至画画图，不紧不慢开始写，甚至有写几行，喝几口茶的感觉，但是写出来的稳得一批。

• 新手，面对bug，首先就是猜，应该是那里，改了再说，恩，好了，然后其他地方出问题了。老手，先分析代码，然后看日志，复现，修改，再复盘一下。

那么，如果我上面的都做到了，就是老手了么？不一定，还有一个很重要的因素---解决问题的能力。

可以说，工作3-5年，上面3点基本都能达到，毕竟熟能生巧，但是解决问题的能力，真的是天赋和努力都需要。

同样一个问题，新手只想怎么打补丁，老手想的是怎么从源头解决而不影响大局，但是大神，往往会想有没有更优方案。

举个例子，sql错误秒杀系统超发了。

• 新手可能一看，哦，这个SQL有问题，改一下。

• 老手一看，这么改可能有并发瓶颈，优化一下。

• 大神一看，这个可以加个队列，解决并发问题，然后对于客户端体验怎么优化一下，产品可以提供一下响应的友好提示等等。

简单的说，就是格局和视野不一样。

那么，我们要怎么锻炼我们解决问题的能力呢？

事无巨细，悉以咨之。

学习的好途径就是经历，我们可以抓住工作中遇到的每一个问题，看看别人是怎么解决的，想想有没有更好的方案，记下来自己复盘。

很多论坛上的求助，或者大佬们对于行业痛点的解决方案，多看看，体会一下他们的优劣和特点，同行就是好的老师。

后就是多思考。

只要思想不滑坡，办法总比困难多。

优化流程

很多时候，我们可能会疑惑，为什么别人能想到我想不到。

首先是知识储备的问题。

你永远想不到你并不知道的东西。

也就是贫穷限制了我们的想象力，这个需要我们多积累，多看多学。

其次就是思考模式的优化，这里主要谈谈这个。

场景分析，抛开程序思维

我常常开玩笑：如果解决不了，就干掉那个提需求的人。

意思就是如果一个需求或问题比较棘手，可以先问问提需求的人，原始需要是什么，可能会找出一个程序实现简单，而且更符合原始需求的方案。

虽然这种机会很少，毕竟产品和程序不打起来已经不错了，但是有时候真的有奇效，会减少很多开发时间。起码你了解了为什么要做这个东西，也不至于怨天怨地。

定义问题，抽象模型

想要解决问题，首先要明白到底是什么问题。

比如，CPU占用非常高，我们把耗CPU的干掉一些把。

首先，CPU占用高并不是问题，CPU就是拿来用的，不卡就不用解决。

其次，优化不等于干掉，先找出有没有空耗CPU的，其次再分析有没有低效利用CPU的。

后，在确定解决方案。

如果方向错了，怎么努力都是错的。

刨根问底

比如一个接口经常超时，有人说，超时时间改长点不就好了。这里你会也许觉得很挫。但是在实际工作中，这种补丁数不胜数。

一旦你选择了妥协，那么就会一直妥协。久而久之，你就会变得不愿意思考，逐渐平庸。

任何现象的背后，一定有原因，补丁只能一时，不能一世，为了业务的正常运作，可以打补丁，但是一定要在下一步将这个问题揪出来。

这就比如，你去看医生，说我经常感觉冷。医生说你多穿点不就好了。你会怎么想？

程序员看bug，其实和医生看病是一样的，望闻问切，尤其是服务端，可以说每次修改都是动手术，一定要稳准狠。

验证和复盘

凡是问题，先复现，抓不到就拼命加日志，直到揪出来再改。

无法复现，就无法验证，一旦逻辑链不完整，就一定还有雷，总有一天它会炸。

每次解决之后，多复盘，再次思考有没有更优方案，这样你会因为一个问题成长多次，而且形成模型后，你解决问题的速度会快很多。

结语

如果有不对的地方欢迎指正。

如果有不理解的地方欢迎指出我来加栗子。

如果感觉OK可以点赞让更多人看到它。谢谢。