拜访一些美国软件公司后对软件的重认识

无线产品的竞争力，特别是对外的、客户可见的竞争力价值，主要取决于硬件和算法。产品的型态、规格、性能等，很大程度上依赖硬件。空口频谱利用率、用户体验等，很大程度上依赖算法。软件本身带来的竞争力，可讲的断裂点不是很多。当然，也不意味着软件就不重要。好软件的架构、工程和集成验证环境，在增加新特性时，所需的工作量较少，缺陷率较低，这些更多是体现在内部效率上。但现在，满耳充斥的都是软件很重要，软件会改变世界，统治世界。这和我们传统的软件价值认识并不一致，为什么有这么大的差异呢？

认识上的不一致，并不一定是哪个认识有错误，而是观察点不一样。讲软件改变世界更多是指软件为主体的系统正在吞噬旧的商业模式，开创新的商业蓝海。不管怎么样，趁这次在美国，拜访几家软件公司，想重新认识一下什么是软件，就首先聚焦在选择什么样的观察点。结合拜访中的交流和自己的思考，总结出来几点分享给大家。有些观点也不一定对，权当讨论的素材。

l  嵌入式软件有其运行特点，不要无原则地和互联网软件去对比

我司设备，是把硬件和软件开发出产品后，交给客户去部署、去维护、去运营，理论上，产品交付使用后，开发者就不再参与（除非是现场定位问题）。这种方式，对产品的质量、可用性、可服务性等要求很高。加上通信设备需要5个9以上的可靠性，不但对产品质量的要求极高，对产品出问题后响应速度也要求极高。要求高就意味着高的开发成本，也许99%的成本是用来解决那1%的问题。在开发阵型上，基本都是大投入、过验证。不怕一万，就怕万一。而互联网软件，软件主体完成开发后，是互联网公司自己部署、自己维护、自己运营，交付给用户的是服务。这种方式，在质量、可用性、可服务性上的要求是可控的，开发者自己可以管理软件的实际运行。有问题，可以很快去修正。DevOps、一周一个版本等都是在这种背景下诞生。互联网软件开发团队，基本不需要专职测试人员，开发人员自己做测试，也不存在过验证。所需的开发人员相对较少，开发效率也很高。由于无线软件运行的模式不一样，不能轻易以互联网开发模式去纠正，甚至否定嵌入式软件开发模式，否则就如邯郸学步，会带来灾难性的后果。学习归学习，切不可妄自菲薄。

l  软件革命带来的效率提升，不是百分之多少的提升，而是1倍甚至数倍的提升

什么是软件革命，是否存在软件革命？大家可能有争议。我认为，现在确实存在软件革命，这场革命的本质是把产品从大化小、减少依赖和等待。华为的主流产品，每个都像一座巍峨的高山。从硬件平台开始，叠加数十个软件平台/组件，然后再在上面开发产品软件。环环相扣，层层依赖。一个大型新产品开发，涉及的人往往逾千（包括公司级平台/组件、领域级的平台/组件、甚至产品内的平台/组件的人，以及后端测试和维护的人员）。这种开发模式，需要集中的、大量的人力投入。以这种模式开发产品，没有一个公司能够超越我们，包括那些很牛X的互联网公司，也只能望洋兴叹。但，换一种模式开发产品呢？

当前移动网络架构，基本都是3GPP协议标准预先定义好的。盒式设备（网元）分层放置，通过标准的接口协议互连，构成整个移动网络。网络架构的变化和演进很慢。随着技术、场景、应用、需求等的发展速度不断加快，这种标准协议框架的方式将不能适应需要。因为面对变化和未知，提前构建一个面面俱到、适应变化的网络架构是非常困难的。最终也是不灵活、不稳定的。在NFV/SDN等技术的驱动下，运营商软件生态系统正在发生变化。一个通用的基础架构，可以按需支持不同类型的网络架构将是趋势。网络功能可以通过软件进行动态灵活地部署、实例化、弹性伸缩。标准组织将有可能不再定义网络架构，而只是聚焦于把小的、可复用的服务/组件去标准化，支撑不同的应用场景。

