之前有看到一份代码，同一个应用中两个不同得模块用反射访问，在访问得函数中通过Binder方式获得另一个模块得数据，从parcelable里面把map数据解析出来，当时看到这个设计，我是百思不得其解，为何一个小小得调用为何要搞得这样复杂，而且调用得地方写得很隐晦，还不容易搜到对应得代码，当出问题得时候，两个模块的人都认为是另一个模块出了问题，因为这个调用过程有点复杂，代码不太好阅读，正好复杂部分又在两个模块交界处，这给后来的维护人很多的麻烦。
其实，写代码不是秀技术，恰到好处的代码设计才是最好的，不足和过了都不好，想上面这种，应该有一个统一的代码访问接口，直接传入map就行了，不必要搞一大堆，不好看，也容易出错。
有看到两个应用间，一个界面应用依赖另一个界面应用的数据，否则应用就没法起来。这样的设计也太不友好了，依赖的应用应该要做防御性设计，不信任设计，数据提供端，可能会出错，可能会失败，可能会延迟，那么我需要有一个方案等待数据完备，我才进行相应的操作。如果数据又问题，那么，应该自己先内置一份，当另一个应用准备好数据再更新，这是客户端，服务端的常识性设计。否则，这样的设计动不动就崩溃，用户体验极差。
有看到一份服务端代码设计，一上来就是线程池，缓存池，异步方案，其实，客户端的调用很少，直接使用就好，反而造成客户端调用麻烦，浪费资源。这就是明显的过度设计，设计初衷应该是方便使用，方便以后的扩展，但是以后的扩展不能预料到，那还是要一切从简，先将变化交给需求的客户端。当需求不能被满足时，就要考虑去重构。
重构应该要在开发里面形成一种常态，针对各种设计，过度的，复杂的，还是不足的，都要随时准备好重构。
