何其榮幸 站在天才的肩膀上看世界 學習這些精妙卓絕的東西
世界觀
- 你對世界的思考方式會融入你的代碼
- 抽象的能力,任何行業都能講抽象 程序員一個最重要的能力就是抽象能力
- 程序員要是嚮往美 品味高 寫出的程序就美而精確
- 整個軟件的組織架構 抽象交流 都能現實社會看到縮影
- 思維的跳脫 高層的看世界 理解世界是如何運行的
- 編程要抽象 歸一
- 大道至簡
- 目的 方法:永遠牢記目的,一件事情你知道爲什麼要做他,你也就知道如何去做了. 一些OO的基本準則什麼的 死背下來記不住,但是你如果記得你的目標是什麼,比如要高併發?要解耦?,你清楚你的目標那你不管用OO FP 甚至過程式 都能達到你想要的目的,就是手段不一樣了而已.所以也不用唯OO 也不用標榜什麼FP java php 也都無所謂了 也不用強調XXX是最好的語言了
方法論
- All your objects want to grow up to be actors.
- GOTO是邪惡的,因爲我們會問:"我怎麼樣獲得這個執行過程的入口點" 而可變性留給我們的問題則是:"我怎樣得到這個狀態"
- 先思考通信。它必須是任何分佈式應用架構的一部分。Ad-hoc通信會帶來可靠性的問題。而Actor模式和隊列則是好的範例。
- 概要設計很有用，但是不要盲目相信它。服務器總是以跟客戶端不同的速度發生變化，Duffy以Internet爲例說明了即便如此也可以工作的很好。
- 安全很重要，但是很難做到。安全性的缺乏可能會導致資源競爭、死鎖或者未定義行爲的出現。Duffy認爲，更好的安全形式是做好隔離。如果無法做到，你需要做到不可改變。如果這也做不到，你需要採用標準同步機制。
- 在設計時爲失敗做好準備，因爲總會有錯誤發生的。Duffy認爲，我們的設計應該考慮可複製和重啓能力，還說明了，故障恢復對於一個可靠的併發系統來說是必需的。
- 結構應該反映因果關係。一連串的事件引發的某個行爲在併發系統裏可能是非常複雜的。有相關上下文可以簡化對這些事件和行爲的跟蹤。
- 編碼結構採用併發模式，以使其更容易理解系統。兩個很有用的模式是Fork-Join和Pipeline。Fork-Join本身也有一些流水線的意思在裏面.
- 少說，多用聲明和響應式編程。聲明和響應模式善於把難題交給編譯器和框架來處理。Serverless是這個想法在只有一個事件和一個動作時的特殊實例。