1. 程式人生 > >初級前端的求生之路(遇到問題時的一些思路)

初級前端的求生之路(遇到問題時的一些思路)

前言

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

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

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

需求

同樣的甲方,同樣的套路。要做一個刮刮樂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呈現給你,差別無非是尋找這個規律的難易罷了。