代碼精進之路讀后感(一)


最近開始看范學雷老師寫的代碼精進之路,看了第一篇之后就覺得非常值得學習,所以特意記錄一下

 (我去,咋把點擊查看原網頁搞上了,無所謂了,你盡管點,能點進去算我輸)

 第一篇論述的從條件運算符入手來講什么是好代碼,其實在工作中,我個人還是很鍾意用條件運算符,因為從學習條件運算符那一天開始我就覺得這個看上去比ifelse精簡多了,所以之后就一直在用,但是今天看完第一篇文章之后,我對三元運算符又有了新的認識。

 舉一個小例子,在工作中我最常用的條件運算符

a==b?c:d

  類似於這種,感覺看上去比ifelse要簡潔很多,但是今天范老師給了一個例子

return x >= 90 ? "A" : x >= 80 ? "B" : x >= 70 ? "C" : x >= 60 ? "D" : "E";

  恐怖不恐怖,如果你不是有一雙鈦合金狗眼,這里面的邏輯怕不是要用筆來畫畫才能捋清

   

那這個樣子就不如我們來使用ifelse了,雖然代碼看上去會多一點,但是便於理解啊,起碼能直接看清楚邏輯

而且范老師還有一個觀點是非常值得學習的,堅持使⽤最直觀的編碼⽅式,⽽不是追求代碼簡短

其實我過去還是很追求代碼的簡短,能用一行代碼實現的操作絕對不用兩行,其實現在想想很是很年輕啊,舉個直觀的例子,之前寫代碼的時候,寫的時候只有我和上帝知道是什么意思,人家都說不出半月,就只有上帝知道代碼的意思了,我只能說太天真了,我忘記自己的代碼和魚一樣,七秒足矣,所以范老師這個觀點直接捅我心窩子里去了。

當我們寫代碼的時候不能盲目的追求簡短,在能直觀的看懂邏輯的前提下適量的簡短代碼挺好的,but不管三七二十一,只為了簡短代碼而瘋狂的精簡,而不考慮別人能不能直觀的看懂精簡后的代碼,我只能送你一句話,少俠練個鐵布衫吧,防止被同事懟死

 

 減少錯誤、節省時間,是我們現在選擇編碼⽅式的⼀個最基本的原則

作為一名合格的bug制造者,我想減少bug節約時間的重要性不必多言了,誰還沒有被老大懟着噴的經歷,所以加快開發節奏減少被噴的概率是我們必然要去追求的事情

當做一個功能的時候我們一定要考慮一下子如何在滿足需求的前提下最快的做完!

好的代碼又具有一下特點:

    1. 容易理解;

    2. 沒有明顯的安全問題

    3. 能夠滿⾜最關鍵的需求

    4. 有充分的注釋;

    5. 使⽤規范的命名;

    6. 經過充分的測試

壞的代碼的特征

    1. 難以閱讀的代碼;

    2. 浪費⼤量計算機資源的代碼;

    3. 代碼⻛格混亂的代碼;

    4. 復雜的、不直觀的代碼;

    5. 沒有經過適當測試的

我們在開發中盡量寫一些好的代碼,這樣后期維護起來也舒舒服服

 

文中還有一個非常棒的觀點:最適合當前現實環境的代碼,才是最優秀的代碼

例如一個創業型的公司在經濟實力人力資源都有限的前提下盲目的照搬大公司的成熟的軟件開發流程的,這樣有大概率會浪費時間和資金而沒有相應的結果。

最后總結一下子,優秀的代碼需要具備三個特征: 經濟、規范、安全

經濟,規范前面都說了一下一下,這個安全是啥子回事。安全還有我說?信不信我錘你啵,你想剛搞好一個系統剛上線,公司正在美滋滋使用,蜜月期還沒過,就被人干掉了,就跟剛結婚沒多久,媳婦被人拐跑了,這誰能受得了,所以說安全也是很重要的,起碼你得保護好自己的媳婦吧

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM