【技術思路】極客時間-左耳聽風-開篇詞2
07 | 推薦閱讀：每個程式設計師都該知道的知識
每個程式設計師都應該要讀的書
- 《程式碼大全》
- 《程式設計師修練之道》
- 《計算機的構造和解釋》
- 《演算法導論》
- 《設計模式》
- 《重構》
- 《人月神話》
- 《程式碼整潔之道》
- 《Effective C++》/《More Effective C++》
- 《Unix 程式設計藝術》、《Unix 高階環境程式設計》
每個搞計算機專業的學生應有的知識
http://matt.might.net/articles/what-cs-majors-should-know/
- 要獲得一份好工作，學生需要知道什麼？
- 為了一輩子都有工作幹，學生需要知道什麼？
- 學生需要知道什麼，才能進入研究生院？
- 學生需要知道什麼，才能對社會有益？
首先，作品集（Portfolio）會比簡歷（Resume）更有參考意義。簡歷中應該放上自己的一些專案經歷，或是一些開源軟體的貢獻，或是你完成的軟體的網址等。個人網址寫自己的技能、經歷、文章。
其次，計算機專業工作者也要學會與人交流的技巧，包括如何寫簡報，以及面對質疑時如何與人辯論的能力。
最後，硬技能方面工程類數學、Unix 哲學和實踐、系統管理、程式設計語言、離散數學、資料結構與演算法、計算機體系結構、作業系統、網路、安全、密碼學、軟體測試、使用者體驗、視覺化、平行計算、軟體工程、形式化方法、圖形學、機器人、人工智慧、機器學習、資料庫等等。
LinkedIn 高效的程式碼複查技巧
LinkedIn 的高效程式碼複查技巧
LinkedIn’s Tips for Highly Effective Code Review
LinkedIn 內部實踐的 Code Review 形式複查有以下幾個特點。
- 強制要求在團隊成員之間做程式碼複查。Code Review 帶來的反饋意見讓團隊成員能夠迅速提升自己的技能水平，這解決了 LinkedIn 各個團隊近年來因迅速擴張帶來的技能不足的問題。
- 通過建立公司範圍的 Code Review 工具，這就可以做跨團隊的 Code Review。既有利於消除 bug，提升質量，也有利於不同團隊之間經驗互通。
- Code Review 的經驗作為員工晉升的參考因素之一。
- Code Review 的一個難點是，Reviewer 可能不瞭解某塊程式碼修改的背景和目的。所以 LinkedIn 要求程式碼簽入版本管理系統前，就對其做清晰的說明，以便複查者瞭解其目的，促進 Review 的進行。
LinkedIn 對提交程式碼寫說明文件這個思路是一個非常不錯的方法，因為程式碼提交人寫文件的過程其實也是重新梳理的過程。寫文件的時候通常會發現自己把事兒幹複雜了，應該把程式碼再簡化一下，於是就會回頭去改程式碼。
- 有些 Code Review 工具所允許給出的反饋只是程式碼怎樣修改以變得更好，但長此以往會讓人覺得複查提出的意見都表示原先的程式碼不夠好。為了提高員工積極性，LinkedIn 的程式碼複查工具允許提出“這段程式碼很棒”之類的話語，以便讓好程式碼的作者得到鼓勵。
- 為 Code Review 的結果寫出有目的性的註釋。比如“消除重複程式碼”，“增加了測試覆蓋率”，等等。
- Code Review 中，不但要 Review 提交者的程式碼，還要 Reivew 提交者做過的測試。除了一些單元測試，還有一些可能是手動的測試。提交者最好列出所有測試過的案例。這樣可以讓 Reviewer 可以做出更多的測試建議，從而提高質量。
- 對 Code Review 有明確的期望，不過分關注細枝末節，也不要炫技，而是對要 Review 的程式碼有一個明確的目標。
程式語言和程式碼質量的研究報告
程式語言和程式碼質量的研究報告
A Large-Scale Study of Programming Languages and Code Quality in GitHub
結論1： 從檢視 bug fix 的 commits 的次數情況來看，C、C++、Objective-C、PHP 和 Python 中有很多很多的 commits 都是和 bug fix 相關的，而 Clojure、Haskell、Ruby、Scala 在 bug fix 的 commits 的數上明顯要少很多。
結論2：函數語言程式設計語言的 bug 明顯比大多數其它語言要好很多。有隱式型別轉換的語言明顯產生的 bug 數要比強型別的語言要少很多。函式式的靜態型別的語言要比函式式的動態型別語言的程式出 bug 的可能性要小很多。
結論3：研究者想搞清是否 bug 數會和軟體的領域相關。比如，業務型、中介軟體型、框架、lib，或是資料庫。研究表明，並沒有什麼相關性。
結論4：研究人員想搞清楚 bug 的型別是否會和語言有關係。的確如此，bug 的型別和語言是強相關性的。
這份報告可以在評估程式語言時有一定的借鑑作用。
電子書：《C++ 軟體效能優化》
Optimizing Software in C++ - Agner Fog
這本書是所有 C++ 程式設計師都應該要讀的一本書，它從事無鉅細地從語言層面、編譯器層面、記憶體訪問層面、多執行緒層面、CPU 層面講述瞭如何對軟體效能調優。實在是一本經典的電子書。
Agner Fog 還寫了其它幾本和效能調優相關的書，可以到這個網址http://www.agner.org/optimize/下載
- Optimizing subroutines in assembly language: An optimization guide for x86 platforms
- The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for assembly programmers and compiler makers
- Instruction tables: Lists of instruction latencies, throughputs and micro-operation breakdowns for Intel, AMD and VIA CPUs
- Calling conventions for different C++ compilers and operating systems08 | Go語言，Docker和新技術
一個技術能不能發展起來，關注三點：
- 有沒有一個好的社群（商業機構參與的社群）
- 有沒有一個工業化的標準（企業級標準）
- 有沒有一個或多個殺手級應用（解決方案）
影響因素：
- 學習難度是否低，上手是否快
- 有沒有一個不錯的提高開發效率的開發框架
- 是否有一個或多個巨型的技術公司作為後盾
- 有沒有解決軟體開發中的痛點
衡量Go：
- Go 語言容易上手；
- Go 語言解決了併發程式設計和底層應用開發效率的痛點；
- Go 語言有 Google 這個世界一流的技術公司在後面；
- Go 語言的殺手級應用是 Docker 容器，而容器的生態圈這幾年可謂是發展繁榮，也是熱點領域；
也就是說，Go 語言不會吞食底層到 C 和 C++ 那個級別的，也不會吞食到上層如 Java 業務層的專案。Go 語言能吞食的一定是 PaaS 上的專案，比如一些訊息快取中介軟體、服務發現、服務代理、控制系統、Agent、日誌收集等等，他們沒有複雜的業務場景，也到不了特別底層（如作業系統）的軟體專案或工具。而 C 和 C++ 會被打到更底層，Java 會被打到更上層的業務層。
衡量一下 Go語言的殺手級應用 Docker：
- Docker 容易上手。
- Docker 解決了運維中的環境問題以及服務排程的痛點。
- Docker 的生態圈中有大公司在後面助力，比如 Google。
- Docker 產出了工業界標準 OCI。
- Docker 的社群和生態圈已經出現像 Java 和 Linux 那樣的態勢。
Docker解決了PaaS層的問題，PaaS層能解決以下問題：
- 軟體生產線的問題
- 分散式服務化的問題
- 提高服務的可用性 SLA
- 軟體能力的複用
新技術的入場，而不是等待技術成熟了再進入：
- 技術的發展過程非常重要
- 關鍵新技術，可以讓你提前搶佔技術的先機
09 | 答疑解惑：渴望、熱情和選擇
加班太嚴重完全沒有時間學習，怎麼辦？
時間一定是能找得到的，就看你對你要乾的事有多大的渴望程度和多大的熱情。 只要你真的想做，你就一定能想出各種各樣的招兒來為自己擠出時間。
為什麼你能夠寫出這麼多東西？
- 第一個階段，是學習的階段：把學習到的東西都以筆記的方式記錄下來，方便可以翻出來看看。所以這個階段主要還是學習的階段。
- 第二個階段，是有利益驅動的階段：證明自己能做，不但要做出來，寫出來，還要說出來。
- 第三個階段，是記錄自己觀點打自己臉的階段：寫部落格，記錄一些自己的想法和觀點。
- 第四個階段，是與他人互動的階段：寫一些觀點鮮明，甚至看上去比較極端或是理想的文章了。一旦一件事被真正地討論起來（而不是點贊和轉發），就會有很多知識命中認知盲區。雖然會被別人批評或是指責，但是，能從中收穫到更多，因為會從不同的觀點，以及別人的批評中，讓自己變得更加完善和成熟。
從寫作中還能訓練自己的表達能力，這讓我能夠更好更漂亮地與別人交流和溝通。這一點對於我們整天面對電腦的技術人員來說，太重要了。
怎樣選擇自己的人生和職業發展？
- 20-30 歲，這是打基礎的階段：開闊眼界，把基礎打紮實，努力學習和成長。
- 30-40 歲，這是人生髮展的階段：明確自己奮鬥的方向，需要做有挑戰的事兒，需要提升自己的技術領導力
耗子叔給的一些建議：
- 客觀地審視自己：如果你超過了身邊的大多數人，你不妨選擇得激進一些冒險一些，否則，還是按部就班地來吧
- 確定自己想要什麼：所謂“極端”，就是自己不會受到其它東西或其他人的影響，不會因為這條路上有人退出你會開始懷疑或者迷茫，也不會因為別的路上有人成功了，你就會羨慕。
- 注重長期的可能性，而不是短期的功利：多去選擇能讓自己成長的事，尤其是能讓自己開闊眼界的事情。人最害怕的不是自己什麼都不會，而是自己不知道自己不會。
- 儘量關注自己會得到的東西，而不是自己會失去的東西：無論怎麼選，都會有得有失。
- 不要和大眾的思維方式一樣：如果你和大眾不一樣，那麼只有兩種情況，一個是你比大多數人聰明，一個是你比大多數人愚蠢。
10 | 如何成為一個大家願意追隨的Leader？
Leader 和 Boss 的不同
兩者得不同點如下：
- Boss 是驅動員工，Leader 是指導員工
- Boss 製造畏懼，Leader 製造熱情
- Boss 面對錯誤喜歡使用人事懲罰的手段，而 Leader 面對錯誤喜歡尋找解決問題的技術或管理方法
- Boss 只是知道怎麼做，而 Leader 則是展示怎麼做
- Boss 是用人，而 Leader 是發展人
- Boss 從團隊收割成績，而 Leader 則是給予團隊成績
- Boss 喜歡命令和控制（ Command + Control ），而 Leader 喜歡溝通和協作（ Communication + Cooperation ）
- Boss 喜歡說“給我上”，而 Leader 喜歡說“跟我上”
從上面這些比較，可以看到 Boss 和 Leader 的不同。瞭解和認識到什麼才是一個真正的 Leader，什麼才是一個 Leader 應有的素質和行為。
如何成為眾人願意追隨的 Leader
- 幫人解決問題：總是能站出來告訴大家該怎麼辦。
- 被人依賴
- 這個世界很大，一個公司或是一個 Leader 很難做到把人一輩子留下來，因為人總是需要有不同經歷的，優秀的人更是如此。既然做不到把人留一輩子，那麼不妨把這件事做得漂亮一些，這樣會讓要離開的員工覺得這個 Leader 或是這個公司的胸懷不一般，可能是他再也碰不到的公司或 Leader，反而會想留下來，或是離開後又想回來。
- 既然做不到不讓員工吐槽公司，那麼不妨讓這件事做得更漂亮一些——可以公開透明地說，而不是在背後說，因為在背後說對公司或是團隊的傷害更大。贏得他人的信任：對於信任來說，並不完全是別人相信你能做到某個事，還有別人願意向你開啟心扉，和你說他心裡面最柔軟的東西。而後者才是真正的信任。
開放的心態 + 傾向性的價值觀：
- 對於各種各樣的技術都要持一種比較開放的態度，可以討論優缺點，但不會爭個是非對錯，尤其對於新技術來說，更要開放。
- 傾向性可以讓別人更清楚地知道我是一個什麼樣的人，而不會對我琢磨不透，一會東一會西只會讓人覺得你太油了，反而會產生距離感和厭惡感。我認為，傾向性的價值觀是別人是否可以跟隨你的一個基礎。- Lead by Example：要做一個有人願意跟隨的技術 Leader，你需要終身寫程式碼，也就是所謂的 ABC – Always Be Coding。這樣，你會得到更多的實際經驗，能夠非常明白一個技術方案的優缺點，實現複雜度，知道什麼是 Best Practice，你的方案才會更具執行力和實踐性。當有了執行力，你就會獲得更多的成就，而這些成就反過來會讓更多的人來跟隨你。
- 保持熱情和衝勁：所謂的保持熱情和衝勁，並不是自欺欺人，也不是文過飾非，因為掩耳盜鈴、掩蓋問題、強顏歡笑的方式根本不是熱情。真正的熱情和衝勁是，正視問題，正視不足，正視錯誤，從中進行反思和總結得到更好的解決方案，不怕困難，迎難而上。
- 能夠抓住重點，看透事物的本質：能夠抓住主要矛盾，看清事物的本質，給出清楚的觀點或方向，簡化複雜的事情，傳道解惑、開啟民智，讓人豁然開朗、醍醐灌頂，才會讓人追隨之。
描繪令人激動的方向，提供令人向住的環境：能夠抓住主要矛盾，看清事物的本質，給出清楚的觀點或方向，簡化複雜的事情，傳道解惑、開啟民智，讓人豁然開朗、醍醐灌頂，才會讓人追隨之。
甘當鋪路石，為他人創造機會：幫助別人其實就是幫助自己，成就他人其實也是在成就自己，這就像一個好的足球隊一樣，球隊中的人都互相給隊友創造機會，整個團隊成功了，球隊的每個人也就成功了。
也許，你不必做一個 Leader，但是如果你有想跟隨的人，你應該去跟隨這樣的 Leader！