我在玩游戏的时候，经常在闯到一些关卡的时候容易死亡，每次走到那里都会小心一些，还是容易挂掉。其实按理说这个地方多小心一点也是可以过去的，就是需要付出额外的注意力。
编程的时候，在一些地方容易出错。看着人说内存泄漏或者之类的漏洞，就觉得明明是自己的错，为什么起一个那么推卸责任的名字。那些地方只要多做留意，是可以都处理好的。只需要增加注意力，可能就会显得花费了更大的力气才能处理好。所以普通情况下，也可以称呼这些地方为容易犯错的地方，容易出现漏洞的地方。并不是不能避免，只是要去避免的话就要付出稍微多一些的力气。
这是一种现象，尽管看上去仍旧是游戏中走过那么多路程，编程里就写了那么多代码、处理了那么多逻辑，可是却需要付出更多的注意力才能办好。同样的完成量，这部分就比别的部分难做好。看上去都是一样的工作量，可是这部分需要付出更多的注意力才能办好。
如果想要有更好的容错率，就要把这一段做更多的处理，让犯错的几率小一些。分出更多的步骤来完成原本的任务。由于这一部分需要更多的注意力，那可能是面向了更多的方面。比如涉及内存管理和程序运行的话，过多面向内存管理就要占用很多里边相关的思考，而切换到业务思考之后可能容易忘记一些需要注意的部分。
有很多东西看上去可以自己一个人处理，或者很容易处理。可是处理起来的时候往往不那么顺意。这说明这些步骤中有不简单的元素，需要找出这些元素并且进行针对性处理，并把对这些元素的处理并到任务量中。等下次再路过这个地方，就可以更清晰地预估这片工作的任务量。然后可以分配更多的劳力来完成这个任务，从而增加容错率。
分配下来的代码任务，容错能力不好，往往说明分配得不好。如果做这份任务老容易出错，就说明这份任务不是看上去那么简单，涉及了更多的思考处理。很多框架的开发都是用来增加容错率，把需要注意但是繁复的地方用框架处理，交给程序员的就是一些灵活变动的地方，涉及的思考量相对减少很多，就比较容易达成。
编程有难有易，普通情况下都是按照普通水平来分配任务，每项任务都是普通难易度。这样编程的容错率就比较高。可如果分配的任务不是按照普通水准，要求每个工作人员都有很高的技术能力，那这种团队可遇而不可求。