2020年我要這樣寫代碼

時間 2020-01-03

標籤 2020年這樣代碼简体版

原文原文鏈接

在 9102 年年初，一位室友問我一個問題，如何纔可以提高寫代碼的能力?前端

惋惜的是: 當時僅僅回覆了一些本身的想法，如多看開源代碼，多讀書，多學習，多關注業界的動向與實踐，同時也列了一些原則。可是這些並無所總結，又或者說沒有例子的語言始終是空泛的。因此在今年年末之際，對應着今年中遇到的形形色色的代碼問題來一一講解一下。vue

好代碼的用處

實際上本書創建在一個至關不可靠的前提之上：好的代碼是有意義的。我見過太多醜陋的代碼給他們的主人賺着大把鈔票，因此在我看來，軟件要取得商業成功或者普遍使用，「好的代碼質量」既沒必要要也不充分。即便如此，我仍然相信，儘管代碼質量不能保證美好的將來，他仍然有其意義：有了質量良好的代碼之後，業務需求可以被充滿信心的開發和交付，軟件用戶可以及時調整方向以便應對機遇和競爭，開發團隊可以再挑戰和挫折面前保持高昂的鬥志。總而言之，比起質量低劣，錯誤重重的代碼，好的代碼更有可能幫助用戶取得業務上的成功。ios

以上文字摘抄於《實現模式》的前言，距離本書翻譯已經時隔 10 年了，可是這本書仍舊有着很大的價值。同時對於上述言論，我並不持否定意見。可是我認爲，壞代碼比好代碼更加的費財(嗯，沒打錯，我肯定)。對於相同的業務需求，壞代碼須要投入的精力，時間更多，產出反而會更少。同時根據破窗理論( 此理論認爲環境中的不良現象若是被聽任存在，會誘令人們仿效，甚至變本加厲 )，壞代碼會產生更壞的代碼。這是一個惡性循環，若是不加以控制，完成需求的時間會慢慢失去控制。須要完成需求的人也會失落離開。git

也就是說，好代碼能夠實現多贏，可以讓用戶爽，可以讓老闆爽，可以讓開發者爽。總之，你們爽纔是真的爽。程序員

怎麼寫出好代碼

少即便多

利用開源出來的設計與代碼來減輕來自於業務線的時間壓力。github

The best way to write secure and reliable applications. Write nothing; deploy nowhere.算法

以上取自 github 上最火的項目之一 nocode。懶惰是程序員的美德之一。因此學習業務，理解業務，拒毫不必要的需求也是一個程序員的必修功課。詳情能夠參考如何杜絕一句話需求？這一篇 blog，固然，在大部分場景下，咱們是不具有對需求說不的能力與權力的，可是不管如何，深度的理解業務，對客戶有同理心是對程序員的更高要求。解決問題纔是一個程序員須要作的事情。可以理解好題意才能解決問題。數據庫

對於軟件開發而言，時間必定是最寶貴，最有價值的資源。相應的，儘可能把時間耗費在解決新的問題，而不是對已經存在確切解決方案的問題老調重彈。因此，儘可能不要本身寫代碼，而是借用別人的設計與實現。而在事實上，你也很難在極短的時間壓力下設計並完成比開源更加合適的代碼。編程

固然，開源做者必定是想讓他的產品有更多的受衆，因此從設計上而言，會採用較爲通用的設計，若是你的需求較爲特殊而且你以爲不能說服做者幫你「免費打工」(或者做者拒絕了)，那麼你也只須要在特定之處進行包裝與改寫,可是要比徹底重寫要簡單太多了。axios

固然，調研新的技術方案而且使用到項目中是一種能力，可是千萬不要由於一個小功能添加一個很是大的項目。

筆者在以前就遇到過其餘小夥伴由於沒法使用數字四捨五入。說 fixed 方法有問題而使用 math.js 的小夥伴。

(11.545).toFixed(2)
// "11.54"

若是想要了解 fixed 方法爲什麼有問題的，能夠參考爲何(2.55).toFixed(1)等於2.5？做者以 v8 源碼來解釋爲什麼會有這樣的問題，以及提供了部分修正 fixed 的方案。

事實上若是沒有很大的精度需求，前端完徹底全利用一個函數即可以解決的問題，徹底不須要複雜的math 這種高精度庫。

function round(number, precision) {
    return Math.round(+number + 'e' + precision) / Math.pow(10, precision);
}

固然，也有小夥伴來找我詢問大量數據的表格優化，我第一反應就是 React Infinite 或者 vue-infinite-scroll 此類解決方案。可是對方可以多提供一些信息包括上下文，採用的技術棧，當前數據量大小，將來可能須要達到的大小，當前表格是否須要修改等。獲得了這些信息，結合業務來看，相比於增長一個庫，是否以下方式更爲便捷與快速。

