又是接口若的祸

 接口问题似乎是编程人员心中永远的痛，在开发过程中不知道有多少矛盾产生于此。这不前几天我们在开发的一个项目又遇到了这个问题，事情原本很简单，开发人员A是负责编写底层函数的，开发人员B负责编写上层函数，当时规定了严格的接口（用C语言开发，通过一个结构来进行参数传递）。按道理说不应该有太大的问题，但B在调用A编写的底层函数的时候却发现，当他把赋好值的结构传递给A编写的函数后却得不到正确的结果，于是便找到A要求A对其函数进行纠错，A经过一天的查找发现自己的函数没有错误，而问题是在B传递过来的结构中的参数不对，原来在这个结构中存在一个字符串变量，由于A在这个字符串赋值的时候没有对字符串的长度进行检验，发生了赋值越界，结果将后边一个int 形的数据覆盖了，问题找到了，处理起来一点也不困难，只要B将自己的代码进行适当的修改就可以解决这个，谁也没有想到的是B不肯承认是自己的问题，反而责怪A在编写底层函数的时候没有进行数据检验，A自然认为自己很无辜，于是问题闹到我这里来了，我让他们把各自的源代码都拿来，通过走查，发现A的算法没有问题，而且在函数的入口处做了数据合法性检查。而B的函数存在很明显而致命的问题――数据越界，而且在数据输出的时候没有进行数据检验。问题明晰了，如何处理也就很简单了，我不想多说了，但在大家处理借口问题的时候有几件事情希望大家注意：
１接口一定要详细、稳定，不要多变。
　  接口要详细稳定，不要经常改变，这个道理谁都明白，但在实际工作中，当你使用一个新开发平台进行开发的时候往往很难做到这一点，特别是对于一个新手，由于对开发平台了解不够往往忽视对接口的设计，造成接口的经常性变化。在这种情况下可以采用以下几种方法来解决问题，一个是要编写一些demo程序，通过这些demo程序来了解开发平台，这对确定接口很有好处，二尽量少传递简单变量，而采用传递结构或对象的方法，这样即使发生了变化也便于修改，三宁可多传，不要少传。除了极少数的程序，现在的代码对于多传几个参数不会对系统性能有很大的影响，在实在没有时间的情况下，宁可多传参数而不用也比到时候参数不够无法进行操作好得多。当然这种方法这是一种临时的应急的方法，不可多用。而且，在以后一定要进行优化。
２接口一定要有书面记录。不能仅仅是口头约定，
    口头约定一般是在时间非常紧张的时候或开发人员开发关系很密切的时候经常出现的一种现象，一般来说开发人员认为这种口头约定的不会影响开发，但实际上这种情况往往是产生编程问题以及破坏同事关系的主要源泉。俗话说好记性不如烂笔头。无论当初说得多么好，彼此之间也会存在一些理解上的差异，而且随着时间的流失，还有一个遗忘的问题，最后一个可怕之处是：一旦发生问题的时候无法确定责任，因为没有书面文档，一旦发生的争执，领导往往会各打５０大板,而工作人员都会认为自己是冤枉的，影响彼此的合作关系。所以在这种情况下，还是费一点力气,将接口记录下来比较好.
３接口不但做输入检验，还要做输出检验。
    接口的输入和输出都要做尽可能的做检验。很多情况是如果只是在底层函数做数据合法性检验是无法验证数据的有效性的，接口上方的高层函数在调用底层函数的时候也应该做输出数据的合法性检验，很多时候往往是由于接口传递了错误的参数而导致接口出现问题。此外，一旦发生接口问题，首先要检验的就是确定接口传递的参数是否正确，在保证参数传递正确的情况下，再去寻找算法错误。
４在有关接口的问题上应该相互协作，不能推卸责任。　
    所谓推卸责任是指两个方面：一个是在接口约定不太好的情况下很多操作放在接口的两头均可，这时候如果双方都推卸责任,而矛盾也就因此产生(特别是在工作紧张的情况下)，另一点是一旦在接口处发生问题，作为上层的开发人员一定要保证输入参数的正确性，另外还要协助底层开发一起解决问题――很多情况是因为设计的问题，底层函数无法利用现有的参数完成相关的操作，在这种情况下如果没有上层开发人员的协助，底层开发人员是无法完成程序的修改。作为底层开发人员应该保证函数的正确性，此外提供相关的数据检验和返回提示,帮助上层开发确定问题的发生原因。
    总之，接口问题是虽然是我们在协作开发工作中最长遇到的问题,但并不是一个不可解决的问题，有时候人们的心理因素的影响往往大于技术因素的影响，正视这些问题是我们解决这个问题的关键。