前言
本文主要写给目前在我技术交流群里的同学。
为什么要正确提问？
对提问者而言，好处在于：
- 更清晰地描述清楚自己的问题；
- 问题得到解决的概率更大
- 被提问者更愿意解答你的问题
对被提问者而言，好处在于：
- 花的时间更少，去解决问题
- 心情更舒畅点，更愿意去解决问题
怎么样才算是一个正确的提问方式，我的建议是，设身处地，仔细想想，假设自己是那个被提问的人，自己是那个要解决问题的人，需要提问者，提供什么样的东西，才能更好地解决问题？
这个大家其实工作中，学习中都会碰到，比如，你的同事要请教你一个问题，你问对方什么问题，对方支支吾吾说不清楚，你听不明白，这问题还能解决吗？
再想想，测试的同学提bug时，是不是好多就是图一贴就完事了，问题什么时候发生的，什么场景发生的，哪个用户触发的，这些信息完全没有，你说，你怎么解决？
我们这边的测试，每次就是贴图，也不说把出现问题的那个单号，用户id之类的复制出来，每次我们开发同学改bug，都要照着图去敲单号？你想不想吐槽？
扯了这么些，其实就是说，我们要尽量地，在职场，在生活中，去做一个靠谱的人，做一个同事喜欢的，愿意和你合作的人，和你合作起来很愉快的人。
以前，我问同事问题，也是qq里直接贴图，后来一个同事就和我说，贴文字啊，不然对方还要敲一遍。
恩，这就是同理心。
正确的提问，核心就是要有同理心。
下面说具体的，java工程的提问方式。
一、使用maven工程
先加个重点，请去掉target目录，那个很大，微信或者qq，传都要传半天，而且有时候是在手机收的文件，一般看问题肯定是电脑上，没有去掉target目录的话，一个工程，几十上百兆很正常，这时候，要把微信上收的文件，转到电脑，就要花几分钟。
java后端，以maven工程居多，所以，一般来说，一个标准的maven工程，长这样：
就是一个文件夹，然后里面一个pom，一个src文件夹。具体可以看下面的图（来自于网络：）
这样的maven工程，不管是什么ide，都是可以直接import的，这样的话，解答问题的人，拿到这个工程，可以直接导入自己的ide中。
如果是多模块聚合工程，一般长下面这样：
不知道怎么搭建聚合工程的话，可以看我以前的一篇文章，比较早了，写得一般，不过还是可以看看。大家也可以自行搜索。
https://www.cnblogs.com/grey-wolf/p/6606334.html
二、数据库sql
第二个要点，是工程涉及的sql脚本，一些问题可能不涉及数据库，那就算了。有的是，没有数据库，根本启动不了；或者，启动后，也没有数据，去进行问题的测试和复现，这时候，就必须提供sql脚本。
一般sql脚本格式如下：
- 建表sql
CREATE TABLE `user` ( `id` int(10) NOT NULL, `username` varchar(200) COLLATE utf8mb4_unicode_ci DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - insert等初始化数据的语句
insert into `user`(`id`,`username`) values (222,‘ssss‘); - 建库sql
CREATE DATABASE /*!32312 IF NOT EXISTS*/`test` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci */;
一般，以上sql，都可以直接通过navicat等工具生成。大家可自行搜索。
三、问题的复现步骤
一般来说，针对web工程，很多问题，都是通过api请求去触发，比如平时我们遇到的各种bug；少部分是定时任务等触发。
如果是请求触发，就需要提供：请求的接口，路径，参数是什么样的，因为不同的参数，可能一个能复现问题，一个就不能。
可以像下面这样提供：
我上面只是举个例子，大家不要用图片，尽量用文字，比如，如下的curl格式，就能完整展示请求的内容：
curl -i -X GET ‘http://127.0.0.1:8080/gym_war_exploded/user/borrowEquipment.do?eqId=54383a62-0a45-46b6-b1b0-c1be58446a4f&userId=c5d759d9c8f8407992ded888eebaf19b‘
四、尽量去掉无关因素
这个是加分项，前面第一点我说了，现在主要用maven工程，大家知道，下载依赖还是需要不少时间的。
很多时候，你给一个完整的工程过去，里面几十上百个依赖，对方下载都要下半小时。。。你说这怎么搞？
所以，大家尽量提供一份：能复现问题的最小工程。
简单就是，pom.xml里，不要大而全，尽量按需要来，这也是我平时工作中很注意的一个点，包少了，打包都快得多，启动也快得多，调试也快些（这时候可能需要加载或扫描的类、jar包就少了）。
五、其他
todo，其他待补充。
总结
有的同学觉得，我提个问题，也太麻烦了。当然，问题从来都不简单，尤其是，信息还不够的情况下。如果真心希望问题得到解决，那肯定是要花点时间的。
原文地址：https://www.cnblogs.com/grey-wolf/p/12656429.html