「统一开发平台，程序沙漠中的海市蜃楼，是那触不可及的天空之城。」

曾经在一家小公司工作一段时间后被一个大集团收购。 集团旗下有十多个小公司，于是开始推行一种统一开发平台，统一所有开发人员的开发模式提升规模效应。 我曾使用那个平台进行业务系统开发，一套使用XML自定义的简化程序语言加上内嵌的特殊的业务函数。 它只能在特定的测试机上进行程序解释翻译调试，编写的过程，也不需要IDE，只用文本编辑器足够。 调试是个黑盒子，错误定位极其困难，业务开发人员被解脱为只需要懂业务流，不需懂技术。 我大概在这样的平台上工作了2个月左右，就离开了，只是觉得呆的越久恐怕退化的越厉害了。

如今开始思考，何为统一开发平台？ 在一个以千人为规模的大团队中进行软件程序开发，我认为没法进行真正完整的统一。 让所有人统一OS、开发工具、代码规范、文档描述，技术选型范围，何其难也。 而且规模越大的公司进行完整的统一越没必要，因为影响了个性，阻碍个性化往往很多时候也阻碍了创新。

从生物进化论的观点来看，人类最终主宰了这个星球。 那必然是经历了无数年月的优胜劣汰的自然选择，人类传承的根源在于小小的受精卵也就是基因。 在一个组织中最先统一的应该是其基因及其生长环境，让小小的受精卵最终孕育发展成长为人。 如果最终长成后是一只猪，那么从一开始基因就错了。 基因的形成过程，本身就是一种自然选择过程，一旦形成优良基因，其生长环境的统一性、稳定性、长期性极其重要。 站在技术人员的角度来说，这种环境就是一种技术文化、氛围、管理体制的统一性、稳定性和长期性。

人与人之间既然千差万别，类同于每个程序员或者小团队的技术实现方案都会千差万别。 人虽外表不同，但不同的是血肉，不同人的骨架置于一处又发现没多大区别。 人的骨架本质上是统一的，不多不少都是206块骨头，这是生物进化无数年的最终结果。 那么在软件开发团队中真正需要统一的是骨架，而非血肉，难题是如何去定义哪些属于骨架，哪些属于血肉？

1996年左右出现的SOA，是行业智慧先驱探寻软件规模化设计、集成解决之道，它不是一种技术而是一种思想。 如今服务化的思想也算深入人心，但服务中最本质的部分，不在于服务接口抽象、实现技术，而在于服务契约。 契约精神构成了人类商业社会的基石，那么服务契约也充当了SOA体系架构中的基石，由所有的开发人员共同遵守、维护和支持。 大型软件系统体系结构中，每一个小小的服务充当了构成完整骨架的骨头，骨头的形状不同、硬度不同、粒度不同、作用也不同。 每一个服务背后的实现技术更是千差万别，但服务契约却始终一致。 契约不会永远不变，却不会频繁改变，在所有服务的关联方都达成一致的情况下，慢慢演进。 最终，服务的一块块骨头组合一起，构筑成完成的系统骨架体系。 服务之上千变万化的业务需求正如人之血肉，骨架稳定而血肉多变，骨之不存，肉将焉附。

最后，谈谈实现服务的具体技术，正如构成骨头的材料，骨头功用不同，材料自然有不同，但更多的部分却相同。 服务实现技术，依赖具体的服务契约说明，不同的约束，自然选择不同的实现技术，功能、性能、易用性、易运维性、扩展性，一个都不能少。 在一个大型团队下划分的许许多多小型团队之中，一个共享的知识库必不可少，由不同的团队成员共同维护、交流、发现交集。 大体上我们可以把服务划分不同层次和粒度，统一不同服务层次和粒度间的契约，而非实现技术。 从层次上说，可以划分为：

1. 硬件服务
   不同的程序对硬件的需求不同，有CPU密集型、磁盘IO密集型、网络IO密集型等等，所以需要底层灵活的硬件选型平台等。
2. OS 服务
   计算资源、存储资源的分布式迁移、伸缩等。
3. 数据服务
   关系型、结构化数据访问。
4. 中间件服务
   异构系统的同步、异步通信（RPC、消息中间件）等。
5. 业务服务
   面向终端的业务接口提供者。

服务层层传递、依赖，有效的划分服务职能和切分粒度。 小团队负责制，术业专攻，契约明了，也许才是规模化软件开发，优化资源配置的一条有效之路。 而统一开发平台，正如天空之城只存在于宫崎骏的动画中。