C/C++开发者金律

引言

项目在推进过程中,会逐渐变得越来越难以控制,筋疲力尽之后,直到失控.

比如 我公司的业务背景:
限制1: 开发出的程序运行在 客户的环境, 处于安全考虑, 客户环境禁止带入手机,禁止拍照,禁止数据导出.
只能用笔将遇到的问题记录在本子上, 出来后反馈到公司研发.

限制2: 客户环境 每天数据导入 有次数限制, 时间限制, 节假日限制, 上下班限制. 传输介质限制.
不是每次都能将最新的程序 传输到现场机.

限制3: 公司每研发人员长期支持着至少3个地区的项目开发,如果驻场开发, 其他项目进度受影响.

限制4: 远程沟通 信息传达 会有损性的丢失.如:
对方很久才回复,
对方对工具不熟悉,
对方的设备受限(机房没有鼠标)
对方手头正忙,
对方是个新手,
对方下班了,
对方在路上,
对方环境存在其他干扰(FTP网络问题,TCP巨帧丢失问题)

项目的演化

2018 年5月:
开发出 网络分析程序 如: analyze, 部署在 某客户机房

2018 年10月:
公司觉得 某个功能具备特色,将其单独作为一个卖点,
在 analyze 基础上开发出 analyze_A, 部署在 某客户A机房
期间 analyze 与 analyze_A 都在 快速开发中, 已经出现更新异常,一个BUG两边代码都要改, 但还能忍受.

2019 年3月:
公司又觉得 某个功能具备特色,将其单独作为一个卖点,
在 analyze 基础上开发出 analyze_B, 部署在 某客户B机房
期间 analyze 与 analyze_A, analyze_B 都在 快速开发中, 已经出现更新异常,一个BUG三边代码都要改, 但还能忍受.

… 期间多次要求给时间重构代码框架, 项目紧急任务过多, 一直未能重构.

至今
已经演化出 analyze, analyze_B, analyze_C, analyze_D, analyze_E, analyze_F, analyze_G,
还有要求将F地区的功能加到C地区的项目上.
还有一部分驻场开发, 但是代码拿不出来的 analyze_X.
但是 F, C 的代码 在长达5年的演化, 已经差异比较大了, 代码的合并测试是个麻烦的活.
现在一个底层 BUG, 要在多少个项目上改, 要在哪个分支上改, 改多少, 测不测? 谁来确认?
我们已经改不动了. 这么多年来, 人员来来往往, 风格各异, 屎山代码就是这样形成的.

金律

  1. 以二进制模式复用, 不要源码级别复用. 解决反复源码打补丁的问题.

  2. 功能模块 必须隔离. 比如我在开发功能C, 其他不相干的模块全部不要加载.
    如用不上功能F, 功能F的开发还依赖某冷门私有RPM包(此RPM还需持续保持更新,否则功能F编译报错).
    否则 我要开发功能C, 还要解决别人的冷门RPM依赖(不是所有人都会在README中说明依赖信息的)
    解决 开发者 环境臃肿问题.

  3. 二进制模块发布