一个非常简单的例子，反映了很多开发人员的通病
最近在项目中接到一个任务，我负责后台开发，另一开发人员负责前台开发。任务非常简单，请看下面的类图。
A和B有一个单向的关联关系，现在要为A增加一个属性boolean resident，该属性值有如下简单的业务逻辑决定（伪代码）：
if(a.x == a.b.x)
resident = true;
else
resident = false;
前台的查看页面需要显示这个值，当用户修改a.x或者a.b.x时，要触发一个事件，实时的在前台更新resident，后台需要以这个resident来
做某些业务逻辑的判断。
我们知道，由于resident完全可以由a.x与a.b.x决定，属于一个冗余数据，不需要显式的增加该属性。很快，前台的那位开发人员就轻松的
告诉我，这个任务已经写完了，原来他是在页面写了一个JS脚本，当a.x或a.b.x发生改变时，触发一个onChange()事件，里面就实现了上述
的逻辑。我一看，感觉问题来了，然后我告诉他，我已经在后台的服务提供了一个方法，用于判断resident的值，他应该在事件触发的时候
，通过异步方式调用后台方法来获取reisdent的值。他一听觉得非常奇怪，这么简单的逻辑，为什么需要使用异步方式去调用后台这么麻烦
，于是我就从设计的角度跟他解释，resident由 a.x与a.b.x决定，这是一个业务逻辑，从职责划分的设计原则分析，前台只负责显示逻辑，
业务逻辑属于后台的职责。接着，他又提出了疑问，说这里其实只有一行代码，没有必要分得那么清，这样调用不但麻烦，而且性能相对较
低。
这个例子，反映出了很多开发人员的通病，没有真正从事物的本质考虑问题，只从代码的数量去考虑。
上述的做法存在两个问题：
1.开发人员没有从职责划分的角度考虑问题，而只是贪图一时的方便，或者觉得简单的一两行代码不需要进行设计，但实际上，上面的问题
必然导致重复代码。上面的例子，即使只有一行代码，但在系统的前后台却出现了两份相同的逻辑，假设以后某天业务逻辑发生了变化，那
么，必须在两个地方（甚至更多的地方）进行修改、测试，如果漏掉了一个地方，就会导致Bug的出现。作为一个开发人员，如果不注意这些
细节，随意的拷贝和重复代码，长期下来，一个系统就会遍布无数的重复代码，系统越往后期就越难维护，最终陷于崩溃。
2.如果作为后台开发人员，看到前台已经实现了这个逻辑，而在前台往后台传递数据的时候，把resident也传递进来，从而认为后台就不需
要重复这段逻辑，直接拿着前台传过来的这个resident来进行业务判断，那么就可能会给系统带来致命的漏洞，因为数据在传输过程中，很
可能被有意或无意的修改，不在后台进行业务规则校验这个错误是常见的，但也是致命的。
有一个原则开发人员特别容易犯，也一定要切记：
在Web应用中，相信客户端提交的数据是正确的，不在业务层进行校验，这是致命的错误。
笔者会在下一篇博文中，详细说明某国内著名的第三方支付平台，因为犯了这个低级的错误，而导致系统出现致命的漏洞，敬请关注。
Feedback
