高级软件工程Pair work之 IP-GeoLocation module

本次Pair Work由我（李亚韬）和林萌做结对编程，任务目标是在Academic Map中加入用户地理位置定位的功能。整个项目的平台是SilverLight，两人都没有经验；不过好在前端的事情，略微放狗即可解决（这么多年都是这么搜过来的，不是吗？），于是我们就把注意力集中在了核心功能的实现上。

获取用户地理位置——一拍脑袋，两个人便想到，抓IP！抓到查个数据库就搞定了！但是深入调查这个问题后我们发现，Internet上存在的数据库，要么是商业版本，要么有版权问题，要么完全免费但是精度就下去了。另外就是针对某个国家的IP库都比较准确（例如针对中国的IP数据库，可以精确到网吧的某台机器，实在可怕），但是全球范围的数据库精度都不理想——我们也不能把所有国家遍历一遍，挨个汇总它们的IP数据库，工作量太大。

就在事情即将陷入僵局的时候，林萌从网上找到了一个免费的Proxy，外层的接口是一个WCF服务（可以轻松地在SilverLight中调用），内层核心是由 MaxMind 公司提供的一个专业数据库的Demo接口。话不多说，两人开始编码。一盏茶的时间便出了结果——定位成功！地图视口中心成功跳转到了Redmond总部。两人大喜，乘胜追击，熟练运用包括画图板在内的一系列工具，制备了一些共前端使用的图标元素，扔进地图里，测试通过，然后就Check In了。

我们略微得意地向邹老师汇报了代码运行的结果，没想到却得到了否定的反馈结果——为什么要使用一个来路不明的第三方定位服务？它的负载能力如何？能否持续稳定运行？一旦它崩溃，FailSafe补救措施是什么？

句句直捣问题核心，二人一时间无言以对。最终只能决定，推倒重来！

既然使用第三方定位服务的方法不可行，那么就寻找一个IP数据库搭建查询服务吧！在陶宇同学的帮助下，我们找到了一个免费而又不存在版权问题的IP数据库，号称精度达到97%以上。我随机地使用经验测试了各省DNS服务器，定位都没有问题，于是两人就开始动手了。关于大量IP和坐标数据如何存储，我们的策略是用一个可以做二分查找的有序结构存储数据——查找代价比HashTable略大，但是内存占用会小一些。当得到一个IP的时候，将其转换为32-BIT整数，在IP表里搜索小于等于这个值的最大元素，即可得到该IP的号段。这里要对C#（和.Net）吐槽一下，竟然没有支持lower_bound和upper_bound方法的有序容器！还好数据库中的IP都是有序的，手动办一个二分算法也不是什么难事。林萌负责导入数据，完成后换人，我实现了二分和服务初始化的外围工作。工作不算轻松（一路上遇到大量谜一般的问题），但是总算也是在一天之内完成了。

当晚测试，结果让人失望——第一次真正意义上的定位，就直接从Seattle飘到了San Francisco。出现这样的结果也不意外，因为MS内部的网络配置比较复杂。我又随机地测试了一些各地IP，得到却是正确的结果——这就很没有说服力——连Demo展示都做不到，还怎么让别人相信它的准确率？我们只能继续寻找更好的解决方案。

闲逛上网的时候发现，W3C在HTML5中规定了浏览器端实现地理位置定位的接口。搜集资料发现，各大浏览器均支持这个接口。这时我隐约感觉，嗯，要翻盘了！于是两个人又编写了一些前端JavaScript代码，测试发现，效果相当好，定位迅速而准确——而且这个接口是由微软官方维护的，稳定性与耐久性的问题不用再担心了。之后几天，我们又将第二种方案作为Fail-Safe方案加回了代码中，这样定位失败的概率就微乎其微了。至此，主线工作全部完成。

与林萌在一起做PairProject是很愉快的事情，两个人轮番上阵，互相能够给对方提示与支援，工作效率非常高，这也加深了我对结对编程优势的理解。:-)