// 由於 vue 模型的緣由，使用 Object.freeze 性能能夠有很大增益
this.xxx = Object.freeze(xxx);

隨着堆積業務，代碼的增加。管理複雜度的成本與日俱增，把依賴下降。利用開源代碼使得任務更容易實現。時間就是成本。關鍵是讓收益能夠最大化。

學習更可能是爲了作的更少。

統一

不一樣的人因爲編碼經驗和編碼偏好不一樣，項目中同一個功能的實現代碼可能千差萬別。可是若是不加以約束，讓每個人都按照本身的偏好寫本身的模塊，恐怕就會變成災難。

因此每次在學習一些新技術的時候，我老是想多看看做者的實例代碼，做者是如何理解的，社區又是如何理解的。以求實現起來代碼風格不至於偏離社區太多，這樣的話能夠提升溝通與協做的效率。相似於《阿里巴巴Java開發手冊》或者 vue 風格指南這種取自大公司或社區的經驗之談，要多讀幾遍。由於他們所遇到的問題和業務更加複雜。

對於公司內部開發來講，寫一個組件時候，生命週期的代碼放在文件上面仍是放在最下面，如何把代碼的一個功能點集中放置。通用型代碼的修改。代碼行數的限制。可以列出統一的方案，多利而少害。

化繁爲簡（抽象）

抽象是指從具體事物抽出、歸納出它們共同的方面、本質屬性與關係等，而將個別的、非本質的方面、屬性與關係捨棄的思惟過程。

若是你面對一個較大的系統，你會發現重構並不能解決根本問題，它僅僅只能減小少量的代碼的複雜度以及代碼行數，只有抽象才能夠解決實質性問題。

不管是數據庫設計，架構設計，業務設計，代碼設計，但凡設計都離不開抽象。抽象能力強的所面臨的困難會比能力弱的少不少。

或者說抽象能力弱一些的小夥伴遇到一些問題甚至須要從新推翻而後再設計，這個是在時間和業務開發中是不能被接受的。

這裏就談談代碼，如下也舉個例子,如 axios 庫中有攔截器與自己業務，在沒有看到源碼以前，我一直認爲他是分 3 階段處理:

請求攔截
業務處理
響應攔截

但若是你去看源碼,你就會發現其實在做者看來，這 3 個階段其實都是在處理一個 Promise 隊列而已。

// 業務處理
var chain = [dispatchRequest, undefined];
var promise = Promise.resolve(config);

this.interceptors.request.forEach(function unshiftRequestInterceptors(interceptor) {
    // 前置請求攔截
    chain.unshift(interceptor.fulfilled, interceptor.rejected);
  });
this.interceptors.response.forEach(function pushResponseInterceptors(interceptor) {
    // 後置響應攔截
    chain.push(interceptor.fulfilled, interceptor.rejected);
  });

  while (chain.length) {
    promise = promise.then(chain.shift(), chain.shift());
  }

  return promise;

這就是一種代碼抽象能力。讓本身的代碼能夠適應更多的場景是程序員須要思考的。代碼不是給機器看的，是給人看的，更高的要求是: 代碼不只僅是給人看的，更是給人用的。須要考慮到協做的人與事，靈活的配置也是必需要考慮到的。就拿前端的虛擬 dom 來講。可以適配更多的平臺。

固然了，抽象能力須要時間，須要經驗，須要學習大量的設計。

注意!:不要過早的抽象業務代碼，甚至不要抽象業務代碼。多寫一點代碼無所謂，千萬別給本身找事作。在業務上儘可能保持簡單和愚蠢。除非你是業務專家，確認當前業務不太會產生變化。

權責對等(拆分與合併)

責任與義務本質上就是對等的，且越對等的就越穩定。這幾年，微服務架構，中臺，微前端理論層出不窮，本質上就是爲了權責對等，對於更加基礎的服務，更有產出的業務投入更高的人力與物力以保證更穩定的運行是很正常的一件事。而不是以前的大鍋飯(單體應用)。

從代碼上來看，某個模塊是否承擔了它不該該作的事情，或者某個模塊過於簡單，徒增複雜度。

固然，事實上有些東西目前是作不到的讓全部人都以爲滿意，增一分則肥,減一分則瘦,剛恰好很難界定。就像 Dan Abramov 說的那樣:

Flux libraries are like glasses: you’ll know when you need them.

只作一件事

Unix 哲學，這個很好理解，就像我今年想作的事情太多，反而什麼都沒有作(或者說都作了,但都很差)。

代碼上來看，不要由於一點點性能的緣由，把幾件事合在一塊兒去作。例如在一次 for 循環中解決全部問題，或者將全部代碼寫在一個函數中，例如:

