前言

前几个月写一篇关于研发管理的文章。在那篇文章提出一个简单的思考框架，并没有实际案例的分享及深度分析。所以在这里以华三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. 统一错误码

控制集中式，处理分布式

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

复杂性

认识到软件开发的复杂性的重要性。在软件开发过程，要先假设软件的各种复杂情况，具体如下：

  1. 假设一定会有错误，错误一定会发生
  2. 假设过程会出错
  3. 假设需求会变更，需求会增加
  4. 假设团队成员有变动
  5. 假设未来会更新线上代码
  6. 假设未来需要解决线上问题

这些假设会增加软件开发的复杂性，但是可以通过对假设的证明与排除来降低复杂性

方案评审

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

预研

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

度量不可少

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

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

减少对人的依赖

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

文档

  1. 重视文档，无论对外还是内部文档，文档就是沟通，文档就是协作（需求文档化，架构文档化，设计文档化，项目流程文档化，交付文档化）

代码

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

版本化

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

设计先行

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

代码规范是行动准则

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

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

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

必不可少的单元测试

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

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

对代码进行鉴定，估计国内就此一家吧。在保证代码鉴定团队的权威下，不仅要求是bug free，而且要求代码信雅达。只有高标准的要求，才会有高质量的代码。

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

注重初始代码质量

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

接口优先，接口先行

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

避免以忙治乱

工作总有人喜欢用了自己的勤劳来掩盖自己的愚蠢。

说明

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

参考

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

欢迎关注

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

沉风网事