大型系统软件Comware研发总结

前言

前几个月写一篇关于研发管理的文章。在那篇文章提出一个简单的思考框架,并没有实际案例的分享及深度分析。所以在这里以华三Comware研发为例,结合思考框架谈谈自己的一些理解与想法。

研发管理的一个中心四个基本点

Comware

开始之前,先介绍一下Comware。其主要要点如下:

  1. 整个系统代码量超过了1000万行(开源代码除外)
  2. 巅峰时期开发人员1000左右
  3. 支持设备类型超过100多种,同时支持各种丰富的网络特性
  4. 性能与可用性要求高,需要满足欧美高端市场(金融,国防等)要求及互联网大流量的冲击
  5. 作为公司的中台,支撑公司绝大部分产业线(安全,路由,交换,云计算等)

下面我们就一一展开说明。

业务

以业务中心。Comware作为一个网络操作系统,主要要求如下:

  1. 充当网络设备的大脑
  2. 承载各种网络业务,并动态满足不同网络业务的要求及变化
  3. 保证整个系统 高可用性,高性能,可维护性,可扩展性,安全性

文化

由于历史上的原因,整个研发文化总体上源于华为,稍有调整。具体要点如下:

  1. 质量为上
  2. 结果导向
  3. 研发三权分立
  4. 追求效率
  5. 鼓励创新
  6. 公开

关于科技公司的文化,推荐Netflix文化:自由与责任

团队

团队是从人的视角出发。要以人为本啊。

团队梯队合理清楚,按技术水平划分具体如下:

  1. 开发上岗人员
  2. 维护上岗人员
  3. 开发负责人
  4. 系统扩展组
  5. 系统组
  6. 架构组

团队组织划分以业务导向,按照不同的业务划分不同大组,独立进行代码管理。在各个大组一般分为开发与维护两个方面进行人员动态调配。

团队建设主要是大组每周定期培训,鼓励分享,除此之外针对不同岗位有专项培训,如项目管理,代码管理。

架构

架构不是我们常说的架构,这里的架导指导代码的工作(架构从事的角度出发)。

选择开源,拥抱开源,不要重复造轮子

不得不说2008年开始预研下一代网络操作系统,当时的团队放弃vxwork,选择了开源linux,而且作到取自开源,高于开源,只使用linux基本组件(文件管理系统,内存管理系统,进程调度等),重新移植与修改协议栈,实现分布式网络协议,扩张SOCKET类型。采用Linux好处多多,具体如下:

  1. 充分吸引Linux开源精华
  2. Linux开源发展路径,决定Linux便于改造与优化
  3. 与Linux一起升级,如内核2.6升级到4.x版本
  4. 方便开源引入支持,如移植wireshark, python
  5. Linux在服务器大量应用,业界有大量人才

合法合规

合法就不用多说了。注意的是要考虑到不同的国家与地区的差异。 合规方法最近的例子就是2017年百度要求内部全面停止使用React/React Native。利用开源的Linux作为基础开发商业操作系统,就不得不遵守开源协议。

KISS原则

关于KISS原则,架构设计通用原则,有太多说明,这里不展开。

开放性

对外开放接口,如OAA(Open Application Architecture,开放应用架构),这样有以下好处:

  1. 对公司内部来说,降低了耦合
  2. 对外部合作方来说,方便不同厂商系统集成
  3. 对客户来说,提供了更多的选择以及DIY能力
  4. 开放与释放了平台的能力

分层与分解

整个系统采用分层设计有如下优点:

  1. 可以分离系统不同方面的设计关注点,使得同一时刻设计者可以集中精力考虑较少的相于因素,封装和分解了相关的复杂性,增加了系统设计上的清晰度;
  2. 减少了系统的耦合和依赖,提高了内聚性,增加了潜在的代码重用性,提高了低层的代码重用度
  3. 层与层之间需要清晰的接口,有利于实现面向接口编程,而不是面向实现编程
  4. 一些层的实现可以被替换或扩展,对整体的架构影响很小
  5. 层次清晰,有利于多个小组并行开发

