PS： 如下内容是我在日常中阅读到的，从中结合工作/生活的所思，认为比较有借鉴意义的思考，不喜勿碰，取者自思！
- KISS（Keep it simple, stupid）: 保持每件事情都尽可能的简单，用简单的解决方案来解决问题。
- 爬，走，跑[顺应自然]。通俗来讲，先保证跑通，然后再优化变得更好，然后继续优化让其变得伟大。迭代着做事情，敏捷开发的思路，对于每个功能点，创建里程碑（最大两周），然后去迭代。
- 创建稳定、高质量的产品的唯一方法就是自动化测试。自动化测试的脚本在一开始做某些功能时就应该开始做起来，因为自动化测试中涉及逻辑上的验证，后期的更改如果修改了这个逻辑，就会触发错误，在一定程度上能让开发提前发现问题，同时也给QA省出来时间来做更重要的事情。
- 开发也要时刻考虑产出比(ROI)，不要一直关注技术而忽略使用者，通过与使用者交互来达到解决问题的平衡点。
- 要知道一个server时如何运行的，从硬件到操作系统，直到编程语言，优化IO调用的数量是你通往最好架构的首选之路。
- 无状态的系统是可直接扩展的。任何时候都要考虑这一点，不要搞个不可扩展的，有状态的东东出来。
- 在分布式系统中，你永远无法避免延迟和失败。
- 总是要为配置设置一个合理的默认值。
- 永远不要悄悄地吞掉或忽略异常，这往往是找bug花几个小时的罪魁祸首。
- 梦想着新的编程语言就会变得简单和明了，但往往想要掌握会很难，不要轻易去换编程语言。
- 设计系统之初就要考虑后期遇到异常情况怎么还原现场
我在做Timing的结伴学习功能的时候，客户端APP从服务端MS获取房间room的信息，然后去腾讯TRTC上麦，上麦成功后TRTC会发回调到MS，整个业务就形成了一个环，APP调TRTC，TRTC给回调给MS，MS提供数据给APP，任何一个环节出现错乱就造成了房间内上麦用户错乱，并且这里还涉及到秒杀（一个房间只有4个位置）的场景，用到分布式锁，但是到了快上线了，测试却测出来了5个用户在一个房间的情况，后面未能再重现。尽管后期我们压测，也未重现，如果当时我们做了详细的log，就能很好的还原当时的场景。另外，一个用户上麦，下麦，进入房间，观众和成员的角色切换，大量的TRTC回调日志充满了这个log，不便于排查，后期复盘觉得当时应该对每个进入房间的用户生成一个trackID，返回给客户端，客户端每次都带过来这个trackID，这样如果这个用户出现了问题，就能直接通过trackId来过滤出属于他的日志。