[周末讀文] 編程的智慧讀後感

本周的摩拜前端周刊總編 yueyue 提了一個任務：每一個人交一篇讀後感。

本讀後感原文來自：https://www.jianshu.com/p/7645a5ea7f46

內容較長，感謝作者，看了幾遍，確不乏一些思考的內容

1、提高編程水平最有效的辦法是什麼？

面對這個還算普通的問題，你會如何回答呢？

其實沒有最有效的，大部分都因人而異，只是看多了成功的人，會發現一些差不多的點。

個人覺得分階段把，按入行年限來看

1. 初級階段：以理論 + 實踐為基礎，通過一些基礎類庫的反覆應用來熟悉前端生態的整個流程，養成一些好習慣：比如記錄一些自己遇到的問題

   選對好的團隊和好的導師，少走彎路，多寫代碼

2. 中級階段：深度和廣度的拿捏開始階段：找到自己的優勢領域，不斷去挖掘，帶有比較性地去看到問題，有一定的抽象能力和意識，學會去看看別人的優勢編程習慣，開始封裝部分有共性的東西
   主動性和興趣是支撐自我優勢的決定性因素，不同技術方向的鍛煉機會也很重要
3. 高級階段：深度和廣度的拿捏修鍊階段，擁有了多年經驗之後，更多地吸收梯隊化團隊帶來的差異性，積極主動地承擔一些技術攻關的項目，對代碼的細節設計反覆思考，能夠帶動團隊其他的同學一起思考和碰撞，制定研發一些利於團隊效率的工具和規範，參與設計組件庫等
   經驗是優勢其實也是劣勢，如何有自己獨有的技術調性，敢於去嘗試和沉澱
4. 資深階段：保持勤奮的學習熱情，善於發現業務中的技術生產力，有更多統籌的架構意識，學會關注行業的動態，推動技術升級，帶動團隊的技術平均水平
   站的位置越高，越願意擁抱技術變化帶來的思考，有危機意識

2、原文開始的階段也提到了：

「看一個作家的水平，不是看他發表了多少文字，而要看他的廢紙簍里扔掉了多少。」

對於初中級的同學，其實難免會出現冗餘、重複的代碼，加上很多業務的壓力，在早期大部分的人都是以結果導向為主

但是：

1. 你有沒有一個負責任的導師
2. 你有沒有一個關注 code review 的團隊
3. 你有沒有一個注重 lint 的團隊開發工具

當然，當你自己有一些調性之後，你自己就會主動地去重構代碼。

3、再談如何定義：可讀的代碼和簡單直觀的代碼？

有比較才有傷害，或者說：貧窮限制了我的想像力。

原文作者也提到了一些 Unix 命令中的巧妙寫法，包含 && 和 || 特性。

其實做前端久了，你發現慢慢地，同其他語言的不斷借鑒，前端也工程化、服務化、組件化，有設計模式、架構設計等等。

前面也講了，我們通過 lint 來約束團隊編碼規範、減少低級錯誤的產生。通過定義的 code review 以及第三方開源案例和類庫的學習研究，確定更好的編碼方式和設計模式。

當然更多也是 ES6 等以及 ts 的不斷發展，源代碼相對而言越來越簡潔：

1. 你的團隊是不是還有一些老項目沒有應用 es 等
2. code review 是否真的認真負責地落地下去
3. 分享交流的習慣是否落到了每一個人
4. 團隊的一致性和差異性是否得到最大化

4、最後講無懈可擊的代碼

很多人會想到兼容性或者適配，當然不只是如此。

最近我們上了一個摩幣遊戲，由於遊戲有一定的規則和複雜性，所以總會有一兩個 bad case 出現。

一般的做法：case by case 地去復現這些奇奇怪怪的操作帶來的 bug，然後 hotfix。

於是，我們開始反思：

1、不管任何人由於任何方式進入到了結束頁面，如果沒有拿到他的登陸信息，就一律跳轉到首頁

2、不管誰分享誰(誰看誰的分享，誰在誰的分享頁面右上角點擊二次分享)，如果進來打開鏈接的用戶沒有登陸過，是否可以理解為它就是第一頁，點擊按鈕，彈窗登陸

當然只是一個舉例，對於代碼本身的考量其實更多，包含返回值類型的不確定、默認值、異常情況、弱網的處理等等

最近我們在做國內國外性能優化的時候，發現慢查詢的業務頁面有的甚至有 8-12s 的節點訪問，所以

我們優化了 dns、加入了更多 ssr 項目的投入和落地，增加了體驗性的佔位和骨架圖，等等

閑扯一篇而已，恩，去看書了，各位周末快樂

順帶問一下 yue 老闆，這篇能得奶茶嗎？