分解主要体现是模块化,有如下优点:

  1. 为整体架构提供最小单元
  2. 带来了模块化管理,模块化提供交付件(cli插件,daemon等),方便模块化升级,模块定制,模块化诊断
  3. 模块化隔离,如实现进程间隔离
  4. 统一模块间依赖管理
  5. 便于将一些基础组件及功能模块化
  6. 方便问题定位,如内核定位踩内存问题
  7. 便于模块信息聚合

测试独立性

个人一直以为一个好的测试人员具有以下素质:

  1. 业务方面做到熟悉,并能不断深入
  2. 细心保证执行方面到位
  3. 独立性,测试并不是帮助开发,而验证开发成果与补充开发的不足
  4. 发散测试,保证测试的完整性,避免漏测,守好产品最后一道门

需要在一个公司层面将测试的独立性体现出来,所以新增一个鉴定测试部门。

软件工程

作为大型系统软件,离不开软件工程的指导,在整个过程必须科学践行软件工程。

工具与效率

基础设施投入,如引入高性能服务器提高编译速度(1000万行c语言速度慢真的要半天),这里说一下越高频越重要。每一次修改代码都需要编译。 开发代码review工具,方便协作。

资源统一管理

主要体现以下几个方面:

  1. 系统资源(如LIPC端口)统一分配与管理
  2. 模块进程统一管理
  3. 大块内存申请统一管理
  4. 统一错误码

控制集中式,处理分布式

在分布式架构上,采用控制集中式,处理分布式,并不追求用复杂的分布式协议来实现,够用就好。整个模型简单,大大降低了开发难度,提高系统可靠性。

方案评审

公开评审,鼓励技术方案PK。

预研

预研由market部门负责,由市场来定义未来需求与方向。

度量不可少

建立度量体系。大的方面分为以下几个方面:

  1. 市场度量
  2. 团队度量
  3. 个人度量
  4. 项目度量
  5. 代码度量

减少对人的依赖

  1. 加强流程建设
  2. 不断用机器及工具代替人
  3. 团队人员互备

代码

代码是研发最终交付的核心,是架构的实体,是业务的载体,是测试的对象,是公司的核心资产

版本化

这个是老生常谈的问题,但是很基础,很重要。

设计先行

代码之前,设计先行。正如以前说过一句话:从长远看,选择比努力重要,数据比算法重要,架构比实现重要

代码规范是行动准则

这是很好的一份代码规规范。还是一个保证得到执行的规范。很多公司都 倡导编程规范。但是实际并不能落地,这里有各种各样的原因。

这里分享一下有利于编程规范得到真正落地的建议:

  1. 规范意识培训
  2. 提供规范检查的工具(这个最重要)
  3. 将规范执行纳入考核(需要建立一套对应体系)
  4. 代码review,review内容包括是否符合代码规范

必不可少的单元测试

交付系统在逻辑上由一个个函数构成,以函数为单元开展测试。

不止代码review,还有代码鉴定

对代码进行鉴定,估计国内就此一家吧。在保证代码鉴定团队的权威下,不仅要求是bug free,而且要求代码信雅达。

关于代码review的关注点,以前写过一篇文章:C语言代码 review的总结

注重初始代码质量

这是开发顺序决定的,由少数核心开发人员完成,完成基础模型的开发。这样的好处,开始代码质量高,不要让系统输在起点上,同时优秀的代码作为后面的大量项目开发的参考与标杆。

接口优先,接口先行

接口(API)比实现更重要。在编码之前,接口完成设计并通过评审。

说明

在不同的公司,不同行业,不同阶段研发管理都要针对性调整,不求多高大上,但求实用,只有管理规定能够落实,才能真正提高效率,增强团队的战斗力,解决具体业务的问题,满足业务的需求。

参考

  1. 如何看待百度要求内部全面停止使用 React / React Native

欢迎关注

欢迎关注微信公众帐号:沉风网事(savewind)

沉风网事

Share Comments
comments powered by Disqus