持续更新。

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跑在老系统上，泼费克特。