基于平台的软件开发

发布日期:
2019-08-09

浏览次数:

我的一家咨询客户为邮电做软件项目,对于不同的项目,虽然项目不同,但是都是邮电行业的,或多或少都有相同的部分,但是每个项目几乎都是白手起家,从零开始。B项目的一位成员曾经做过A项目,发现A项目的部分函数可以B项目中,他就把这些函数copy过来。这么做显然节约了他一点编码时间,然而大家有没有想过,如果他们能够搭建软件平台框架,把很多项目都可能会用上的功能模块识别出来,封装成公共的基础模块,为各个项目所使用,会很大程度较少项目工作量、缩短项目周期、提升项目质量。

会提升质量吗?或者有人有这样的疑问。软件平台为许多产品所用,就大大增加平台中缺陷发现的机会,有助于平台的迅速稳定。人的美丽不仅是外在美,内在美一样很重要;软件也一样,软件的质量不仅是外在的、用户可以感知的质量,也包括内在的、用户感知不到的质量,比如可维护性、可移植性的优劣。软件平台之所以能够成为平台,通常会有精心设计的架构,提升软件的“内在美”,而没有基于平台开发的软件,通常迫于项目的进度压力,开发人员关注的是如何把客户需求实现了,哪里顾得上软件的内部质量属性。因此,基于软件平台开发的软件,有助于让软件同时具备“外在美”和“心灵美”。

会减少工作量、缩短工期吗?好像没有人有疑问。但是,估计你会低估平台所能带来的工作量和工期的缩减程度。基于重用平台的软件开发,毫无疑问节约了开发时间,但是往往很多人忽略了测试的时间也得到了节约,维护的工作量也得到大大缩减。以维护工作为例,当修复了一个平台bug,如果该平台为十个产品所用,那么实际上是用解决一个bug工作量解决了十个产品的bug。

软件平台往往会成为企业的核心竞争力之一。比如,有些软件项目竞标,你觉得少于100万你就会亏钱,而有的公司敢报50万,他们还赚钱,为什么?因为人家只需要有20%开发工作量,另外80%是已有的软件平台。H3C在国内异军突起,短短几年时间已经成为企业网市场的领先者。一切都没有偶然,H3C在市场的卓越表现是因为内部有强大的研发能力,而这种强大的研发能力的一个重要体现是他们的平台软件。H3C大部分软件工程师都从事平台软件的开发和维护工作,而各个产品的软件工程师相对并不多,因为各产品的软件开发工程师要开发的仅仅是一小部分与硬件相关的驱动而已,大部分功能都由平台软件提供。即使驱动软件与硬件相关,他们也尽量提出一些公用模块,比如设备的启动界面模块,可见,想方设法地重用已经成为H3C的一种研发习惯。试想,如果H3C没有平台软件,那么他们的软件开发和测试人员要翻十倍或许都不够用。

有的人会说,我们的企业不一样,产品各异,根本不需要也可能构建软件平台。或许这是事实,我曾经的咨询客户,软件开发人员一共不超过二十人,而编程语言就有五六种,在规范他们软件开发过程之前,我向总经理提出了症状背后的一个本质问题:业务方向不明确、产品不聚焦。享誉全球的苹果公司也只有几款可以数得过来的产品,而我们国内很多名不见经传的小企业研发出的产品琳琅满目,可是有多少赚钱的?所以,有人说了,在这个时代,管理者要学的是如何做减法,不是做加法,要成功,就要专注!如果你的业务专注了,必然就有了构建平台的可能和需要,而一旦你构建起了强大的平台,虽不能保证你会成为这个领域的Number one,但会使你成为这个领域的Professional。

现在,或许你已经有了强烈的构建属于自己的平台的冲动,但如何下手呢?下面告诉你软件平台DIY六步骤法。

步骤一:选择基准产品

首先,选择一个具有对本业务领域最具代表性的产品,以此产品的软件作为软件平台的雏形。构建软件平台不必从零开始,平台从产品中,又到产品中去。

