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