前言
本文主要寫給目前在我技術交流群里的同學。
為什么要正確提問？
對提問者而言，好處在於：
- 更清晰地描述清楚自己的問題；
- 問題得到解決的概率更大
- 被提問者更願意解答你的問題
對被提問者而言，好處在於：
- 花的時間更少，去解決問題
- 心情更舒暢點，更願意去解決問題
怎么樣才算是一個正確的提問方式，我的建議是，設身處地，仔細想想，假設自己是那個被提問的人，自己是那個要解決問題的人，需要提問者，提供什么樣的東西，才能更好地解決問題？
這個大家其實工作中，學習中都會碰到，比如，你的同事要請教你一個問題，你問對方什么問題，對方支支吾吾說不清楚，你聽不明白，這問題還能解決嗎？
再想想，測試的同學提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，其他待補充。
總結
有的同學覺得，我提個問題，也太麻煩了。當然，問題從來都不簡單，尤其是，信息還不夠的情況下。如果真心希望問題得到解決，那肯定是要花點時間的。