代码调试一直是非常重要的，也占用了我们很多时间，相信大家都深有体会。
会不会写代码，很大一个衡量标准是，你写完代码以后花多少时间在调试代码上面。
调试代码的时间花费和很多都有关系，作为框架设计者，或者机制设计者，如何让使用框架的小伙伴能方便的调试数据和找出相关问题，这个是我们要思考的。
今天给大家分享框架设计中方便定位错误的几个点，供大家参考。

01
保证每个模块数据源头，底层准确上报与及时的数据错误日志。

不是所有的小伙伴都懂得框架的全部内容，清楚框架的所有流程，对很多人而言，做的模块清楚就可以了。

比如所有代码都从main入口开始，初学者不用管前面OS的一些列复杂操作。这样就要求每个模块有统一的入口来获取输入数据。

比如网络模块。假设你怀疑某个网络事件没有收到或数据不对，这个时候，只要比对验证网络模块收到的所有输入即可。

而框架要做的，就是保证这个模块输入的准确性。比如我底层收到的数据一定都传给了这个模块，而逻辑开发者在调试代码的时候，就可以从网络模块的收到数据的地方来追踪，而不用管底层是如何取上来的，框架设计就是要保证传入的数据的准确性。

底层要保证上报数据的准确性，当底层发现数据错误的时候，要有详细的打印，必要时抛出异常，从框架层面上保证数据的准确和追踪错误。

当底层抛出错误后，可以和框架设计者联调，这样不至于到处甩锅，当设计框架模块的时候一定要做好异常数据的打印日志维护和错误断言。

02
框架机制尽量保证业务模块的工作独立，移除成本低。

协作就会有成本，沟通就会有成本。框架设计尽量要提供机制，让开发各种功能的人的工作尽可能独立，这样降低这种沟通成本，而沟通成本中最大的就是联调维护成本。

保证好数据的输入，业务代码给出对外的输出。而输出数据有可以作为其他模块的输入。这样，开发人员只要验证输入，验证输出，核对中间处理逻辑，最坏的情况就是重写这个模块，而我们要从机制上保证重写这个模块的去掉成本要最低。

这样移交代码的时候，如果这个代码能修正，就修正，如果实在不能修正，移除重写即可，而移除不会造成系统性崩塌和瘫痪。你可以写任何代码，但是5分钟我能把你的代码从项目中移除，这个是我奉行的哲学，即使某些代码开发者水平太菜，也不太影响整个项目的代码质量和开发进度。

03
每个框架机制最好配套使用文档和调试的视频教程。

使用文档，大家都觉得稀松平常，不就是API的说明文档么？但其实有这个还不够，每个机制能配套好对应的调试和跟踪策略。

我带项目发现很多初学者调试代码没有思路，埋头就下断点、就看，出了问题不知道如何下手，如何验证比对。

调试方法不难，教一次，大部分人都能学会。

我带的项目和团队里面，一般会把重要的一些机制的调试方法和追踪思路录制成视频，交给大家，这样沟通成本比较低，同时新来的小伙伴能学会找问题的思路和方法。

这样遇到问题大家就不慌，知道如何调试验证。

核心开发只有那么少数几个，而如何把这些思想和方法传递给其他的小伙伴，是打造一个技术过硬的核心团队的根本。

一个人强，没有用，要大家都强。

我发现这样真的能帮助很多的人快速的提升，这也是我做在线教育的萌芽。

我现在做创业也保留这个习惯，就是给每个岗位的入职员工录制视频，讲解目前公司的现状和主要的运营思路和流程，真的可以节约很多时间管理成本。

04
框架与项目要尽早引入测试

项目一开始就引入测试，这个也是我带团队的一个经验。
有些项目，项目都开发完成了还没有上android、 iOS做过一次真机测试，一上来就遇到了莫名的闪退。

随着代码比较庞大，也不容易调试出来，导致对整个项目的进度发生非常严重的误判。

项目都快开发完了，才发现性能问题，再去做性能调优，还不知道导致性能低下的是哪个模块，哪部分代码。

不要等到最后再爆所有的雷，真正项目管理者一开始就要关注框架+项目的整体性能稳定度等。

我做开发的时候，每天17:30分，我一定要让开发发一个完成的今天的功能测试包出来，给测试来进行主要的一些测试，并且自己也测试一下,找出一些不好的实现细节，尽早改正。

而且我要跑主流的我即将发布的平台，android，iOS等，尽早发现问题，项目进度越可控；入口一开始就对质量松懈，后面delay的可能性就越大，失败的可能性就越大。

编辑器开发的时候没有问题，不代表发布到其他平台没有问题。同时有重大功能完成后我一定会review代码。从整体上把控一下代码质量与设计。

以上是我总结的框架快速定位错误的几个点，希望能对框架设计者有所帮助。

尽量多阅读别人的框架代码，多看多学习，自己体会。