接口开注意事项.docVIP

第一：接口开发的流程问题。 接口开发的大致流程：1.和第三方讨论需要实现哪些接口。重点是要确定每个接口的具体功能。接口参数在开发过程中常常会有变动，所以讨论中一般不会明确定义。 2.编写详细设计文档。文档包括接口名，参数名，参数类型，返回消息格式等，并提供给合作方。 3.编码接口根据实际需要进行调整，同时更新详细设计文档，保持接口详细设计的可追溯性。 4.测试包括接口内部测试、修改，和第三方的联调。 5.上线接口正式上线，测试通过则上线成功，失败则回退,并从第4步开始新一轮的测试，直到系统上线成功。 常见问题：1.详细设计文档应付了事，甚至不写设计文档。实际的开发过程中，由于时间的原因，或者开发团队对设计文档的不重视，造成有的开发者忽视接口设计文档的作用，甚至不写设计文档。 设计文档的缺失，往往会造成：人员流动时，系统无法顺利交接；会给接口的升级，带来重重困难。 2.不按合作双方的接口定义，私下决定不实现某些接口。这种情况不一定每个人都会遇到，但我确实遇到过这种事情。某一次和一个比较有名的体育社区的合作过程中，由于我们的平台是类电子商务的，所以要给用户建立财务账户，如果我们系统中不保存用户的基本信息，就没法为用户创建账户。 所以我方提供的接口文档中，有一个注册接口，需要用户在体育社区的注册时，同时把信息传递到我们的平台，这样我们就会为这个用户创建财务账户，否则，用户登录时就会有问题。 合作方对接口文档没有提出异议，但双方接口上线一段时间后，一次偶然的聊天过程中，对方开发人员透露，他们根本没有调用注册接口。吓了我一大跳，多亏我们前期的设计和编码中考虑得比较完善，否则，接口上线后，不堪设想。 所以，大家一定要遵守事先的约定，不要违背事先的约定，否则会出大乱子。 第二：接口开发过程中，发现原有功能设计有不合理的地方，应该对系统重构，还是仅仅实现功能了事？以我的经验而言，总的来说大多因为原有接口缺乏可扩展性，导致添加新功能或者接口更改后代码冗余的问题。究其原因，有下面几种情况的原因： 1.开发周期比较紧张，来不及对原有代码重构。 2.开发人员懒得去重构，或者不具备重构的能力。 个人认为，这些问题归根结底要由开发流程来约束和控制。 开发周期紧张的情况下，技术负责人一方面要争取尽量多的开发时间，另一方面要根据开发任务的难度安排水平尽量高的人员来做；如果高水平的人员有了，时间还是紧张，可以考虑在以后某个合适的时间来重构这部分代码,千万不要让这部分待重构的代码永远的等待下去。应该制定合理的重构时间表，作为正常的开发流程的一部分。 第三：技术负责人在系统构建过程中应该担负哪些责任？ 无论系统对外接口，还是系统内部功能，都是整个系统的一部分，都是技术负责人的控制范围。 个人认为技术负责人应该对开发流程的建立、系统质量负主要责任。能否建立合理的开发流程，能否领导开发人员产出高质量的软件系统，是一个技术负责人是否合格的很重要的判断标准。 就算开发团队中，开发人员数量充足，水平够高，但是开发流程不完善，缺乏合理的约束，往往会导致一部分人滋生得过且过的心态，编码完了基本上就算了事。有的人争取尽量多的空闲时间来学习新技术，为将来谋划；有的人刚接了私活，人家催的比较急，需要上班时抽空做呢；这种情况并不少见，怎样在这中恶劣的情况下保证开发工作在规定的时间内、高质量的完成？没有严谨的、合理的开发流程根本不可能领导这些各怀心腹事的开发人员研发出高质量的系统。 个人认为，技术负责人一定要抓住软件开发过程中的三个关键点：测试、代码复查、模块重构，一定要重视再重视，程序员和老板讲解它们的重要性，他很可能不明白其重要性，但是技术负责人千万不能不重视这三个环节，如果您都不懂或者不重视，那最终产出的是什么样的系统，大家可想而知了。 以下是面向接口编程的一个简单例子，主要说明了设计过程中的一种思路： 原始需求： 系统提供和其他相关系统的调用接口，能够方便的将其他系统的文档导入到文档管理系统(java编写)中。 // 定义接口 import java.io.FileOutputStream; public interface OperateFile { // 导入文件 public boolean importFile(String path,String name); // 导出文件 public FileOutputStream exportFile(String path); } // 实现子类 import java.io.FileOutputStream; public class OperateFileImp implements OperateFile{ public boolean importFile(String path,