前端開發者應該養成的開發好習慣

語言: CN / TW / HK

1.合理命名

合理命名,這裡的命名包括變數名,方法名,檔名,git的提交資訊,分支名等等。
起的名字應該讓其他開發者一看就知道你的方法是用來幹什麼的,這個檔案是講什麼的,你這批提到的程式碼具體內容更新了些什麼東西,新建了這個分支又是用來幹嘛。

當然也不一定是為了給別人看,就比如我在看我自己一年前寫程式碼的時候呢,也要重新過一遍才能搞清楚每一個功能是怎麼實現的,這時候如果你裡面的命名都比較正常的話,這樣找到要修改的地方就會比較快。


或者如果說當產品迭代多了之後呢,想要追溯到沒有某一個具體功能的一箇舊版本的時候,如果你git裡邊的描述都非常清楚,也會比較容易的能夠找得到。

2.合理的寫註釋

註釋是一定要寫的,只不過不要寫得太多。我以前的話就很喜歡寫那個分隔線,就是某一個功能是從哪裡開始,然後到哪裡結束,因為我老是翻半天都找不到我想要找的那一行程式碼,後來有一天我知道寫分隔線其實是不太規範的,就有點類似於你可能每寫一兩行程式碼就寫一行註釋,解釋一下他是幹嘛的一樣,就比較多餘,如果說方法名,變數名都起得非常的精準的話,別人其實一看就知道是幹什麼的就不用額外去解釋,比如說你一個獲取使用者列表的方法名叫getuserlist,別人一看這個方法都知道他是幹嘛的。

HTML裡頭的class名ID名也是一樣的,比如說使用者列表裡的標題class或者id叫做比如說user list title會比你直接叫做title要好找很多,如果命名可以做到非常精準的話,其實就可以通過搜尋關鍵詞去直接定位到那行程式碼,就不用去寫什麼分隔線之類的。

我覺得比較有必要寫註釋的地方,就包括比如說to啊,或者說這行程式碼可能稍微需要一些優化啊,然後存在一些問題什麼的要給後邊開發的人或稽核程式碼的人解釋一下,或者我註釋掉了一段程式碼,然後解釋一下為什麼我要把它註釋掉,或者是一些比較複雜的功能,不能夠完全通過命名去解釋清楚的,或者說我使用了一些比較冷門的第三方外掛我想要解釋一下或者是附上一個文件連結等等

3.儘量分元件

元件化是前端開發裡面一個核心的概念,把頁面上的每個模組單獨分出來,作為一個單獨的元件不僅可以方便今後把單拎出來重複使用而且也可以避免某一個檔案裡面的程式碼太長,導致我又要寫分割線了。

我在自己剛剛開始做開發的時候就經常會省時間嘛,就偷懶就把所有東西都寫一個檔案裡,短期看來呢確實是挺省事的所以就往裡頭加的功能越來越多,那個檔案裡的程式碼就會變得越來越長,你要找到某一行程式碼就變得更加不方便,而且隨著一個檔案裡的功能點越來越多你想要去拆分成不同的元件,也就越來越麻煩,牽一髮而動全身所以你懂吧,問題呢就滾雪球形成一個閉環所以說如果在剛開始寫的時候就養成分元件的習慣後續就不會有這樣的困擾了

4.不要讓自己卡在小的bug上

我是一個有一點完美主義的人,一旦遇到了bug解決不掉了就渾身不舒服。可是解決bug這種東西很多時候都是看運氣的,就很難保證說我多長時間我就一定能搞完,我發現了這個時候就一定要有大局觀,在適當的時候放棄執念就可以節省掉很多時間,想想你現在在做的這個功能的實現主要是依賴什麼,是不是這個bug,還是別的什麼東西。

就比如說作為一個登入頁做到驗證使用者收的那個郵箱的格式的時候出現了bug,我就一直卡在那裡,但是吧登入功能的實現在老闆或者是普通使用者看來,就是你輸了使用者名稱,密碼之後可以登入成功,或者說他告訴你登陸失敗了,那其他東西也很重要但是相較於此來說還是比較次要的,所以說接下來呢,把登陸介面給它接上,其實對於完成這整個任務來說更重要。

其次就是如果我先跳過這個bug先去做那個更關鍵的工能,心理上來講也會比較的好受一點,畢竟在這整個的功能只實現了20%的時候,被一個bug卡住,和在整個功能都完成了90%的時候被這個bug卡住,相比後者壓力會相對小很多。

5.找一個時間段是可以專注於工作的

尋找一個時間段是可以專注於工作。程式設計師在工作的時候很忌諱被打斷,就是我們在構思一個功能怎麼樣去實現的時候,通常來說都是需要集中思考的,這也是為什麼我們很容易陷入就是發現了一個bug就一定得去死磕他想要把解決,至少對我自己來說是這樣的。

如果我在寫程式碼的時候,被一個很小的事情打斷了,比如說有人來找我聊天,然後我開始分心去加入這個話題的時候還要重新再回到這個工作狀態,我又要去花一些時間,重新進入到我這個邏輯思維裡頭,你們懂我意思嗎?

所以通常我再給我自己安排工作的時候,如果我知道我接下來可能要去做一些新功能或者是要去解決一個bug的時候,我會給自己至少至少三個小時的時間是完全沒有任何干擾的,這樣可以保證我最大化的提高自己的工作效率。