**订单缴费服务
近期因为项目要新接入一个第三方的缴费服务，在整个项目完成的过程中，遇到了一些问题，当然最后项目安然上线。但是由于是第一次接触到第三方的接口和服务，因此确实体会还比较多，具体的技术细节上也接触到一些新的工具，感觉很兴奋。
此文主要从项目业务实现的角度，讨论个人对于项目优化的一些想法，具体的技术细节，会另外单独去写文。
- 第三方对接，大家好才是真的好
- 是否还有其他的实现方式？
- 关于项目开发的效率–文档和封装框架的使用
- 关于开源项目的使用
- 技术的意义就是完成业务的开发？
第三方对接，大家好才是真的好
Third-party interface, every part being good is genuine good!——from me
之前在开发项目的时候，有涉及到内部不同部门和业务团队的接口调用，但是大部分情况下，因为还算是在一个体系之内还都算比较顺利。然而这次接入的是一个第三方的服务提供商， 明显的在沟通的成本上要远远大于内部的接口调用。很多很简单的事情，其实都反复的沟通了多次，回头想想，其实也没有什么特别困难的点，其实都是沟通的效率太低了。
开发过程中，虽然有完整的文档，但是先后还是重复沟通的其中一些具体的细节：通信报文的加密解密方式 、报文报头和报体的格式约定规则 、关于具体约定规则的含义 、关于联调的环境配置问题等。虽然整个项目开发的时间还算充裕，但是确实沟通占了很大一部分。看来在这方面，咱们这边应该思考下，这沟通方式还是很重要的一个因素，如果这个沟通的效率很高了，开发的工期应该还能更短一些。
关于这一点，从我自己的角度来说的话，有一些值得反思的地方。本人决定对自己提出一定的要求，希望以后能从自身的提升将这类问题对项目的影响降到比较低的水平：
1. 提高对三方文档的重视程度，保证阅读后对技术细节完全理解
2. 在提问题之前，一定按照文档完成一个完整流程的demo
3. 对于第三方提供的demo一定要理解透，无论基于哪种开发语言
是否还有其他的实现方式？
Don’t be so serious, this is just brainstorm.——from me
这一部分主要是想思考一些，关于项目实现方式的效率问题。主要的角度就是考虑吹毛求疵，以便能探求和思考不同的实现方式对于计算机计算资源的利用率。
本次**订单缴费服务，采用的是windows服务的形式实现，并采用定时跑任务的形式去对付款订单进行处理。该服务包含两个job，一个job定时3分钟，另一个6分钟。假定在日常上班时间和晚上休息时间，一整天24小时，其中至少有凌晨5-6小时的时间，该服务占用的资源是无意义的。虽然每单次处理占用的资源并不多，但是几个小时的计算机资源如果积累起来，用作其他有实际意义的用途，也算是用的其所了。
按照最优的情况，就是用户在下订单的过程中，根据用户的下单之后，分配商家后，直接调用服务，然后订单即可直接根据返回的第三方接口状态直接确定订单状态（这里还涉及到一个商家分配逻辑和兼容其他第三方接口的问题，这里只考虑最优效率，不考虑兼容）。如果这样的情况，则需要在商家分配之后，根据用户请求的参数，动态进行判定，然后调用具体的服务接口，此处本项目的商家分配，由于历史原因，十分的复杂，个人认为已经到了需要考虑解耦的情况了，目前单个类的代码行数已经上千了。
此种情况下，只有用户在下单时，才对接口的调用进行触发，因此，不存在windows服务在闲时进行运转的资源浪费问题（当然，因为该第三方服务是实时反馈订单受理情况，因此可以采用这种思路）。
总结下来，如果提高效率和为了以后长久的项目发展以及维护，有以下几个事情需要做：
1. 商家分配服务功能解耦
2. 将可以实时反馈的商家处理订单加入解耦后的具体实现模块
3. 将不可实时反馈的商家订单处理加入消息队列处理
关于项目开发的效率–文档和封装框架的使用
Everything is software, all problems are caused by human——from me
在整个项目业务代码开发的过程中，我遇到了几个问题，事后想起来，个人确实受到了这些影响导致了效率的降低。1. 公司之前负责和第三方对接的另一个业务负责开发，告知他们的文档有错误，对接口提供方发表了一些个人的看法，之后我的印象就是第三方不靠谱；2. 在本公司内部开发的过程中，没有强行的要求开发文档和相关规范，业务开发团队各自分离，交接出去的成本很高 3. 公司内部的封装框架有底层方法不完整，这次项目就出现了实现功能相同，但是因为实现方式的不同，导致我们引用的时候，一个方法正常，另一个无法正常使用的情况。
项目在这样的情况下，目前业务团队相对比较稳定的情况下，问题并没有特别的显现。但是一旦出现业务的老人和新人的交接，或者团队开发任务的调整，则会出现对业务模块的熟悉时间和维护效率的问题。这样继续下去的直接后果就是，负责某一个模块的开发的工程师对自己的业务模块越来越熟悉，这个人如果离职，其原本负责的工作，交接和维护工作就成为一个坑。而对于这个问题，在上一家公司，本人就深有体会，各种坑。
对于这样的情况，个人认为重构的工作可以穿插在日常开发的工作中。具体的改善方法，可以从以下几个方面入手：
1. 技术总负责人，将手中的维护和开发任务逐步分散，重点抓各个模块的代码规范和重构工作。
2. 完善公共框架，并逐步的推进各个业务团队，替换零散的方法，保证代码重用率和安全问题。
关于开源项目的使用
Free software is software that respects your freedom and the social solidarity of your community. So it’s free as in freedom.——from Richard Matthew Stallman
其实关于开源项目的使用这点，更多的是我个人的体会。个人觉得目前项目中使用的开源技术和各种，已经远远的超过之前上一家公司的情况，感觉效率提高了不止一点。目前个人已经习惯性的在处理一个具体的业务实现时，首先想到的就是开源第三方框架的使用，这个对我个人来说是一个非常重要的改变。
在本项目的使用过程中，我接触到了以下几种开源的框架的使用：log4net, Topshelf, BouncyCastle, Quartz.Net, NOPI等。虽然公司的大神前辈可能觉得没什么，但是我再实际的开发过程中，用到这些框架的感觉，就是强烈的相见恨晚的样子。而且，在这过程中，个人也逐渐的开始了解和学习这些开源框架的原理和底层，随后就是各种对大神的膜拜。
个人决定设立一个远大的目标：
1. 希望在自己感兴趣的NLP领域，实现自己的开源项目。
2. 逐步的深入到开源社区，并尽量参与到相关工作中。
希望不久的将来可以实现自己的目标。
技术的意义就是完成业务的开发？
Any sufficiently advanced technology is indistinguishable from magic.——ArthurC.Clarke
我觉得上面的一句话已经足够表达我的观点了。并非所有领域都有机会可以随心所欲的幻想，然后凭借自己的双手，去实现整个所有的一切。然而，我坚信，科学和技术是最有效的工具，不过，如果你是一个自己给自己设限制的人，那对不起，你也许听不懂我在说什么。
科学和技术都是可以从前人的文字和经验学习的信息，然而也并非所有人都可以成为冯诺依曼，成为费恩曼，成为钱学森，成为比尔盖茨，成为乔布斯，成为谢尔盖。
这世界，除了眼前的苟且，还有诗和远方。
完。