一份擁有良好可讀性和拓展性的代碼是專案里的良藥，它不僅看著舒服，改起來也方便，甚至還能重用，各模塊邏輯分明，“見碼知功底”，而要達到高手那種簡潔有力的境界，需要進行大量的總結和練習，今天我們就來談談如何寫出優美的代碼，
命名
好的命名應該具有如下特征：
1，意思正確，這是最基本的要求，不要掛羊頭賣狗肉，詞不達意，要一眼就知道什么意思，就算一眼看不出來，復制到有道詞典翻譯一下也能知道什么意思；
2，單復數分明，如果是一個陣列，要么加s/es結尾表明其是復數，要么加入list表示它是一個陣列，如cars，carList都可以表達一個車的串列；
3，慎用縮略詞，縮略詞可以讓我們的命名更加簡潔，但是一！定！要！是！業！界！通！用！縮！略！詞！比如info原意為information，msg原意為message，fn原意function，conf原意config等等，這些縮略詞都是業內傳統了，大家都知道什么意思，切記不要自己亂造縮略詞；
4，有具體含義，根據業務場景去命名，而不是根據抽象命名；比如getUnreadMsgList，一看就知道是獲取未讀訊息串列的意思，而getData這種說了跟沒說一樣，缺乏具體含義，
注釋
有表達力的代碼是不需要注釋的，比如一個init函式，一看就知道是用于做一些初始化的作業，沒必要寫多余的注釋來說明，
但是有一些場景注釋是非常有必要的，下面幾種場景要添加注釋：
1，一些針對特殊業務場景而訂制的特殊邏輯，比如當我們更新個人資訊的時候，由于后端的問題，需要少傳一個諸如生日的資訊，或者更新頭像時要多傳一個時間戳來供其他業務以后使用，這些莫名其妙的增刪屬性，如果不加以注釋，將導致后續自己都無法理解；
2，可能會出現隱患的代碼，由于自身水平所限，或者本身技術上就無法實作，只能通過一些特殊技巧來仿制一些效果，往往會存在安全隱患，比如：用戶操作太快會出問題，網路太慢會出問題，某個介面調不通這頁面會全掛了，一些特殊的操作會引起的暫時無法解決的bug等等場景，都需要注釋說明；
3，涉及到某些高深的或者生僻的技術知識，這種也要注釋，以提醒自己和其他開發者，
一般來說，注釋基本上都是在表達“這里我為什么這么做”，很少有注釋會去表達“我是一個什么玩意兒”，如果是后者的注釋，只能說明命名沒做好，
函式
函式是代碼的靈魂，也是寫邏輯的載體，以下幾個要求是判斷一個開發者函式寫的好不好的標準，
1，是不是單一職責，一個函式應該只做一件事，而這件事應該能通過函式名就可以清晰的展示，這是一個非常好的特性，一個辣雞的函式可能動輒幾百行代碼，各種邏輯堆積在一起，看得人頭腦發暈，甚至開發者自己都理不清楚；判斷這個函式是不是單一職責的技巧很簡單：看看它還能不能再拆分，
2，有沒有層級之分，函式與函式之間是有身份地位之分的，有負責整體大局觀的高級函式，也有專注細節的打工仔低級函式，如果不建立起層級結構，就容易迷失在細節的海洋里，比如：
對于做一頓飯這個函式來說，他不需要關心諸如買菜時反復挑選這種細節，它只需要知道，大概有三個大步驟就行了，所以這段邏輯會根據其地位拆分出不同等級的函式，假設沒有層級之分，那么從第一步的“搭公交”一直寫到最后一步的“倒垃圾”，這東西會變得極難維護，
3，承載的場景是否足夠簡單，有時候我們會遇到這樣一種場景：一個函式在很多地方都會用到，但是不同地方傳入的引數不一樣，這樣我們為了函式的通用性，就針對入參做了很多種場景的識別，導致入參非常多，里面還需要根據不同的場景做邏輯上的細微調整，所以單單是取傳入引數都夠嗆了，一堆的if else或switch case，
這個函式太難了，而且這已經違背了函式的單一職責原則，它在里面做了多種場景的判斷，從而表現出不同的行為，但這些行為又不是完全不同，而是“大體相同”，如果重寫好像又會增加很多的重復的代碼，解決的方法是做更小粒度的拆分，將那些真正與業務脫鉤的部分抽離出來，而不同場景對應不同的處理函式，剛剛抽離的業務脫鉤函式正好作為這些不同場景函式公共部分！
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/37738.html
標籤：架構設計