⽂不對題的記拆分任務對解決問題的重要性

在上個項⽬組時因為隊友們都特別給力，加上⾃⼰己還沒想清楚很多事情所以養成了了⼀個很不好的習慣，遇到不懂的不知道的張⼝就問。

年底總結之時思考了很多，一年時間我學到了很多前端的技術，但其實更多偏向於基礎。加之⾃己懶散，很多事情一知半解。對於去年的我來說，每當遇⻅了不能解決的技術問題時，抬頭問問身邊的大神隊友便能解決。但其實這樣的便利雖然短時間內我解決了問題但並沒能讓我學到關鍵的東西。雖然看起來我做卡速度不不錯，程式碼貢獻度不錯，但我只知道怎麼做能解決這個問題並不知道為什麼能解決。就如同最近遇到的問題，我知道前端項⽬打包可以⽤webpack, 但不知道為什麼需要打包，為什麼選用webpack⽽不是別的工具以及webpack如何配置，每一個操作帶來什麼結果。(立個flag:解決了webpack的問題後再寫一篇)

後來仔細想想，我為什麼會越來越依賴求助他⼈來解決問題，⽽不是⾃⼰先嚐試解決。原因有三:

1. 在發現我解決不了問題或者思維混亂的時候我容易慌亂，迫切的想要快速解決問題即使這個工作並沒有那麼著急。

2. 在我試圖解決問題時沒有章法，常常找不到解決問題的⼊口。導致在google drive develop時 很難使⽤正確的關鍵字進行搜尋，在搜尋解決⽅方法上花了⼤量的時間其結果還無法滿足。

3. ⾃己⼀開始就拒絕了思考解決問題的過程，⼀⼼心只想要個解決問題的方法。一旦解決就不再思考這樣解決的原因

綜上，今年在新項⽬目上決定做一些必要的改進。首先逼著⾃⼰在遇到暫時想不到解決方法的問題的時候⾃己解決，忌張⼝問⼈。心態轉變過來後感覺每天的狀態變的比以前更忙碌了了。但通過⾃己的思路路解決了當下遇到的問題，還是很不錯的。

嚐到甜頭後繼續保持，不過沒⼏天暴露了上⾯的第二個原因:很難定位到問題並找到解決的答案。 如之前一篇統計測試覆蓋率的文章⾥裡提到的，我想要統計後段測試覆蓋率，想要在prepush時計算測試覆蓋率並限制提交如果覆蓋率不達標的情況下。在google了了好久之後依然沒有找到想要的 解決方案。因為我看⼀遍文章發現不完全滿足我想要解決的東⻄就不再細想。並且我想要的答案太多，其實很難一步到位的找到完全契合你需求的答案。畢竟每個情況都不一樣，解決方案都是各⾃挑選後堆砌起來的。況且我的搜尋關鍵字還是如何在prepush時得到測試覆蓋率。。

於是我可恥的張⼝口問了一個魔鬼。。。魔⻤說⾃己google去。。在捱了⼀頓罵後我意識到我搜索的根本就不對，因為我⾃己都沒有想清楚我要的是什麼。現成的一鍋端的思路，等著別人直接的答案，我似乎又犯了⽼毛病，只不過物件換成了google而已。經指點我開始拆分我想解決的問題。

1. 程式碼語言為java，構建工具為gradle

2. 單元測試覆蓋率

3. 如何配置prepush時要做的事

4. 最簡單的目的是要能視覺化當前的測試覆蓋率

這是我的劃分出來的task，那麼我理解的是既然我的目的是視覺化我的後段測試覆蓋率，那⼤可不必糾結於是否跟prepush相關聯，首先解決如何統計在gradle下的java單元測試的測試覆蓋率問題就可以了。

果然這樣快多了，具體解決方案⻅上篇。此篇完全為提醒⾃己吸取教訓，在以後遇到籠統的⼤問題時先正確劃分task再根據目的⼀個⼀個解決問題。⽽不是一開始就想解決所有的問題。(在後⾯面抽取form時依舊犯了了這個毛病。。看來反省的不深刻)