通常我们区别一个人是新手还是老手，可以看一下几个方面：
- 新手，百度的主要是语法。老手，Google的基本是解决方案或者疑难bug。
- 新手，一顿操作猛如虎，一旦发测全是bug，甚至有需要颠覆设计来修改的。老手，先想，甚至画画图，不紧不慢开始写，甚至有写几行，喝几口茶的感觉，但是写出来的稳得一批。
- 新手，面对bug，首先就是猜，应该是那里，改了再说，恩，好了，然后其他地方出问题了。老手，先分析代码，然后看日志，复现，修改，再复盘一下。
那么，如果我上面的都做到了，就是老手了么？不一定，还有一个很重要的因素---解决问题的能力。
可以说，工作3-5年，上面3点基本都能达到，毕竟熟能生巧，但是解决问题的能力，真的是天赋和努力都需要。
同样一个问题，新手只想怎么打补丁，老手想的是怎么从源头解决而不影响大局，但是大神，往往会想有没有更优方案。
举个例子，sql错误秒杀系统超发了。
- 新手可能一看，哦，这个SQL有问题，改一下。
- 老手一看，这么改可能有并发瓶颈，优化一下。
- 大神一看，这个可以加个队列，解决并发问题，然后对于客户端体验怎么优化一下，产品可以提供一下响应的友好提示等等。
简单的说，就是格局和视野不一样。
那么，我们要怎么锻炼我们解决问题的能力呢？
事无巨细，悉以咨之。
学习的最好途径就是经历，我们可以抓住工作中遇到的每一个问题，看看别人是怎么解决的，想想有没有更好的方案，记下来自己复盘。
很多论坛上的求助，或者大佬们对于行业痛点的解决方案，多看看，体会一下他们的优劣和特点，同行就是最好的老师。
最后就是多思考。
只要思想不滑坡，办法总比困难多。
优化流程
很多时候，我们可能会疑惑，为什么别人能想到我想不到。
首先是知识储备的问题。
你永远想不到你并不知道的东西。
也就是贫穷限制了我们的想象力，这个需要我们多积累，多看多学。
其次就是思考模式的优化，这里主要谈谈这个。
场景分析，抛开程序思维
我常常开玩笑：如果解决不了，就干掉那个提需求的人。
意思就是如果一个需求或问题比较棘手，可以先问问提需求的人，原始需要是什么，可能会找出一个程序实现简单，而且更符合原始需求的方案。
虽然这种机会很少，毕竟产品和程序不打起来已经不错了，但是有时候真的有奇效，会减少很多开发时间。最起码你了解了为什么要做这个东西，也不至于怨天怨地。
定义问题，抽象模型
想要解决问题，首先要明白到底是什么问题。
比如，CPU占用非常高，我们把耗CPU的干掉一些把。
首先，CPU占用高并不是问题，CPU就是拿来用的，不卡就不用解决。
其次，优化不等于干掉，先找出有没有空耗CPU的，其次再分析有没有低效利用CPU的。
最后，在确定解决方案。
如果方向错了，怎么努力都是错的。
刨根问底
比如一个接口经常超时，有人说，超时时间改长点不就好了。这里你会也许觉得很挫。但是在实际工作中，这种补丁数不胜数。
一旦你选择了妥协，那么就会一直妥协。久而久之，你就会变得不愿意思考，逐渐平庸。
任何现象的背后，一定有原因，补丁只能一时，不能一世，为了业务的正常运作，可以打补丁，但是一定要在下一步将这个问题揪出来。
这就比如，你去看医生，说我经常感觉冷。医生说你多穿点不就好了。你会怎么想？
程序员看bug，其实和医生看病是一样的，望闻问切，尤其是服务端，可以说每次修改都是动手术，一定要稳准狠。
验证和复盘
凡是问题，先复现，抓不到就拼命加日志，直到揪出来再改。
无法复现，就无法验证，一旦逻辑链不完整，就一定还有雷，总有一天它会炸。
每次解决之后，多复盘，再次思考有没有更优方案，这样你会因为一个问题成长多次，而且形成模型后，你解决问题的速度会快很多。
结语
如果有不对的地方欢迎指正。
如果有不理解的地方欢迎指出我来加栗子。
如果感觉OK可以点赞让更多人看到它。谢谢。
