feature: App 逆向防护

Chapter6 - Design Pattern/6.23.md

@@ -173,7 +173,7 @@ public class Application {
 
 ## 使用场景
 
-在之前的文章利用[责任链模式设计了一套校验器](./../Chapter1%20-%20iOS/1.110.md)
+在之前的文章利用[责任链模式设计了一套校验器](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/Chapter1%20-%20iOS/1.110.md)
 
 - Node 的洋葱模型
 - Redux 中间件思想都是责任链的使用场景

Chapter6 - Design Pattern/6.8.md

@@ -49,7 +49,7 @@
 ## 重构的质量保证
 除了 QA 测试之外，最有效、可落地的测试就是单元测试可。当重构完成后，如果新的代码可通过单元测试所有 case，那么说明之前的逻辑没有被破坏，原有系统的行为、外部可见性没有改变。
 
-那 iOS 侧如何开展单元测试，可以见[这篇文章](./../Chapter1%20-%20iOS/1.75.md)
+那 iOS 侧如何开展单元测试，可以见[这篇文章](https://raw.githubusercontent.com/FantasticLBP/knowledge-kit/master/Chapter1%20-%20iOS/1.75.md)
 
 ## 代码是否需要“解耦”？
 间接的衡量标准有很多，比如，看修改代码是否牵一发而动全身。直接的衡量标准是把模块与模块、类与类之间的依赖关系画出来，根据依赖关系图的复杂性来判断是否需要解耦重构。