[附加题] 结对项目对接的苦痛

 

[附加题] 结对项目对接的苦痛

本次很荣幸地，我的程序作为很多程序员队伍的备胎计算模块被加入了各大程序的附加题参考中，有以下几位同学都曾与我进行模块的对接：

• GNU_Linuxer
• 马克斯
• kanelim
• PocketPanacea
• kibbon
• ruoyuwang
• 夜微凉evol

苦逼的计算模块—快被吐槽死了

先来谈谈我作为计算模块的提供者的感受吧：

总的感受就几个字：请别吐槽我了...

我的代码质量我觉得还是可以的，但是在这过程中出现的最严重的问题是啥呢，是设计的问题，是设计者对于需求的理解和框架、接口统一与否的问题。

关于计算核心质量，不同的人的看法有着天壤之别，比如ruoyuwang组在我给他们计算核心与简短的使用说明后，他们就很成功地对接上了我们的模块，并且表示还是挺好用的。当然这过程中也有一点点曲折，我的计算模块单向引用了我的UI模块里的一个静态变量，原来是为了能够动态更改Grade.txt的生成路径使用（现在想想这种做法也真是下下之策...）。因为若愚同学要的早，一开始给的不是封装好的dll模块，而是一堆计算的.cs文件，而最后若愚同学他们拿到后编译都编译不过...虽然改动是比较好改吧，但是我的这种设计上的小毛病也是为他人带来了非常大的不便，真是非常抱歉...同样的问题也出现在了江昊同学那里，对这两位同学表示歉意...

在跟kanelim的对接过程中产生了比较大的问题，因为他们是用xml传参的，所以我们就又做了一个用xml传参的前端与后端给他们来对接。但是我发现一切根本不是想象中的简单...即使两组都是使用xml传参的，但是kanelim组增加了很多功能，他的前端和我的后端基本没有办法对接：他的很多附加的小功能我们组都没有实现，而他们的附加功能是在计算模块里扩展的。最后勉强用我们的前端在改动了xml有关的代码后，算是对接了。

但是最严重的问题出现在跟GNU_Linuxer组的对接上。我们的计算核心和他们的前端完全不匹配，问题主要是出现在一个设计的思路上：是前端做写入文件的逻辑，还是后端做写入文件的逻辑呢？在他们组看来，后端应当是一个纯粹的计算模块，就像一个库一样，计算模块就只需要有计算模块该有的功能。

而我们的程序，就像是为scanf加上了默认读取文件路径一样，有了许多的附加作用，这些本来看起来为了开发者方便的附加作用现在成为了对接上最大的困扰，然而降低了对接组对接的效率，从而导致鸣神对我吐槽不断。

而我在第一次尝试对接失败之后也反思了自己的原因：确实我们的计算模块不像是个类库，倒更像是个一键式程序：给你提供三个函数，你不同的功能调用不同的函数，一步到位，信息隐藏得十分隐秘。简短的几行代码就可以完成复杂的功能，不需要做额外的事情，只需要将它和对应按钮的Click事件绑定就好。

这样真的是好的做法吗？我在对接之前还是信心满满的，因为我觉得它最大程度地遵守了信息隐藏的原则，最后只开放一个公共类可以让你调用几个函数，这确实做到了很好的“封装”。但在逐渐的思考过程中我发现，实际上我“意译”了老师的需求：作为一个计算模块，就该是计算模块的样子，就不该牵涉到文件的写入。计算模块带来的副作用，违反了接口设计规范里的单一职责原则，是超出其职能范围的一种误操作。

在这过程中我还反思了另一个问题：我作为计算模块的提供者，究竟要不要为了更好地适应做出不同版本的计算模块？这样是不是有违松耦合的原则呢？我是不是只要做一个能实现基础功能的计算模块就好，其他改动需要前端去适应呢？我一直在想这个问题，因为鸣神组最后是通过前端的更改达到对接的目的，而其他成功对接的组最后也都是略微修改前端而达到目的。而除了GNU_Linuxer组使用前端写入文件，其余组都是使用后端写入文件的。而除了kanelim使用xml传参，其他组也都是比较普通的传参形式。

所以我现在还不太明白，当前后端对接较为困难的时候，是需要设计理念略差的一方做出更多让步呢，还是根据便利来进行改动？这设计理念不同，又如何评判略差和略好呢？希望老师能够解答我的疑惑哈~

农奴翻身做主人—还是得自己适应

那么说完我作为计算模块的提供者，就再说说我作为计算模块的使用者的感受吧。首先是kanelim组提供的计算核心，我个人觉得模块本身没有任何问题，质量很高，也写了不少公用函数的Xml函数注释说明。但是我亲身体验下来，还是觉得略微繁杂。因为他们实现附加功能的函数也一起被暴露，所以在挑选函数进行组合成我要的功能时经常会混淆函数的作用——即使很多函数有较为良好的说明，但总有漏网之鱼。所以对接最终勉强成功，时间花费较长。

再来就是kibbon组的核心，他们组提供了六页的API文档，但是都不是我想要的功能超强的God或者God's son函数...因为函数划分太细，相当于自己需要很多的函数进行组装以及拼合才能组成最后的功能，我个人觉得略微蛋疼。

鸣神组的核心虽然说明不多，但是最后调用的时候还是挺方便的，唯一的问题在于我之前不是在前端写入文件，所以补充了比较多关于写入文件的代码，最终才能成功运行。（吐槽一下小丽叔写代码基本不写注释的坏习惯！）

本次项目对接还没有完全做完...(还有三个小矮人需要接洽...白雪公主与七个小矮人的故事哈哈哈）。就算是这样我也一样感触颇深（感觉为啥一点都没有当主人的感觉），再有新的感受会及时更新~