前言

一晃就快半年沒寫什麼東西了，在這段時間裡，我經歷了妻子從孕晚期到臨盆，孩子的滿月，兩代人的磨合…
好在，妻子是通情達理的妻子，長輩也是明辨是非的長輩，一家雖說不上其樂融融，相處也倒算得上融洽。

工作方面，托領導的福，知道我的情況後，一直沒給我安排什麼任務，所以也一直沒什麼值得讓我專門抽時間坐下來記錄記錄的東西。

在家裡情況趨於穩定的過程當中，我也開始陸陸續續接手一些專案。今天想說的事情，就是其中一個專案。

需求

同樣的甲方，同樣的套路。要做一個刮刮樂H5來發紅包。但是不同於尋常的刮刮樂，要求刮出來的內容是實時請求到的結果，且不願意用：刮完之後彈出一個彈層來展示結果這種方案。

思考

由於這個專案的後端是我的領導，所以在不考慮

1. 如果要在刮之前知道使用者的獎品，那麼在進入當前頁面的時候就應該請求了發獎品的介面，這樣帶來一個問題，如果使用者沒刮直接關閉了H5呢？
2. 如果在使用者刮的過程當中請求介面，那麼當高併發或者使用者自身網路情況較差的時候，勢必會出現：已經刮完了，但是沒有顯示東西。

看起來似乎是相悖的兩種情況，當時讓我一籌莫展，好在我加的有交流群，將問題描述了一下，群裡的大佬很快給我找到了解決方案。

其實很簡單，參考了螞蟻金服：

上面加一個按鈕，當點選了按鈕之後，視為你刮過了，不管你是否真的去刮，獎品都已經發送給你了。相信很多人有其他的解決方案，但今天我想寫的並不是如何去解決這個問題，而是：

該怎麼問問題？

假設我在群裡是這樣問的：

用canvas做刮刮樂的時候怎麼實時的去獲得刮出來的東西?

甚至是這樣問的：

刮刮樂怎麼做？

那麼我很可能被一群大佬直接懟回來，因為這樣的問題：

• 答案太多
• 太簡單
• 問法太籠統

我當時是這樣問的

我在問之前思考了幾個問題，我最多能做到哪一步？怎樣能把問題和背景儘量描述清楚？怎樣提問能讓被提問者明白我實際上是想得到什麼答案？

最初我也是個什麼都不懂的小白，在看過張鑫旭大神的這篇文章後得到了一些啟發：

縱然有很多人技術大牛都有樂於助人的品質，但就如文章所說，大牛們很可能也是在工作的碎片時間，甚至私人的休息時間，通過郵件、討論群等等一些渠道去回答一些新手的疑問，那麼這個時候，他肯定會優先回答那些有禮貌、條理清晰、帶著自己思考的人發來的問題，如果你在高中數學課解一道幾何大題，跑去問老師圓的面積怎麼求，我想老師肯定會懟你一句：自己回去翻課本！（至少我是這樣…）

1.對於太簡單百度google隨便能搜到的問題，請節省別人的時間，同時也節省你自己的時間，一次忘了就查第二次，兩次忘了就查第三次，查的多了印象深刻你也就記住了。

2.對於有一些水平的問題，求人以魚，不如求人以漁。自己完成了30%，別人給予你30%的指點，促使你把剩下的40%完成，這樣下次再碰到類似的問題，或許你就可以自己思考到50%。迴圈往復，總有你可以獨立解決的一天。如果你總是在0%就祈求別人幫你完成剩下的100%，那你永遠也只能從0%開始。

3.對於一些複雜的問題，切忌籠統的提問。如果你直接去問尤大，vue是怎麼開發的…尤大嘛，你們懂得。將問題細化，或者將背景、需求描述清楚，不要讓被提問者有心幫你，卻無從開口。

怎麼自己去解決問題？

當然，這裡的問題指的是專案中的bug。學會怎麼提問，只是其中一種解決問題的方法。從長遠來看，還是得培養自己去解決問題的能力。

相信很多同學的日常開發過程中，都遇到過之前沒見過的bug，其中一大部分通過上網搜尋可以直接解決，另一小部分在搜尋到的內容中稍作變通也可以解決，還有極小一部分，怎麼搜都找不到相關的內容，我就來分享一下對於這些問題我的經驗。

1. 首先排除低階錯誤：諸如變數、類名拼寫錯誤，資源引用路徑錯誤等等。通常這種情況F12的報錯可以輕鬆解決問題，況且，用再智慧的IDE開發也會有拼寫錯誤的時候，誰會專門把自己的一次拼寫錯誤給記錄下來？
2. 抓關鍵字、自己總結搜尋：看到F12列印了一大串紅色的Error，不要方，也不要整段copy下來去google，很可能一大段中只有一句是真正有用的資訊。具體例子我一時也想不到，或許日後想到了再來補充。
3. 對於沒有報錯，功能卻表現異常：這時候就很難受了，不過也有應對方法，尋找100%復現bug的方法，或者摸索bug的變化規律。還是文章開頭提到的專案，使用canvas的globalCompositeOperationAPI做刮卡清除canvas畫布內容的時候，發現滑鼠觸點的位置與實際canvas清除的起始位置並不在一起，後者在前者的右下方，通過反覆比較發現，兩者的位置關係類似於“斜投影”，而“光源”則位於兩者連線的左上部分。而左上角正是HTML文件的左頂點——javascript獲取點選事件的（0，0）原點。此時我恍然大悟，出現問題的原因正是因為我獲取的觸點位置並不是相對於canvas畫布，而是相對於整個頁面左上角的座標。只要設定清除的起始位置時，橫座標減去canvas元素的offset().left值，縱座標減去canvas元素的offset().top值即可。（實際上這個問題網上已經有了解決方法，只不過我這個時候已經習慣了遇到問題先自己先鑽研，實在不行才會去別的地方去尋找答案）
4. 對於沒有報錯，同時bug規律也無跡可尋的情況（真的無跡可尋嗎？），這個時候可能真的需要靠運氣了。我之前曾寫過一篇部落格，有一個bug，只有在最小化或後臺執行你的瀏覽器時才會發生，且不說在實際生產環境當中會不會有使用者復現這個bug，單說這個復現條件，恐怕若不是我運氣好，我也不會發現。總之，很多人都說計算機笨，你告訴它什麼它才會做什麼，在我看來，計算機同樣也是聰明的，只要你寫的程式碼有問題，它肯定會在同樣的情況下，把bug呈現給你，差別無非是尋找這個規律的難易罷了。