代码之外的功夫 第2章 观察增量变更，发掘隐藏依赖（读书笔记）

这一章要在一个现有的内部知识库之外再开发一个公开的维基系统，两个项目相互独立但是共享代码库和基础设施。

两个项目都有着自己的地盘，但是由于共享基础设施，所以还是会有互相影响。例如，如果维基系统受到攻击，导致存储空间耗尽，内部的知识库系统就会崩溃。文中还提到另外一个共享的组件，Markdown语法转换器，也可能因此受到攻击。【这一小节的主要问题是，一个内部的重要程度更高的系统，可能会因为另一个公开系统受到攻击而瘫痪。而当不存在这个公开系统时，内部系统即使没有经过充分的优化，由于很少会受到攻击，也就很少会出现问题。这里主角通过分析发现了一些隐藏的依赖并提供了解决方案。但是条件允许时，最好还是隔离基础设施，避免那些一时注意不到的相互依赖导致的问题。】

除了基础设施，数据层面也可能有相互依赖。另外一个是，主角添加了一个侧边栏，会根据标题长度自动扩展宽度，当标题过长时就会严重干扰页面内容，同屏也是一种相互依赖。【不太了解数据库，对文中提到的数据库模式也不是很明白。大概理解的意思是，即使代码是相互独立的，也会存在依赖，一切共享的资源（甚至是屏幕）都会产生依赖关系。】

还有依赖外部api的情况，如果请求比较频繁，会对api产生较大的压力。这时候如果数据并不需要实时更新的话，可以考虑定时拉取数据，然后读取数据库。外部api出现问题时，至少还有个过时的数据可以用。【主角在这里用的定时方法是crontab，但是个人感觉crontab的维护性比较差，不知道有没有更好的方法。在之前的工作里也碰到过类似的问题，其他部门频繁拉取我们提供的一个接口导致我们这边的服务崩溃，然后我们反馈让他们用我们的批量接口合并拉取次数以降低压力。】

复用旧代码时，由于老代码设计时并没有考虑现在的场景，使用时会产生不可预知的问题。复用代码时要注意使用范围、性能标准或隐私安全级别的改变。【最简单的场景就是，一段只是内部使用的代码放到公开环境，就会有很多可攻击的漏洞。一个系统要公开使用时，一定要进行充足的测试，否则影响的不仅仅是单个系统。】

另外要注意的是，一定要建立监控机制，能迅速处理异常情况，而不是等到竞争对手都知道了才开始处理。