科技

這些程式設計習慣get一下,效率提升,bug減少

當年我還阿里工作的時候,P10大佬告訴我,年輕人不要天天想著整高大上的技術,把業務程式碼寫得無懈可擊也是一種技術的體現。同樣是寫業務邏輯的,為什麼有些人月薪40K,而有些人就月薪7K呢?一個程式設計師除了技術牛逼,靠譜,也是衡量一個程式設計師重要的指標。Bug是每個程式設計師最害怕的事情了,沒上線還好,萬一上線了造成線上故障了,那就完蛋了,就只能祈禱不要上通報郵件了。

怎麼樣才能把程式碼寫得無懈可擊呢?經過這麼多年的積累,自己也行程一些方法,拿出來跟大家分享分享希望能共同進步。

首先當然是理清業務,理清模組的呼叫關係。很多人會懶於寫技術方案,這其實是一個很不好的習慣。當然,我們也要分清需求的規模,如果需求的開發聯調時間超過2天,那花半天時間出來整理技術方案,理性模組的呼叫關係,把大致的時序圖跟流程圖畫一畫,能夠讓你在開發的時候行雲流水。有的人會覺得就實現一個功能,為什麼非把自己整得這麼麻煩,不煩先用這種辦法堅持一段時間,你會對你現在做的業務的認識會有質的變化。

第二是提前想好邊界條件,設計一些測試用例。不知道你有沒有這樣的經歷,程式碼寫完了,設計得很完美,程式碼結構很清晰,但是因為忘記考慮一些邊界情況,導致後面bug頻出,只能拼命打補丁,拆東牆補西牆,最後把程式碼改成四不像。一個優秀的工程師,應該在開發之前就能想到容易出坑的地方,哪些需要在設計上去規避,哪些需要產品上去妥協,哪些如要在編碼的時候注意。

第三是編碼習慣,種瓜得瓜種豆得豆,有些人寫程式碼想到什麼就寫什麼,想起什麼名字就起什麼名字,可能過了3個月,都不知道這個程式碼是自己寫的,這些其實都是很容易挖坑的。一個比較好的編碼習慣是寫完程式碼不要著急編譯或者執行,先肉眼檢查一下自己的程式碼,看看是否有因為自己編碼疏忽寫出來的奇怪語句,這個小技巧真的非常實用,對於重新梳理自己的編碼思路非常有幫助。另外一個是不要放過Warning的資訊,有時候一些小細節,例如某個變數沒有使用這種低階又很難查的錯誤,都會在Warning裡面體現。另外就是多寫註釋,這個註釋不僅給別人看,更給自己看,Review程式碼的時候要注意是否有按照註釋的去實現。

第四如何應對需求變更跟需求迭代,說真的,這兩個才是真正的Bug之源。很多人都說外企效率高,中國的IT公司效率低才需要996。這話說得不無道理,但效率低是程式設計師的事情麼?很多時候都是因為需求變更引起的,要遇到一開始就把握市場的產品跟老闆真的比較難。那麼如何應對需求變更呢?這個時候更加體現了第一跟第二點的重要性了,只有真正的理解了需求,把握整個架構,才能夠知道需求變更中的變與不變,而不會忙中出錯。

第五打好日誌,一個好的工程師不僅要關注功能是否正常,而且要關注整個流程中的各個介面的耗時,輸入輸出是否有異常,打好日誌不僅能夠更快速的定位到問題,也是一個對自己業務一個鞏固思考的過程,什麼地方容易出錯,什麼地方的中間狀態最為關鍵,把這些的思考好,真出了什麼問題也不是什麼問題。線上故障什麼最鬱悶,就是無日誌可查,只能夠看程式碼靠猜測。測試反饋過來的bug,本來只要5分鐘能解決的事情,因為沒有日誌,重現到發現問題可能就花了1個鐘了。

以上,都是普通人能夠做好的,或者通過自身的努力就能做好,就看你願不願意花時間。除此之外,還有像對架構的理解,對框架的熟悉,這些並不是每個都能夠立馬掌握得很好的。如果對需求覺得繁瑣,覺得自己的大部分時間都花在實現功能上,不凡站高一個角度,看看是否是因為架構的問題、是否有更成熟便捷的框架?只有理論沒有實踐的架構都是空中樓閣,只有當你深受其害的時候才能夠看清楚新的方向。

最後,希望大家都能寫出沒有BUG的程式碼,薪水蹭蹭漲。不要只滿足實現手頭的業務,那樣只能夠緩慢地長經驗,用優秀的習慣去做事,會更快提升你的等級。

Reference:科技日報

看更多!請加入我們的粉絲團

轉載請附文章網址

不可錯過的話題