步骤二:组建平台团队

再则,要组建各个软件平台架构师团队。科技以人为本,构建平台软件的极其关键的人是软件架构师,架构师就好比建筑行业的设计师,架构的质量决定了整个平台的质量,而架构师的能力水平又决定了架构的质量。架构师要精通软件设计,同时也要对所选择的代表性产品软件技术非常熟悉。此时,你也许要挠头了,我们工程师都很年轻,没有这样的人才怎么办?或者挖一个本行业的架构师来,或者借助外力,引入培训、咨询帮助经验相对丰富的工程师一同去设计软件架构。对许多公司来讲,第二种方法的可操作性会更强一些,我曾辅导过一些企业工程师去设计平台框架,我提供方法,他们提供产品技术知识,一同讨论互动的过程中,迅速构建起了平台架构,更重要的是,在这个过程中,工程师的设计能力得到了提升,平台设计好了,同时也培养出来了一批软件架构师。

除了构建平台之初需要架构团队之外,在平台实现和后期的维护升级还需要平台软件开发维护人员。强烈建议从组织上要把平台的开发、维护工作独立出来,目的是:1、确保平台工作有较充分的资源。因为产品开发属于紧急而重要的工作,而平台开发相对来说不太紧急,如果没有独立的专职的平台团队,开发人员往往都被安排到了紧急的工作上,即产品开发,然而重要度要大的平台开发没人来做了;2、确保平台的架构不被要求各异的产品所破坏。我曾经的咨询客户很重视软件平台建设,辛辛苦苦构建好了之后,因为没有独立的平台团队专门负责平台的开发和维护,导致最后的平台被各个产品改得面目全非,已不能称之为平台了。

步骤三:平台架构设计

首先对所选的产品软件进行总体架构设计,总体架构首先要对软件进行层次划分。如果你学过计算机网络知道OSI/RM,就会知道分层的好处,就是使用下层提供的服务而为上层提供统一的服务,屏蔽本层及以下层的差异,当本层及以下层发生了变化不会影响到上层。

做软件设计要学习硬件设计,硬件的设计越来越简单,二十年前,哪怕是一个功能很简单的电路,电路板上也要铺上密密麻麻的元器件,而如今,一块电路板上焊几块集成芯片(IC),就可以实现很复杂的功能,对硬件设计人员的电路设计能力恐怕还没有三十年前高,因为主要功能都集成到了芯片里面,设计人员不必了解芯片内部如何实现,只要读懂芯片手册、了解了各个管脚的定义,可以利用IC实现所要的功能了。软件架构进行了分层,每一层就相当一块大的IC,层与层之间的互动都不必了解层内部是如何实现的,只需要搞清楚每一层的对外接口函数(相当于IC的管脚)即可,当软件开发人员只需要关心本层的技术细节时,软件实现的难度将大大降低,对开发人员的技能要求也随之降低。

以目前应用较广的Android软件系统为例。Android共分四层,最底层为LINUX KENEL层,作为硬件和软件之间的抽象层,它隐藏具体硬件细节而为上层提供统一的服务。其上一层为LIBRARIES和RUNTIME,顾名思义,这一层是一个C/C++库集合,相当于中间件,各个应用通过APPLICATION FRAMEWORK层访问。APPLICATION FRAMEWORK层存在的目的就是为了简化组件的重用,任何应用程序都能发布他的功能且任何其他应用程序可以使用这些功能。APPLICATION层是指运行在Android系统上的五花八门的应用程序了,如日历、地图、邮箱等。

 

基于平台的软件开发

 

有了总体架构设计之后,接下来便是对每一层进行展开设计,如Android架构所示,每一层在细分出多个组件,每个组件又可以看出一个小IC,同样,此时不必关注小IC内部如何实现的,只要把这个IC的功能和相应的管脚(也就是软件接口)定义出来。最好,每个小IC可以做出编译可裁剪的,即用条件编译保证只编译自己需要的功能模块。

