淘宝商城店铺合并上线， 今夜无人睡眠（图）

经过两个月的奋斗， 淘宝商城店铺合并（五彩石）项目终于成功上线！
[img]http://macrochen.iteye.com/upload/picture/pic/29879/5129c68a-a8d5-3047-b880-be876be42fd1.jpg[/img]
项目上线， 对开发来说，还是相对比较轻松， 有吃有喝的， 差不多等同于在开party了：） 主要工作集中在SA， DBA以及测试人员。 要是开发还在忙的团团转的话， 那这个项目的上线可能存在很大的风险。不过对于这种大型的分布式应用项目来说， 系统上线对底层的基础应用也是一个很大的挑战， 你不知道那个地方会出问题。所以对平台架构部的人来说也不轻松哈！
[img]http://macrochen.iteye.com/upload/picture/pic/29883/ec73f46d-25bb-3de1-99fc-c838b6fa07b0.jpg[/img]
为了晚上的发布， 周六大家依然在公司做最后的代码检查， 吃完晚饭， 该回家的回家， 该休息的休息， 只等着凌晨的通宵发布， 十一点之后， 人员渐渐的多了起来， 淘客的， P4P的， 搜索的， SA， DBA， 架构组同仁， 纷至沓来。 于是大家开始做准备工作，凌晨一点之后， 开始停机部署， 切换数据库。随着时间的过去， 上百台服务器部署完毕， 当然中间也出现了一些小小的问题， 后台log中终于出现了异常信息， 于是大家开始一起分析。系统上线之后， 日志成了分析解决问题的重要依据， 因此如何在代码中打日志也是非常的重要.
[img]http://macrochen.iteye.com/upload/picture/pic/29885/bad5ef18-447e-3bdb-9be3-542f43e1c40c.jpg[/img]
系统部署差不多之后， 凌晨两点多钟的样子， 测试人员纷纷到岗， 开始对线上应用进行测试验证。 到凌晨4点多的时候， 也是人最困的时候， 没什么事情的开发人员， 渐渐有了困意，趴着的， 躺着的， 千姿百态。
八点之后， 整个系统发布基本结束， 大部分都没什么事情， 于是大家开葡萄酒（汗！怎么不是香槟？）以示庆祝
[img]http://macrochen.iteye.com/upload/picture/pic/29881/e8e86a03-7670-3516-926b-e794972b7c12.jpg[/img]
这个项目虽然是一个改造项目， 技术难点几乎没有， 但是做的也很辛苦， 几乎每天加班到10点以后。后来想了想， 为什么做的这么辛苦？ 逐渐发现原来在大规模团队“作战”中相互之间需要很频繁的沟通，比如查找已有代码的实现的沟通， 接口之间调用的沟通。了解需求要进行的沟通，很多时候基本上就是在和人打交道， 很多时候中途被打断而没有静下心来写代码。 还有一个就是如果一个问题存在多种解决方式， 各种方式之间的取舍也花了不少时间。是采用a方案好， 还是b方案佳，左右权衡，最终取舍等等。 同时中间也犯了很多不该犯的错误， 也对效率造成了一定的影响。在这个项目过程中算是真正熟悉了淘宝的开发流程， 和自己以前三两个人， 七八条枪的开发方式有很大的不同。
前事不忘后事之师， 因此总结一下还是很有必要的。
一个就是对需求的理解， 因为没什么技术难点， 所以了解需求就显得非常重要， 在开始的时候， 没有对PRD文档和UC文档没有刨根问底的熟悉， 导致最初的接口定的不是很理想， 很多功能实现的也不是很好， 中间出现反复的修改的成本。
第二个产品质量的要求， 以前做开发几乎没有做什么单元测试， 全手工验证， 没问题就上线， 在这个项目中前期没有关注测试， 主要是实现功能之后， 然后后期补的单元测试， 因为这个项目依赖很多其他的服务， 为了取消这种依赖关系，就需要对这些依赖进行mock， 这个做的不是很理想， 影响了写单元测试的效率。以前写单元测试， 主要是因为繁琐， 效率不高， 付出的成本获得的效益不成比例， 比如你辛辛苦了写了比已有代码还要多的测试代码， 结果没有发现程序的漏洞， 让人很没有成就感，所以都不愿去写它。在掌握了一些测试技巧， 积累了一定的测试经验之后， 测试是越写越顺手， 虽然没有达到TDD水平， 但是写完实现之后， 接着写测试， 和以前的感觉和心态大有不同， 在这个项目中也知道了怎么搞持续集成（CI）这个是个很好的项目构建的最佳实践。
还有一个就是团队合作， 之间的接口定义的问题， 当淘宝从以前的需求产品化， 到现在的产品服务化的转变之后， 很多公共的东西都放到平台的各个中心， 以服务的方式向其他产品开发人员提供， 这就要求， 服务的接口定义的要合理， 让人容易理解， 而接口主要包括两个部分， 一个数据模型， 一个就是服务方法， 模型要合理， 通用， 能满足不同应用的需求， 接口方法则需要做到灵活， 能满足大不多数产品的需要。 因此这个就需要对各个不同部分的需求进行整理， 能分清那些东西应该纳入服务中， 那些东西需要客户端自己实现。
最后一个就是代码的严谨， 以前做的应用都比较小， 所有东西都是自己实现， 因为对于方法调用传递的数据， 大部分都还是了然已胸， 很多情况下，对数据的验证可以根据需要来进行处理， 当进入分布式服务化的应用之后， 当没法对参数进行约定之后， 就必须对数据进行严格的验证。 为了保证程序的健壮性，即使有些验证可能不是必须的, 也需要去做。