一、背景
老手，大牛都是从新手走过来的，偶尔也会在群里解答一些问题。
但是确实很多新手的提问让人摸不着头脑。
常见的是问题很笼统，好像大神都会特异功能，都可以穿越时空，逆转到过去来到他的电脑旁看到了事情的经过一样。
描述不清楚，没有配图，没有交代清楚背景等等。
本文结合自己的体会，提几点建议。
二、建议
2.1 参考
这篇github描述《高效提问》写的就不错
https://github.com/mmflys/blog/blob/master/common/EffectiveAsking.md
强调描述环境、操作描述、期望、现象
注重问题的清晰度给出更多的线索，阐述的顺序根据序号递增，根据重要性递减。
2.2 我的建议
（1）自己先做出一些尝试！！
最重要的一点是，要分析不要猜测，分析可能的情况，然后去印证！！！
- F12大法，根据请求参数，响应码，响应数据等定位是前端还是后端问题。
- code review分析代码逻辑是否有问题
- 使用各种命令辅助排错，比如dubbo命令查看服务是否可调通，git命令拉新分支尝试解决问题，mvn或gradle命令编译是否可以通过，查看依赖树等等。
- 控制变量法，比如新增了3个类出错，可以依次删除，看哪一步开始报错。
- debug大法：断点、查看变量，单步，watch，查看调用栈等
- 日志大法：查看日志或者打日志方便排错
- 单元测试大法：编程的时候就应该多写单元测试，尤其推荐mokito来mock接口检查逻辑是否正确。
- 换环境大法：换浏览器，换个项目等等
- 先本地测试好再发预发或者线上
- 官方文档大法：如果是用法问题，配置问题，尽量查官方文档，看看这一块怎么用，是不是自己用错了。
- 搜索引擎大法：自己分析不出来把报错信息复制到搜索引擎，看看别人的分析步骤和解决方案。能科学上网尽量先谷歌，不行再百度。外国人的答案更多，更靠谱。
- 寻求帮助，最后才是寻求帮助
通过这些步骤，绝大多数问题都已经被解决。如果需要寻求帮助，去群里提问也可以给出自己的排查方法，给出更多的线索。
重点参考我这两篇文章
《代码排错和避免错误的正确姿势》https://cloud.tencent.com/developer/article/1868978
《记一次maven jar包冲突的排查和解决过程，干货分享》https://cloud.tencent.com/developer/article/1870401
（2）描述问题自己先想如果自己不了解背景，单纯看描述自己是否清楚是啥意思？
如果自己都描述不清楚，别人怎么给你解决问题呢？
如果觉得有歧义换一个说法，如果觉得笼统，举个栗子。
很多人问了半天，想问的和自己发的完全不是一回事。
比如“前端调用一个接口不通，咋回事呢？”
那么别人会想：
- 调用的是dubbo还是http接口？
- 如果是http请求，请求的Url是啥？响应码是啥？参数是啥？
- 如果是dubbo接口，自己在服务器或者本地先telnet调用看看是否成功
如果你能够给出，f12的截图，响应码是404 显然极可能是url写错了，或者如果是新的接口，可能后端分支发布错了等等。
我们既然是请教别人的问题，本来认真回答的就没几个，要让解答的人能够更快速的了解我们的情况，帮助解决问题。
（3）重点给出哪些信息？
如果是具体的错误：重点是报错信息，以及涉及到的自己代码截图。
（4）如果别人没有给出好的解决方案
如果没有能够给出好的解决方案，最终通过某篇博客，或者最终自己解决了，一定主动在群里分享解决的方法。这样其他人也可以增长经验。
三、感受
（1）我们提问要力求精准，描述清楚，让别人可以快速了解自己的问题。
（2）一方面我们要特别重视排错积累和实践方法。要分析问题，而是瞎猜。
因为开发就会遇到千奇百怪的问题，如果不能掌握排错的方法总是依赖别人，就很难进步了，而且不可能有人一直闲着一直帮你。
很多人加群总潜意识里认为是来学东西的。真正分享点排错的文章，反而也没几个人重视。也没几个人看，没几个人点赞收藏。
（3）加强基础知识的学习，很多问题都是Java基础不扎实，不熟悉一些框架的用法和原理导致的。写业务代码的同时，私底下要主动学习。
如果觉得本文对你有帮助，欢迎点赞，欢迎关注我，如果有补充欢迎评论交流，我将努力创作更多更好的文章。 另外欢迎加入我的知识星球，知识星球ID：15165241 一起交流学习。 https://t.zsxq.com/Z3bAiea 申请时标注来自CSDN。
