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