|
|
EDA365欢迎您登录！
您需要 登录 才可以下载或查看，没有帐号？注册
x
你的研发团队是否存在如下问题9 U- X' @$ y, P# N
程序bug不断5 `5 _( B) @$ `# o
好好的功能换个姿势使用就出bug0 v/ Q7 R- r+ D+ D
开发好的功能，业务流程走不下去
1 m- i6 c7 ?- ]( t每个开发人员写的代码风格各异 g& y7 T5 _2 Y. g
调试他人代码无比痛苦* N# i1 Q2 x& C: P
接手他人模块代码无比痛苦9 {, L' V3 k6 J2 K3 n- R9 M
代码要不不提交，一提交一大堆代码
# J0 U+ y! E9 z$ u) @等等等
" q& z1 B, t) i+ z' R* B) T; F. o+ W- y8 s- J/ N% l
版本控制提升研发代码质量
# d6 B" A+ ]# S1 B/ b代码管控的工作有很多种，早期大家使用SVN，现在大部分企业都用Git，使用GitLab建立企业自己的代码仓库服务器。为了契合企业自身的业务发展，有多种使用分支提交代码的方式，分别适用不同的业务发展特征。博主所在公司使用的是这种分支开发模式：Mast分支创建Dev分支，Dev作为过程版本分支每半个月一个，过程版本分支是用于不同项目交付使用的。新的Dev分支是在最新交付的Dev分支中拉取产生的。这种Git版本管控模式适合博主所在企业的业务发展模式(企业服务)。究竟哪些分支演进模式适合读者所在的企业，需要读者根据自己公司业务特征做选择。8 y' F- d; x; Q* n) b4 |2 R0 Q
4 ^& P6 d& i! ~8 e& \
功能设计规范化提升研发代码质量 d( W3 e; B1 K: A
要想研发的需求功能更可控适用，就必须把需求功能设计文档做好，设计文档分成两部分：一：PRD(产品需求文档)，此文档做好了，可以让开发者很清楚待开发的需求是干什么的，此需求将给谁用，解决什么业务问题。二：SRS(需求研发设计文档)，此文档作为研发人员针对PRD做的详细设计文档，此文档经过研发经理或者SE评审通过后，直接进入研发阶段，有了评审后的SRS护航，研发做的代码风向就不会错，再配合Code Review、自测、测试人员验证，产品需求质量就可以得到有效保障。根据博主多年工作经验，要想PRD\SRS产生较大的价值，必须要包含如下这些内容：6 p, ^$ ^2 f: i: O+ b0 z
1 h; I) T, T( ~1 q
1）PRD：最后面一定要有针对此功能的实际业务人员使用的带场景的示例流程，这样可以给研发、测试指明此功能最终的服务形态，也是研发自测的依据。
/ W5 v s- Q+ ~" z. _: d u: l+ ]/ |' v0 b3 i4 z
2）SRS：SRS做的越细越好，但是究竟要多细呢？究竟要包括哪些内容呢？ SRS内容至少要包括如下内容：详细的接口文档、物理模型PDM、新增修改类的UML图、指明是新增类/方法 还是 利旧已有的原子化类方法、要实现的业务逻辑的详细描述。6 O, U9 E$ i$ H; A- _( Y& _. V
1 l5 d& K5 p$ c
$ A% I: |6 U5 n5 C. l
|
|
/1 
发表于 2021-10-26 14:47
收藏
淘帖
支持！
反对！