【技術性】Software engineering知識

持續更新。

1. Clean code之如何減小函數參數個數：

   1. put into class or context struct
   2. 放進類的member中，這樣就不用傳入了

2. Logging
   各個公司/語言/平臺/service確定都會用不同的logging系統，有時須要學習和看看庫代碼
3. Config
   不管是什麼樣的系統，通常都是有template而後有具體的configs。在FB是thrift file規定struct，Configerator repo裏.cinc文件作template，.cconf文件作具體的config。
   在Zillow是default.yaml文件作template，而後別的yaml文件作具體的config。
   通常都有config repo，各個service都須要同這個repo對話來獲取具體的config。

4. Deployment
   不管是FB的Tupperware仍是Zillow的Concrete+Jenkins系統，基本思想仍是一致的，都是把特定版本的package（或稱artifact）給弄到特定的機羣上去。Deployment config通常包括以下fields：

   1. package/artifact/egg: name，version，dependencies
   2. command：build + run
   3. arguments
   4. （scheduling）

5. Thrift能夠在各個語言之間share structs做爲粘合劑
6. Debugging之複雜系統焦頭爛額的應對策略：
   首先絕對應當understand the system!!但並不必定是所有，首先讀手冊讀wiki，瞭解清楚整個流程，而後用調整input觀察output的方式定位到一個黑箱子，對這個黑箱子的部分再仔細閱讀便可。
7. Clean code之如何消減switch的使用：
   通常原則是switch只能在一處使用一次，也方便改動只一次。因此通常都在base class（工廠類）裏面。
   其餘地方出現的switch能夠考慮用map消減，或者context。
8. Clean code之方法類：
   適用於有多種操做且可能持續添加操做，e.g. stats，這時候能夠抽象爲類。
9. Clean code之複雜業務邏輯：
   通常程度的複雜還能夠忍受，可是若是有一天你真的以爲不管如何都記不住複雜的代碼邏輯的時候，就應該考慮重構了！

10. 重構：
    接9，可是！！！並非全部的複雜系統都應該重構！！！有時系統的複雜是自然的，是由於原本就有不少overhead，原本就經歷了很長的開發過程。。。重構只應在知足如下條件時發生：1）6個月之內能爲系統增長明顯的value，好比提高perf之類；2）必須有老員工的支持，不然邏輯根本沒法重寫；3）考慮折衷方案：新feature跑在rebuild上，老feature跑在老系統上，潑費克特。