天天看點

高薪前端都具備的開發好習慣,學會了效率翻倍

作者:引邁資訊

格拉德威爾曾提出過一個“一萬小時定律”,即任何人從平凡到大師的必要條件,就是曆經1萬小時的錘煉,而這“1萬小時”也不是達到就行;如何構成,才是能否成為行業資深的關鍵。總結起來,就是四個字:多看+多練+刻意練習,那具體怎麼做才可以完成這“1萬小時”的錘煉?

優秀的Web開發人員工作效率更高,因為他們擁有豐富的經驗和良好的習慣。工作多年,我有一些自己了解的習慣分享給大家,都曾讓我受益,希望接下來的分享可以讓您的工作事半功倍。

高薪前端都具備的開發好習慣,學會了效率翻倍

耐心一行行 Debug,但别鑽牛角尖

寫代碼過程中總是會碰到這樣那樣的BUG,不解決渾身不舒服,沒解決好上司不舒服,可是解決bug這種東西很多時候都是看運氣的。這時候一定要有大局觀,給自己充足的時間耐心去Debug,哪怕是通宵不眠,如果來不及的時候則要立刻去求助,前面的路不要省,在适當的時候放棄執念就可以節省掉很多時間。

三思而後行

程式員主要不是寫代碼; 相反,他主要是向其他程式員寫有關他的問題解決方案的信。 對這一事實的了解是他作為工程師走向成熟的最後一步。 多問自己一些重要的問題:

  • 您有完成工作的流程嗎?命名變量時,您多久權衡一次可讀性和簡潔的設計?您是否建立PR(拉請求),以便比您更有能力的人進行代碼審查?代碼重構是您日常編碼習慣的一部分嗎?您是否為實作的每個功能建立文檔?編寫代碼時,過程多久進行一次基準性能測試?

有時,快速釋出版本真的很重要,但是花時間來做功能測試是很有必要的。而且永遠思考如何優化你的應用程式,這一點很重要。

高薪前端都具備的開發好習慣,學會了效率翻倍

成功的前端工程師很會善用工具

這些年低代碼概念開始流行,像國外的Mendix,國内的JNPF,這種新型的開發方式,圖形化的拖拉拽配置界面,并相容了自定義的元件、代碼擴充,确實在B端背景管理類網站建設中很大程度上的提升了效率。

我們在前端開發腳手架中,通常會建立一些通用的元件,然後在各個需要這個元件的地方進行引用,來提升開發效率。低代碼開發就是用較少的代碼來完成業務邏輯出來過程。有拖拽式的代碼生成器,靈活的權限配置、SaaS服務,強大的接口對接,随心可變的工作流引擎。支援多端協同操作,100%提供源碼,支援多種雲環境部署、本地部署。

開源位址:引邁 - JNPF快速開發平台_低代碼開發平台_零代碼開發平台_流程設計器_表單引擎_工作流引擎_軟體架構

代碼量少,系統的穩定性和易調整性都會得到一定的保障。基于代碼生成器,可一站式開發多端使用Web、Android、IOS、微信小程式。代碼自動生成後可以下載下傳本地,進行二次開發,有效提高整體開發效率。像“樂高”一樣設計你的門戶,依然是拖拽式開發,可一站式搭建:生産管理系統、項目管理系統、進銷存管理系統、OA辦公系統、人事财務等等。可以節省開發人員80%時間成本,并且有以建構業務流程、邏輯和資料模型等所需的功能。

高薪前端都具備的開發好習慣,學會了效率翻倍

我的母語無語...哦不,是英語

程式的世界是英文的世界,這個世界的問題,用它的語言去解決最高效,任何的技術問題。在作業系統上,把英語作為母語,在日常工作中,用英語作為搜尋語言。堅持這件事十年如一日,當你看到一個英文單詞,不必在大腦中做中文翻譯,其意了然于胸。

高薪前端都具備的開發好習慣,學會了效率翻倍

寫注釋,寫的溜還讓别人看得懂

代碼盡量多寫一些注釋。寫的溜還讓别人看得懂,也是一種能力。之前有個同僚很喜歡寫分隔線,某一個功能是從哪裡開始,然後到哪裡結束,但是我從來就翻不到我要的那一行,回回找回回找不到,多餘寫。

有必要寫的地方就比如to啊,或者說這行代碼可能稍微需要一些優化啊,有問題及時和後邊開發的人或稽核代碼的人解釋一下,解釋一下為什麼我要把它注釋,或者說我使用了一些比較冷門的第三方插件我想要解釋一下或者是附上一個文檔連結等等。

不斷的學習,為他人不斷提供價值,隻有這樣,才能走的更久更遠……這裡要特别強調,和後端保持及時溝通。如果遇到問題,最好先溝通解決好,别問我是怎麼知道的......

善于使用Bug追蹤系統

行内人都知道,想要做好軟體開發并非易事,這裡面還包含大量的功能需求、Bug報告以及使用者回報的内容都值得我們好好去摸索。也許有的時候你會收到有關需求的要點清單郵件,再好不過了,不是誰都願意花時間和你回報的。這時候就要善于利用Bug追蹤/項目管了解決方案,比如Basecamp(提供消息闆,待辦事宜,簡單排程,協同寫作,檔案共享)或Trac,讓你記錄 ticket(問題)或者不會遺漏重要事項。

你要追蹤這個問題發生的位置。為什麼出現這種情況,這次送出的ticket(問題)到底是因為哪裡出現的,然後解決它。

高薪前端都具備的開發好習慣,學會了效率翻倍

量命名盡量要語義化

變量命名盡量要語義化。甯可很長,也不要短的讓人摸不着含義。如果命名不明确,一旦變量名有很多的時候就會無從下手,搞不懂哪個是哪個了。這裡命名其實也包括變量名,方法名,檔案名,git的送出資訊,分支名等等,要讓其他開發者一看就知道你的方法是用來幹什麼的,這個檔案是講什麼的。别說别人了,你過一年回頭看你的代碼,也要重新過一遍才能搞清楚每一個功能是怎麼實作的,友善别人也友善自己哈。

格式化、格式化、還是TMD格式化

用VS Code去寫,ESLint、stylelint、Beautify、Code Spell Checker這些插件都裝上,尤其是在團隊開發的時候,誰用誰知道。。。 最後,注釋、格式化、格式化、還是TMD格式化

多關注前端技術話題,多看書,利用空閑時間多看其他大神寫的技術文章或者分享,多交流多借鑒。最後,我希望您可以有不同的看法和我分享,這段時間,我已經在整理有用的課程和視訊,可以點我首頁加關注mark住,讓我們一起成為高薪的程式員。