记一次jQuery+WCF页面的离岸协作

时间：2011-03-12 来源：嘉瑜

背景：与美国某公司的一个离岸外包中的一个页面，最后交付物为，20来多存储过程，3000行左右的C#代码量，2000行JS代码量，7个jQuery plugins，参与人员及职责：

BA一名（美国方），负责把握进度、控制风险、阐述需求、解答需求问题。
Application Developer（美国方技术接口人），负责建议/帮忙解决开发中出现的技术疑问，负责C#及SQL Code review，审核代码质量、安全性和性能，负责性能测试。
jQuery前端开发人员（美国方），是临时从另一个项目中调派过来的，负责所有前台的代码，包括jQuery及插件的使用和选择，与BA沟通确定方法接口，负责解决客户端有关的性能问题和BUG修复。初期稳定后，会撤离项目组。
C#和数据库（我），负责所有的C#、WCF和数据库相关开发，BUG修复，稳定后的维护工作。

难点：

离岸协作，16小时时差，即美国上班时中国在睡觉，所以基本都是美国方在加班与我进行协作，通常都是他们晚上9~11点，我这儿中午12~1点。
代码交付问题，尤其是前后端的衔接非常紧密，所以若有一方因为代码交付问题，另一方则会完全被stuck住，风险较难控制。
由于使用典型的敏捷迭代，所以时间的要求上其实很急，规定上线时间根本没得商量，如果不能完成只能等下一次迭代。
各种新技术：采用全新jQuery dataTables展现grid，后期使用线上数据库才发现性能完全不行。性能测试不足，出现之前没有预料的问题。
沟通，我这边的老大曾经建议过直接onsite开发，不过美国方没有同意，这个页面因为需要无间的配合，所以对沟通的要求其实很高，我们后期是采用的每日~每两日一次会（会经常持续达半~1个半小时，有几次甚至达到了2小时，包括我和前端讲述头天已完成项，整理BUG完成情况，讲解新发现的BUG，指派新BUG的负责人，列出明日交付计划等等），每天必须使用邮件来更新开发进度并列出明天的计划和交付。倘若交付出问题（也确实出过），整体交付的日期会延迟。
整个过程使用英语沟通。
其它。

我们的协作方式：

由BA确定需求时，对方技术负责人告知前端与我的技术需求、扩展和重构，
我之前从来没用过WCF，我需要在这期间做出WCF POC，更新我的auto-complete控件使之支持WCF，
前端需要了解dataTables等相关技术。
（耗时一周左右）
初步需求文档，列出主要web methods，当时一共只有15个，在这段过程中web methods的命名和需求往返超过不下于8次
前端给出后台需返回的JSON结构及request参数等。
任务分解。
前端进行页面代码的初步编写和插件研究；我同步进行数据库设计，后台代码框架等，并做出几个初步的web methods，准确代码合并。
第一次代码合并是比较痛苦的，因为前端会改我的后台代码，他本身也懂C#，这样我们经常会有代码冲突，于是此时美国的技术接口人提出了协作原则，洋洋洒洒一大篇，即双方不允许互相修改对方代码。我补充说，希望每天有一次进度汇报，包括change log、明日计划、needs等。
第一次合并后，发现问题很多，比如我写的web method对方不能使用或出错，第二次我就开始做unit testing，每个方法都使用Nunit进行过单元测试，这样大大提高了我每日后台代码的交付质量。
在开发阶段，每天会有一次这样的报告，发现BUG会及时汇报，每日back and forth不下于5次，好在美国方总在晚上8~11点能联系到（即中国时间早10点~中午1点），所以这期间能clarify很多疑点，总之每天计划都能完成，第二天另一方会收到相应的代码更新。
开发近一周半后，第一个版本发布到DEV服务器上，初步测试开始，BA生成简单的excel文档记录BUG清单，excel包含2个sheet，一个列出bug，一个列出尚未实现或打算实现的功能。每天会有一次电话会议，来确定这些BUG的负责人，并写上计划完成日期，每日有更新。每日会有一次构建，都会在DEV服务器上发布新版本以供BA测试和检验BUG修复情况。新BUG仍然会有层出。这个BUG清单最后有80来条，各种大大小小包括performance和页面布局问题等。
第二次成熟版本发布后，对方使用线上数据库（dune版）来做性能测试。性能测试的结果，比如：loading会有timeout的错误，正式发布前都有处理。
全部的回归测试。
发布上线。从协作开发到第一版本上线一共耗时一个月整。

关键词：

任务：任务分解、初期需求不必完美、过程控制、任务负责人清楚明确
沟通：每日进度汇报及计划、快速跟进修复BUG、积极响应、频繁会议、清晰沟通、无情绪沟通
测试：单元测试、性能测试、集成测试
交付：严格遵循不修改对方代码、bug tracking、遵行每日计划交付目标、后期每日构建、允许迭代

遇到的技术难点：

上线后，当即发现另一个性能问题，因为使用jQuery datatables我们当时并没有做服务器分页，所有filter和pagination全部客户端，即提交查询请求后，从数据库返回全部数据（比如5000行），形成庞大的json串会导致出现script无法响应强制终止脚本的提示。BA当即只能决定将先只返回800条查询数据，在第二次迭代中再想办法提升。
另一个性能问题就是左侧层级列表，数据量不少，页面载入后，分别有左侧4个及右侧3个widgets的数据需要异步载入，第一次访问页面的速度很慢。使用cache也不能很好解决这个问题，只能将左侧jstree做成服务器端异步提交显示。
end-users的反馈很强烈，很多人使用得不习惯，很多抱怨和反馈纷至踏来。
很多东西都必须改，第二次迭代开发开始。

我们开始第二次迭代：

所有存储过程都需要分页，问题比较麻烦，因为存储过程和C#方法有27个之多，如果每个存储过程都必须加上7个参数（startFrom, limit, sortBy, totalCount, Archived totalCount, etc)，每个接口也必须如何加上7个参数，所有方法都需要动。
左侧jstree需要改动。
更多performance tunning。

我们开始第三次迭代：

由于客户端已基本稳定，前端退出开发团队，我继续进行维护工作，并需要了解所有使用到的前端技术和jQuery插件等。客户反应渐好。

总结：

深刻感受到西方的敏捷开发模式和不带任何非工作以外情绪的沟通方式，很受启发，很喜欢。
交付质量和承诺至关重要，否则一天的耽搁，可能会引起两到三天的延时，严重者会使进度失控。
一个小遗憾：我做出的WCF其实并没有体现WCF data contract的优势，仍然返回JSON串，可是时间太紧，一直没有去解决这个问题。也是后期想要解决的。