步骤四:平台实现和验证

在平台架构设计完成后,接下来是实现了。此时,也不必所有的代码都要一行行地重新编写,可以把已实现了产品软件拿来借鉴、甚至可以重用,但一定确保不与设计相违背,代码的风格也要遵循统一的规范。实现之后,要对每个模块、以及各个模块的集成进行测试,确保正确实现了。

步骤五:平台发布

最后,平台软件要发布给用户,也就是产品开发人员。此时,要注意以下两点,第一,发布的平台软件最好为二进制的,而不是源代码,目的是从技术上防止平台被产品开发人员改动。第二,要为平台的客户,写平台软件的使用手册。使用手册应对每个模块的功能、如何裁剪、在什么情况下裁剪、它的对外接口进行详尽描述,便于使用者能够方便地、正确地使用软件平台。

 步骤六:平台的维护和升级

最后一步,恐怕也是最不易做好的一步。打天下容易,坐天下难;建软件平台容易,维护平台难。为什么?一个企业不断面临原有产品维护、升级和全新产品开发的情况,而且各个产品的研发工期通常比较紧张,产品维护时对bug解决时间通常也有急迫的要求,如何保证这些面临着时间压力的研发和维护工作中,各个产品依然考虑平台软件的完整性,哪怕忽略短期的便利性也不牺牲平台软件的完整性,确实是一个很大的调整。许多企业在建好了平台之后,各个使用平台软件的产品,在维护和升级过程中,自行地改动、增删平台代码,导致最后各个产品的平台软件部分已各不相同,此时平台完全地跟着产品走了,已不能称之为平台了。

要解决以上的问题,有两个关键前提,其实在前面已经提过。第一,从组织结构上要保证有独立的团队专门负责平台软件的维护和升级;第二,平台软件提供给产品的软件包一定是二进制的,而不是源代码。的确,如果提供源代码可能会给产品的开发和维护人员提供方便,然而这样小小的好处的代价导致整个平台遭到破坏这样巨大的损失。有人说,可通过制度来保证产品人员不改动平台,是的,是可以通过制度来保证,但是监督、检查所带来的成本一定非常巨大,好比我们也可以通过制度规定而不是银行卡加上密码的方式来保证每个人都取自己的钱,然而没有那个银行敢这样做的。

有了以上两个关键前提,还要建立平台的升级开发和维护机制。当产品不断有新的需求,而当前的平台软件又不满足这些的需求,此时,产品不可以为了所谓的快速市场反应独自开发这些需求,而不考虑要求平台升级从而满足这些需求。因此,当产品面对市场需求时,要评估这些需求需要平台增加或改动哪些功能,然后向平台软件团队提出开发任务,平台开发完成后再向产品发布,这样就保证了平台软件也是随着客户需求而发展演进的。

平台的维护工作涉及了一个很重要的bug同步问题,即任何一款使用平台软件的产品发现了属于平台软件的bug时,不可以只在该产品上修复, bug的修复一定要同步到平台软件上(如果平台软件提供给产品的是二进制文件,该bug同步很容易实现),既该bug最终是在平台软件上得到了修复,并把修复后的平台软件在何时的时机升级其它产品,如此,一个产品bug的解决,所有的产品也都不存在该bug了。

同时,平台软件不会只有一个版本存在,因为在使用的平台软件版本需要维护,另外要若干增加新特性、特性定制等开发版本的存在,平台软件的版本管理将是非常重要的一项工作。版本管理不仅涉及软件的配置管理,包括版本的规划,即规划出要开多少个版本分支,为何要开出这些分支,何时这些分支在回到主线,何时将发布XX版本,等等,也包括版本的监控、版本发布管理,以及不同版本间的bug同步,即不可以在旧版本中已解决掉的bug又重新出现在新版本里。因而,平台软件的开发维护工作想要做好,需要较全面的高水平的研发管理,平台软件建设得如何特别能反映一个企业的研发管理水平和研发实力。

相关推荐