`
tulunta
  • 浏览: 356813 次
文章分类
社区版块
存档分类
最新评论

破阵子·道 - 天空之城:统一开发平台

 
阅读更多

曾经在一家小公司工作一段时间后被一个大集团收购,集团旗下有十多个小公司,于是开始推行一种统一开发平台,统一所有开发人员的开发模式提升规模效应。

我曾使用那个平台进行业务系统开发,一套使用XML自定义的简化程序语言加上内嵌的特殊的业务函数,只能在特定的测试机上进行程序解释翻译调试。

编写的过程,不需要IDE,只用文本编辑器足够,调试是个黑盒子,错误定位极其困难,业务开发人员被解脱为只需要懂业务流,不需懂技术。

我大概在这样的平台上工作了2个月左右,就离开了,只是觉得呆的越久恐怕退化的越厉害了。


如今开始思考,何为统一开发平台?在一个以千人为规模的大团队中进行软件程序开发,我认为没法进行真正完整的统一。

让所有人统一OS、开发工具、代码规范、文档描述,技术选型范围,何其难也。

而且规模越大的公司进行完整的统一越没必要,因为影响了个性,阻碍个性化往往很多时候也阻碍了创新。


从生物进化论的观点来看,人类最终主宰了这个星球,必然是经历了无数年月的优胜劣汰的自然选择,人类传承的根源在于小小的受精卵也就是基因。

在一个组织中最先统一的应该是其基因及其生长环境,让小小的受精卵最终孕育发展成长为人,如果长成后是一只猪,那么从一开始基因就错了。

基因的形成过程,本身就是一种自然选择过程,一旦形成优良基因,其生长环境的统一性、稳定性、长期性极其重要。

站在技术人员的角度来说,这种环境就是一种技术文化、氛围、管理体制的统一性、稳定性和长期性。


人与人之间既然千差万别,类同于每个程序员或者小团队的技术实现方案都会千差万别。

人虽外表不同,但不同的是血肉,不同人的骨架置于一处又发现没多大区别,人的骨架本质上是一统的,不多不少都是206块骨头。

这是生物进化无数年的最终结果,那么在软件开发团队中真正需要统一的是骨架,而非血肉,难题是如何去定义哪些属于骨架,哪些属于血肉?


1996年左右出现的SOA,是行业智慧先驱探寻软件规模化设计、集成解决之道,它不是一种技术而是一种思想。

如今服务的思想也算深入人心,但服务中最本质的部分,不在于服务接口抽象、实现技术,而在于服务契约。

契约精神构成了人类商业社会的基石,那么服务契约也充当SOA体系架构中的基石,由所有的开发人员共同遵守、维护和支持。

大型软件系统结构体系中,每一个小小的服务充当了构成完整骨架的骨头,骨头的形状不同、硬度不同、粒度不同、作用也不同。

每一个服务背后的实现技术更是千差万别,但服务契约却始终一致,契约不会永远不变,却不会频繁改变,在所有服务的关联方都达成一致的情况下,慢慢演进。

最终,服务的一块块骨头组合一起,构筑成完成的系统骨架体系,服务之上千变万化的业务需求正如人之血肉,骨架稳定而血肉多变,骨之不存,肉将焉附。


最后,谈谈实现服务的具体技术,正如构成骨头的材料,骨头功用不同,材料自然有不同,但更多的部分却相同。

服务实现技术,依赖具体的服务契约说明,不同的约束,自然选择不同的实现技术,功能、性能、易用性、易运维性、扩展性,一个考虑都不能少。

在一个大型团队下划分的许许多多小型团队之中,一个共享的知识库必不可少,由不同的团队成员共同维护、交流、发现交集。

大体上我们可以把服务划分不同层次和粒度,统一不同服务层次和粒度间的契约,而非实现技术。

从层次上说,可以划分为:

1、硬件服务

不同的程序对硬件的需求不同,有CPU密集型、磁盘IO密集型、网络IO密集型等等,所以需要底层灵活的硬件选型平台等

2、OS服务

计算资源、存储资源的分布式迁移、伸缩等

3、数据服务

关系型、结构化数据访问

4、中间件服务

异构系统的同步、异步通信(RPC、消息中间件)等

5、业务服务

面向终端的业务接口提供者


服务层层传递、依赖,有效的划分服务职能和切分粒度,小团队负责制,术业专攻,契约明了,也许才是规模化软件开发,优化资源配置的一条有效之路。

而统一开发平台,正如天空之城只存在于宫崎骏的动画中。


分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics