溝通創造價值，分享帶來快樂。這裡是程式設計師週刊，歡迎您每週五和我一起做時間的朋友。
並不是社會不尊重程式設計師，只要你能幫上大忙，就一定會贏得別人的尊重。所以，開玩笑說，我們可能都是在寫一樣的 for 語句，但是，你寫在那個地方一文不值，而我寫在這個地方，這行程式碼就值 2000 元。
大咖思維
本期繼續和大家分享陳浩關於未來技術發展的趨勢，因為是個人最近一直在追他的文章，乾貨非常多，大家不妨體驗看是否有道理。
一個技術能不能發展起來，關鍵還要看三點：
1、一個比較好的技術社群：像 C、C++、Java、Python 和 JS 生態圈都是非常豐富和火爆。
2、一個工業化的標準：像 C、C++、Java 這些程式語言都是有標準化組織的。尤其是 Java，它在架構上還搞出了像 J2EE 這樣的企業級標準。
3、一個或多個殺手級應用：C、C++ 和 Java 的殺手級應用不用多說了，就算是對於 PHP 這樣還不能算是一個優秀的程式語言來說，因為是 Linux 時代的第一個殺手級解決方案 LAMP 中的關鍵技術，所以，也發展起來了。
上面三點至關重要，新的技術只需要佔到其中一到兩點就已經很不錯了，何況有的技術，比如 Java 三點全都滿足，所以，Java 蓬勃發展也在情理之中。
用這些標尺來衡量一下 Go 語言：
Go 語言容易上手；
Go 語言解決了併發程式設計和底層應用開發效率的痛點；
Go 語言有 Google 這個世界一流的技術公司在後面；
Go 語言的殺手級應用是 Docker 容器，而容器的生態圈這幾年可謂是發展繁榮，也是熱點領域。
最後陳浩得到的判斷是：
Go 不可限量，會吞食 C、C++、Java 的專案，吞噬主要是中間層的專案，也就是說，Go 不會吞食底層到 C 和 C++ 那個級別的，也不會吞食到上層如 Java 業務層的專案。Go 語言能吞噬的一定是 PaaS 上的專案，比如一些訊息快取中介軟體、服務發現、服務代理、控制系統、Agent、日誌收集等等，他們沒有複雜的業務場景，也到不了特別底層（如作業系統）的軟體專案或工具。
程式設計師的個人財富
財富的定義遠遠不限於金錢，而是任何有價值，能產生收入的東西，《富爸爸，窮爸爸》中，把一個人的財富歸為了下面幾大類：
- 無需本人到場就可以正常運作的業務；
- 股票；
- 債券；
- 能夠產生收入的房地產；
- 版稅，如音樂、圖書、專利等；
- 其他任何有價值、可產生收入，或者有增值潛力，並且有很好銷路的東西，比如藝術品。
這本書不僅改變了我對“財富”定義的認識，更重要的是讓我明白了這一點：人生在世，最重要的事情不是打工賺工資，而是積累真正的財富。想清楚這個，你才能實現從“打工者思維”到“財富管理者思維”的轉變，才有可能真正走上“財富自由”的道路。
作為一名程式設計師，我們是比其他職業的人更幸運的，因為我們可以積累的財富遠不止上面提到的幾項。這裡羅列一下我能想到的財富積累：
優質公司的關鍵技術崗位，管理崗，技術人脈，自身技術壁壘，技術專利、課程，影響力資源（包括但不限於公眾號，知乎專利，微博等），所在公司期權。
Code Review
- LinkedIn 的高效程式碼審查技巧：（https://thenewstack.io/linkedin-code-review/）
這篇文章介紹了 LinkedIn 內部實踐的 Code Review 形式。具體來說，LinkedIn 程式碼複查有以下幾個特點。
1、從 2011 年開始，強制要求在團隊成員之間做程式碼複查。Code Review 帶來的反饋意見讓團隊成員能夠迅速提升自己的技能水平，這解決了 LinkedIn 各個團隊近年來因迅速擴張帶來的技能不足的問題。
2、通過建立公司範圍 Code Review 工具，這就可以做跨團隊的 Code Review。既有利於消除 bug，提升質量，也有利於不同團隊之間的經驗互通。
3、Code Review 的經驗作為員工晉升的參考因素之一。
4、Code Review 的一個難點是，Reviewer 可能不瞭解某塊程式碼修改的背景和目的。所以 LinkedIn 要求程式碼簽入版本管理系統前，就對其做清晰的說明，以便複查者瞭解其目的，促進 Review 進行。
這篇文章通過阿里巴巴內部因為業務程式碼不做Code Review案例進行的覆盤，詳細地講解了為什麼要Code Review，Code Review為什麼會有問題，結合實際情況進行反思，是一篇深度思考的好文。
本文是我之前對程式碼審查的總結，分別從為什麼要審查，審查的困境和爭議，審查的形式，審查的物件，審查人員，審查物件等維度出發，系統性的學習筆記，希望對你有所啟發。
程式語言和程式碼質量
這是一項有趣的研究。有四個人從 GitHub 上分析了 728 個專案，6300 萬行程式碼，近 3 萬個提交人，150 萬次 commits，以及 17 種程式語言（如下圖所示），他們想找到程式語言對軟體質量的影響。
然後，他們還對程式語言做了一個分類，想找到不同型別的程式語言的 bug 問題。如下圖所示：
以及，他們還對這眾多的開源軟體做了個聚類，如下圖：
對 bug 的型別也做了一個聚類，如下圖：
我們來看一下相關的結果。
首先，他們得出來的第一個結果是，從檢視 bug fix 的 commits 的次數情況來看，C、C++、Objective-C、PHP 和 Python 中有很多很多的 commits 都是和 bug fix 相關的，而 Clojure、Haskell、Ruby、Scala 在 bug fix 的 commits 的數上明顯要少很多。下圖是各個程式語言的 bug 情況。如果你看到是正數，說明高於平均水平，如果你看到是負數，則是低於平均水平。
第二個結論是，函數語言程式設計語言的 bug 明顯比大多數其它語言要好很多。有隱式型別轉換的語言明顯產生的 bug 數量要比強型別的語言要少很多。函式式的靜態型別的語言要比函式式的動態型別語言的程式出 bug 的可能性要小很多。
第三，研究者想搞清楚 bug 數是否會和軟體的領域相關。比如，業務型、中介軟體型、框架、lib，或是資料庫。研究表明，並沒有什麼相關性。
每個程式設計師都應該要讀的書
在 Stack Overflow 上有使用者問了一個問題，大意是想讓大家推薦一些每個程式設計師都應該閱讀的最有影響力的圖書。雖然這個問題已經被關閉了，但這真是一個非常熱門的話題。排在第一位的使用者給出了一大串圖書的列表，看上去著實嚇人，不過都是一些相當經典又相當有影響力的書。
有大家耳熟能詳的書，比如
- 《程式碼大全》 雖然這本書有點過時了，但是這絕對是一本經典的書。
- 《程式設計師修練之道》 這本書也是相當經典，可以是你的指路明燈。
- 《計算機的構造和解釋》 經典中的經典，必讀。
- 《演算法導論》 美國的本科生教材，這本書應該也是中國計算機學生的教材。
- 《設計模式》 這本書是物件導向設計的經典書籍。
- 《重構》 程式碼壞味道和相應程式碼的最佳實踐。
- 《人月神話》 這本書可能也有點過時了。但還是經典書。
- 《程式碼整潔之道》 細節之處的效率，完美和簡單。
（地址：https://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read）
永不過時的技能
什麼是永不過時的技能呢？之前跟極客時間作者左耳朵耗子聊天的時候，談到過這個話題，他的答案非常具有參考性，也就是程式設計能力、架構能力和工程能力。
程式設計能力，就是用程式碼解決問題的能力。你程式設計能力越強，就能解決越複雜的問題，細分之下，要有除錯能力、演算法、資料結構、作業系統原理等基礎技能的支撐，你才能解決各種麻煩的問題。
架構能力，就是掌控複雜系統的能力。當一個系統足夠複雜時，你會寫每一塊程式碼、能解決每一個問題，不等於你能搞定整個系統，這就需要架構能力。架構能力包含了一些意識，也包含認識業務建立抽象模型，還有一些常見的模式等。
工程能力，其實核心就是成事的能力。你要知道，當系統規模越來越大時，光靠你一個人是沒辦法完成的。那如何保證幾個高手能夠互相配合好？如何保證專案裡面水平最差的人不拖後腿？工程化建設往往會跨越多個業務，又如何保證質量和程式碼風格呢？
這三項能力不管對於前端還是後端開發來說，可以說都是從初級、中級走向高階必須要跨越的鴻溝，也是作為一名程式設計師永不過時的技能。
GitHub
- V8引擎系列教程
V8 是 Google Chrome 瀏覽器和微軟 Edge 瀏覽器的 JavaScript 執行引擎。本課程介紹如何成為 V8 的開發人員。注意這是硬核技術培訓，每次視訊請預留10個小時的上機程式設計練習時間。
Github地址：github.com/plctlab/v8-internals
vue移動端元件庫
一個開箱即用vue移動端元件庫，基於 Vue、uniApp、 ColorUi、uView 的web移動端解決方案，包含地圖、電子簽名、證照識別等。
自定義TabBar與頂部、地圖軌跡回放、電子簽名、圖片編輯器、自定義相機/鍵盤、拍照圖片水印、線上答題、證件識別、周邊定位查詢、文件預覽、各種圖表、行政區域、海報生成器、視訊播放、主題切換、時間軸、瀑布流、排行榜、課程表、漸變動畫、載入動畫、請求封裝等～ 該專案使用最新的前端技術棧，它可以幫助你快速搭建移動端專案。