在这个趋势下，网络架构将从“盒式设备+规范协议”过渡到“信息模型+软件框架”。传统意义上的网元可能将不复存在，取而代之的将是一系列小的标准化服务组件（包括专用的接入硬件，如射频和天线）。网络架构本质就是一个分层软件框架，提供API，支持即插即用的事件标准。一旦产品被从大化小，减少了模块之间、层层之间的相互依赖，开发者的效率将会被极大地释放和提升。另外，微服务化的开发模式也能从根本上提升开发效率。比如大家熟知的SAAL协议，虽做成公共组件，但从基站、控制器到核心网，数十个产品都要对其进行集成、适配和系统验证，总的开发成本仍然很高。如果SAAL一旦被做成微服务，这个问题就不复存在。各产品都不关心SAAL模块，只调用其服务就可以了。还有个例子，HSPA时代，部分功控从控制器下移到基站，LTE时代，移动性管理从控制器上移到MME。其实算法和流程都基本一样，由于缺乏微服务化的架构，铁板一块，无法平滑迁移，基站和MME都重新另搞一套。

无线当前有个蓝军项目，就在利用这种模式，以10倍的效率在开发新产品。虽然说软件开发没有银弹，但换一种模式，就有可能产生银弹。

当然，这也是一把双刃剑。华为单个网元设备传统的高性能、高集成度、高可靠性的优势将不再是必须的。容量、可靠性等可以很容易地通过多实例部署来解决。这对我们来说，是丧失了一道重要的防护门槛，必须提前做好应对。最坏的情况下，运营商或者第三方将通过开源，自行开发，自行部署，自行维护，自行运营，类似互联网软件模式，将会对我们目前的产品模式造成致命打击。

效率提升数倍，不一定就是要减少数倍的人。而是要做更多的事情，做更多的创新试错。在硅谷，仍然是不眠夜，好的软件人员仍然是一将难求。硅谷的软件公司，不仅是小的创业公司，还有Facebook、Google等大公司，都极力把工作环境营造得像家一样温馨，甚至像白宫办公室一样气派。拿某CEO的话来说，这样做是让员工的工作环境舒适、留住员工，同时也是希望员工把公司当家，愿意留在公司加班。

l  软件会走下神坛，成为生活的一部分，而不只是软件人员的开发工具

最近奥巴马在一场白宫协办的编程大会上，熟练地利用一小段代码画出了一个正方形，以此告诉大家：编程并非难事，谁都可以。奥巴马会后说道:“别总是充当消费者，试着去创造点什么……花上一个小时的时间，你就可以了解更多关乎我们生命一部分的科技。”

在硅谷，很多创新公司就在做这件事情：为编程者提供极易的软件创造平台。对大部分软件人员来说，编程并不是最重要的，创造才是。也正是在硅谷，新的编程平台和编程语言层出不穷。通过这些强大的编程平台和语言，家庭主妇可以编上一段代码来烧一个风味独特的菜，卡车司机可编上一段代码让车在特定的路线上行驶。这些强大的编程平台和语言的意义还在于，可以很容易为产品营造出一个开发者生态，让不同的开发者基于产品开发出独特的应用，满足不同的要求。

专职的软件人员也不用太担心自己的饭碗，强大的编程平台和编程语言，本身就需要优秀的专职软件开发人员（普通的专职软件开发人员可能没这么幸运了）。另外，作为软件开发者，不要只死守一种编程平台和一种编程语言，否则真就危险了。

l  软件提倡拿来主义。互联网软件的快，秘诀就是拿来主义

互联网软件最会使用开源，虽然他们对开源的贡献并不大。互联网软件公司的快，就是基于开源。即使像Google、Facebook这样有名的大公司，刚开始软件也谈不上有多优秀，软件能work起来就是最好。等公司活下来，发展壮大了，才去正名，才去优化软件架构。他们使用开源软件的方式也很原始。从开源社区获取代码，自己优化、定制，很多情况下也不再回馈社区，也不和社区代码同步，或者3~4年才同步一次。

对于软件开发人员来说，使用开源软件并不丢脸，像乌龟一样的速度去开发代码才是丢脸。

l  开源是软件创业公司的生存方式，对于他们来说，开源是活下去的基本条件

也许是因为小公司没有战略，对于他们来说，开源不是战略，而是能活下去的基本条件。不同公司应用开源的方式也有差异。一种公司是拿开源软件来构建自己的产品，另一种公司是增强开源软件的管理功能，推开源软件的企业版。

开源，是软件生态不可或缺的一环。以前可能被IBM洗脑太多，总从战略高度，把开源想象成高大上。先定战略，再做开源（实际上IBM自己在很多节骨眼上也是被逼的）。实际上对我们这些涉足开源不久的后来者，不妨放低姿态，能用就用，需要开时再开，不用整天为开源战略折磨。

从很多方面来讲，无线软件都是走在公司最前面。不管是敏捷，还是6个1。不管是代码增量控制，还是架构守护。即使是领先者，也容易迷失方向。和美国最领先的软件潮流对齐，也能帮我们找到改进。拜访交流期间对无线软件的几个思考：