created() {
  const {a,b,c,d} = this.data
  // ... 三件事情彼此有交互同時須要 a,b,c,d
  
  // 完成以後的邏輯
}

改造後:

created() {
  const axx = doA()
  doB()
  const cxx =  doC()
  // 完成以後的邏輯
}

// 分離出3個函數
doA() {
   const {a,b,c} = this.data
  // ... 三件事情彼此有交互同時須要 a,b,c,d
  
  // 完成以後的邏輯
}
// 其餘代碼

相比於第一個只須要一次取數，一次setData，第二個性能無疑更低，可是可維護性變高了，3 件事情都被拆分出來，後面修改代碼時候，我能夠追加一個 doD 而不是再次把第一份代碼中邏輯整理清楚再當心翼翼的修改代碼。

命名與註釋

There are only two hard things in Computer Science: cache invalidation and naming things.

命名與緩存失效是兩大難題，今年講了很多緩存問題，同時，命名的確是很困難的一件事情。經過一句話來解釋大家在作什麼事情，經過一句話來解釋一件事的意圖。

不說在程序世界中，在現實世界中也是如此。例如: 《震驚!xxx竟然xxx》等新聞,雖說看完後都會想要罵一句，可是，正如這樣的名字才能吸引人家點擊進入，讓人不由自主的被騙一次又一次。因此在項目沒有發佈前，要取一個簡單而又好記的名字。

但在程序內部，咱們不須要「騙取」人家的點擊量，反而是要務實點，不要欺騙另外的同伴，好比說寫了一個簡單的名字，結果內部卻封裝了不少的業務代碼。同時我認爲這也是函數越寫越短的理由，由於你們難以經過命名來解釋那一大坨代碼的意圖。因此，須要編寫能夠自我解釋的代碼，而這種代碼最佳實踐就是好的命名。

對於開源代碼，你每每會發現，這些文件開頭都會有一系列註釋，這個註釋告訴咱們了這個模塊的意圖與目的。讓你無需看代碼就能夠進行開發。

對於業務開發而言，僅在你不能經過代碼清晰解釋其含義的地方，才寫註釋。在多個條件下都沒法解釋你的代碼。

項目名
模塊名
文件名(類名)
函數名(方法名)

這並非讓你不寫註釋。可是我以爲更多的註釋應該放在數據結構而不是代碼邏輯上。聰明的數據結構和笨拙的代碼要比相反的搭配工做的更好。更多的時候，看數據結構我能瞭解業務是如何運行的，可是僅僅看到代碼並不能實際想象出來。

實際上，隨着時間的推移，代碼作出了許多改動，但註釋並無隨之修改，這是一個很大的問題。註釋反而變得更有欺騙性。

這裏也提供一篇 export default 有害的文章。我以爲 export default 導出一個能夠隨意命名的模塊就是一種欺騙性代碼(隨着時間的推移，該模塊的意圖會發生變化)。

考慮場景

沒有放眼四海皆准的方案，因此咱們必需要考慮到場景的問題，咱們老是說可修改性，可讀性是第一位的(每每可讀，可修改的代碼性能都不差)。可是若是是急切需求性能的場景下，有些事情是須要再考慮的。

if 是業務處理中最經常使用的，在每次使用前要考慮如下，哪一個更適合做爲主體，哪一個更適合放在前面進行判斷。若是有兩個維度上的參數，一個是角色，一個是事件。必定是會先判斷角色參數，而後再去判斷事件參數，反之則必定很差。由於前者更符合人的思惟模式。在同一維度下，至於哪一個放前面，必定是更多被使用的參數放在前面更好，由於更符合機器的執行過程。

就像在 if 中你到底是使用 else 仍是 return。大部分狀況下處理業務邏輯互斥使用 else,處理錯誤使用return。由於這樣的代碼最符合人的思惟邏輯。

可是在這裏我也要舉出來自《代碼之美》的例子，在第五章中，做者 Elliotte Rusty Harold 設計了一個 xml 驗證器，其中有一段在驗證數字字符:

public static boolean isXMLDigit(char c) {
  if (c >= 0x0030 && c <= 0x0039) return true;
  if (c >= 0x0660 && c <= 0x0669) return true;
  if (c >= 0x06F0 && c <= 0x06F9) return true;
  // ...
  return false
}

這個優化以後以下:

public static boolean isXMLDigit(char c) {
  if (c < 0x0030) return false; if (c <= 0x0039) return true;
  if (c < 0x0660) return false; if (c <= 0x0669) return true;
  if (c < 0x06F0) return false; if (c <= 0x06F0) return true;
  // ...
  return false
}