其实想写这篇文章很久了，其目的不是别的，算是对自己过往的一个总结以及对未来的展望。当然其中有好有坏，有辛酸汗水，有喜悦与成就。
记得刚来公司的时候，没想到是接手某硕 公司的代码，这里就不明说是哪家外包公司了。知道的自然懂。刚接手完全是懵的，一个类几千行代码就一个方法。写的还是jsp里写业务逻辑的代码。对于习惯了前后分离的人是一种灾难，领导对于这种现状也没有提出异议，作为撸代码的我们更加就只能在他的上面加砖了。需要在原来的业务上增加新的业务只能在代码里面加if else 你可以想象那代码会成什么样子。终于有一天通过if else 的做法已经满足不了需求了，这个"重担"压到了我的身上。我还清晰的记得当时的需求是需要做一个新的贷款合同，而我一看以前的合同，不看不要紧，一看吓一跳。一个类三千多行代码，而且没有注释。领导给我一个星期，光看他们代码就花了两天。可想而知这次的效果是什么样的。承认自己的失败并不可笑，可笑的是你不能从这次失败中吸取教训。通过业务的熟悉以及第一次的教训之后。心中也就产生了一个蓝图。
这里说一下这样设计的原因：
为什么需要一个入参路由和一个实现类的路由。实现类的路由大家应该明白，为了统一入口，这样即使新增了合同。入口是不需要做任何改变。只需要增加路由实现类规则就可以了。入参路由是为了减少前端调用的最少入参，减少前端的入参压力。同时这也符合最少知道原则，调用方只要传入指定的几个与业务有关的参数即可。因为公司保密制度的原因，代码是贴不了了。只能在这里说一下实现思路。
- 这里解决路由匹配规则，我自己写了权重优先级匹配规则。同时通过自定义注解的方式，将每一个参数权重以自定义注解的方式注入到对应的注解中。同时将对应的实现类注入到spring中。这样就解决了每一个实现类与对应的匹配权重的对应。
- 参数合成实现类。这里采用定义一个调用生成合同的方法。同时用一个抽象类实现这个接口，同时新增获取参数、检查是否通过、调用、保存返回结果的几个抽象方法。这样设计的目的是为了最大程度的解耦同时最大程度提高代码的复用性。将这几个过程分解，一来让自己编写代码的思路更加清晰，二来如果需要取其中的一部分结果。可以很方便的返回。
因为时间的缘故 代码结构未能及时贴出，将在下次贴出。
总结
通过这次大致得出一个总结：在时间容许的情况下，我们还是尽量要做到对自己以及对后来接手你项目的人负责。其实这也是对自己的一种提高。写项目的时候最忌讳的就是拿到需求提手就敲代码。这是最致命的，俗话说 磨刀不误砍柴工 特别是做业务需求的时候，一定要了解他们所提出的需求，不要求你全部都懂，但是一定要知道他们做的动机是什么。不然就算我们写出来东西，也是不满足要求的，这样反而会给自己的职业生涯打上不靠谱的标签。大致就是这样了，如果还有更好的想法，欢迎私信！O(∩_∩)O谢谢