u  拿来主义不是一件丢脸的事情

对于软件开发者来说，拿来主义永远不是一个丢脸的事情。不管是架构、工程、工具、方法，还是开源软件。能拿则拿，能用则用。软件开发的生态是非常丰富的。拿一句夸张的话来讲，我们现在做的任何东西，在外面都有，而且都可以免费拿到。当然，由于电信行业门槛高，由于完整性、可靠性等原因，很多东西拿过来不一定就能用。但我们要以更加开放的心态都做软件开发，切忌闭门造车，重复造轮子。

u  软件架构从垂直架构向水平架构演进，开发组织从功能型组织向服务型组织演进

产品从大化小，减少层级依赖。产品由一系列松耦合的微服务组成，公共组件也演变成微服务，减少集成、适配和验证的成本。基于这种模式开发产品，能释放开发者数倍的能力，提升开发者数倍的效率。

软件架构也要适应这个变化。以前开发新产品，架构师会在开始构建一个好的软件架构。基于这个架构，更多的软件开发人员在上面堆代码。就如盖楼，先打好地基，搭好框架，再在上面砌砖。这种Scale-Up垂直架构的缺点是容易腐烂。初始再好的架构，随着新功能的不断加入，新开发人员的不断进来，架构容易腐烂，导致开发成本越来越高。并且由于是单体架构，架构优化的成本也比较高。另外，由于后进来的开发人员做的最多的事就是在已有的架构上堆代码，对架构本身缺乏深入的理解，人员成长的速度会相当慢。

水平架构的特点是有一个面向服务的总线，各个功能都以服务的形式，水平地挂接到这个总线上。总线提供服务发现和相互对接功能。各个服务的粒度较小，相对独立。存量的代码也可以通过服务化改造挂接到总线上，实现重用。在水平架构下，弱化了对初始架构的依赖，各个服务都可以有自己不同的架构。服务间的影响也比较小，架构重构的成本比较低。这种Scale-Out的水平架构可以很好适应产品服务化的需要，也是当前互联网软件普遍采用的架构模式。

当前的开发组织是面向功能设置的。一个开发组织面向一个产品，或一个平台，是单体、树状结构。随着产品服务化的趋势，开发组织要进一步扁平化，面向服务来设置。班长的战争，一个班长可以对应一个或几个服务，这个服务是面向多个产品的，动态的，可独立部署。面向服务的组织，在层级上也可以简化，更加贴近于软件在网上真实运行的本质。

u  从软件个性化开发模式到软件工厂化开发模式

软件开发充满个性化特点，不同的软件人员，开发同样的功能，开发的软件可能是千差万别。回顾软件开发人员的苦难史：从汇编语言到C语言，开发效率至少提升10倍，为什么？因为C语言相对汇编语言，不但可读性增强了，更重要的是C语言提供了很多库函数，让编程者自由使用，简化了很多实现。但库函数仍然是代码的一部分，在使用上仍然是可以千差万别。如果把这些公共功能改造为微服务，提供标准化接口，编程就可以更加简单，从个性化模式到工厂化模式。

说到这里，大家可能有疑问。究竟什么是服务，它和C语言的库函数、当前的CBB组件到底有什么区别？不管是C语言的库函数，还是CBB组件，虽然都提供了一些公共功能，但它们是静态的，被动的，需要被分配资源、被管理。而服务是自组织、自运行、自管理的，并且和语言无关。使用者不需要对他们做什么，需要时调用其提供的服务即可，召之即来。举一个例子。汽车由各个不同的标准化零件组成，比如钢铁、橡胶、玻璃、螺丝等等，像C语言的库函数，各个厂家需要花费巨大精力在这种差异性的组装上。但如果进一步进行服务化改造，提供发动机服务、变速箱服务、底盘服务。厂家拿过来就用，造车就更加简单、快捷、可靠了。

软件工厂化开发模式，就是把公共组件和功能改造为服务，拿这些服务去组装产品，提升开发效率。平台部门类似一个服务工厂，提供一个个服务。产品在使用平台时，不是像现在这样，拿一个或多个完整的大平台，在上面开发代码，再去集成、联调、发布。而是从各个平台部门拿所需的服务，拼成一个产品。产品部门甚至不需要开发一行代码，就能推出一个产品。

另一方面，平台部门提供的服务，其来源有更多的选择。这些服务，可以选自开源界，可以外包给其他公司，甚至可以一个服务多家开发，择优选用。这种模式，就非常类似苹果的硬件工厂模式了。

尽管当前在软件价值认识上还有不一致，软件改变世界并不是一句空话。我们要做好准备，去迎接这个浪潮。