关于研发规范化的一些实践和思考
除了老板之外,我想大多数人是讨厌规则的,因为它束缚了我们的自由。然而,无论是个人,还是组织,规则却是发展中必不可少的环节,虽然我们很难看出规则的直接价值。
研发类任务,更是一类严谨的工作,它不仅需要严谨的逻辑思维能力,更需要一个完善的研发规范流程。对于程序员的我们,其实我们心里是比较讨厌规则的,在我们心里,只要把需求完成,上线就ok了,其他都是浮云,其实,这样的心里,我以前也是有过。
那么,一个标准的合理的研发规范,应该是怎样的?
这篇文章,我将与大家分享自己认为的研发规范化应该是怎样的, 若有任何问题,请大家及时在评论区提出与交流。
1 范围
本规范适用于【技术部-各组】所有关联的相关人员,如产品、开发、测试、运维等,技术部相关人员应严格遵守并执行。
2 目的
俗话说,“不以规矩不成方圆”,磨刀不误砍柴工,良好的文档和文档管理是项目或产品成功的关键要素之一,它能有效地解决项目开发中的极大部分问题,如业务规范,开发人员职责划分,技术规范,项目管控、项目测试、项目上线、项目运营、bug追踪等问题。
无论是传统的瀑布式开发、敏捷开发,devops,还是多种方式结合的开发模式,标准流程万变不离其宗,均可抽象成标准流程。
3 需求如何流转
需求如何流转?这是个标准化流程问题。根据我多年的研发、架构、团队管理等经验,与大家分享我的见解。
我个人认为,一个正常的需求流程应具备如下关键环节。
在实际研发中,不必完全按照该流程流转,我的建议是模块及模块以上的需求,按照该标准流程,模块及以下的需求,可根据实际情况,参照该流程的局部流程即可。
3.1 需求维度
关于需求,应包含如下五大阶段:
编辑
添加图片注释,不超过 140 字(可选)
3.1.1 需求提出
需求提出为需求整个阶段的首要环节。对需求的后续环节影响非常大,因此良好的需求提出至关重要,为此,需求提出人员应做到如下两个方面:
(一)明确需求
明确需求,提供如下参考意见:
1.该需求背景是什么?
2.该需求主要解决什么业务问题?
3.决定该需求成败的关键因素有哪些?
4.该需求涉及到哪些业务领域?
5.该需求涉及到公司哪些相关部门?
6.该需求的的调研方式有哪些?
7.该需求的成本,如开发成本,人力成本等
(二)需求应具备相关要素
编辑切换为居中
添加图片注释,不超过 140 字(可选)
3.1.2 需求调研
需求调研为需求五大阶段的第二环节。采用的调研方式,调研结果直接影响需求的准确性,因此需求调研是非常重要,不可或缺的部分。
需求调研必须要解决需求提出阶段(一)明确需求的几个重要问题。
当调研结束后,要对调研的结果,获取的资料进行提取,加工,转换和分析,然后将分析的结果形成文档,并以一定的形式展示出来,方便后期需求评审等一系列工作。
3.1.3 需求定义
需求定义为需求五大阶段的第三环节。当完成需求调研后,需求攥写人要对需求五大阶段第二环节认真分析,并在需求调研人的协助下完成需求文档的编写,当完成需求的定义及分析后,需要将此过程书面化,要遵循既定的规范将需求形成书面的文档,我们通常称之为《需求分析说明书》。
需要注意的是,关于晦涩的业务需求点,需求攥写人应借必要工具进行建模分析,展示,以方便技术开发人员理解交流,除此之外,需求定义过程中通常会出现的问题有内容失实、遗漏、含糊不清和前后描述不一致,需求攥写人也着重标注类似业务需求点,以尽量减少或防止造成业务需求的二义性
3.1.4 需求评审
需求评审为需求五大阶段的第四环节。关于需求评审,应着重关注如下几个因素:
(一) 评审参与人员
原则上,需求评审应确保如下至少五方人员参与:
1.需求方:该需求提出人
2.开发方:该需求开发负责人
3.测试方:该需求测试人员
4.DBA方:相关DBA人员
5.运维方:相关运维人员
(二) 评审内容
评审内容,应从如下几个方面进行:
1.需求方案可行性
应从需求业务价值可行性、技术可行性,运维可行性和成本可行性等诸多因素考虑
2.业务需求准确性
应从需求是否可行,需求是否遗漏,需求是否准确等方面评估
(三)评审记录
需求评审阶段,必须对评审过程和最终结果进行记录,并归档
(四)评审修订
评审过程,势必会造成偏差,应对偏差进行纠正,并反复校验,从而形成最终需求文档
3.1.5 需求定稿
需求定稿为需求五大阶段的最后环节。该环节将前四环节进行归档,并最终形成定稿《需求说明书》并归档,需求名建议格式:【需求负责人-类别-需求名称-八位日期--版本-已评审】+文件格式,如【wangjm-需求文档-支付系统设计一期-20211117-v1.0-已评审】.doc
3.2 架构维度
3.2.1 业务架构
业务架构作为技术方案的首要环节,若公司有业务架构师,应由业务架构师设计,否则由技术架构师设计。业务方案的好坏直接影响技术架构和技术选型的设计,因此在设计业务方案时,应重点考虑但不限于如下因素:
1.该业务的价值是什么?直接利润、间接利润、流量、or其他?
2.定义业务类别,即该业务属于0到1创新型业务,还是1.1到1复制型业务,或局部创新型业务?
3.该业务是属于核心业务,非核心业务还是公共业务?
4.该业务的领域边界是什么,该业务领域与其他业务领域的关联关系是怎样的,以及该业务对其他业务会产生怎样的影响?
5.该业务的纵/横向是怎样的?
6.当前的业务现状是怎样的,深入挖掘过去,现在,以及未来可能的业务发展。
7.深入分析当前的业务痛点、业务瓶颈等。
3.2.2 业务架构评审
评估业务架构时,应重点考虑但不限于如下因素:
1.业务架构是否能准确描述《需求说明书》上的业务需求点?
2.业务架构是否存在遗漏《需求说明书》上的业务需求点?
3.业务架构是否结合公司技术栈,开发团队、运维实际情况等因素综合考虑?
4.业务架构是否准确体现核心业务和非核心业务?
5.业务架构是否对业务进行类别的高度抽象与剥离?
6.业务架构是否考虑公司未来业务的发展等诸多因素?
7.业务架构师在设计前和设计时,应反复与需求方,产品经理和相关开发小组leader充分沟通,缩小偏差
8.评审结束后,必须形成业务架构方案,业务架构方案评估通过后,形成业务《业务架构方案》并归档,业务架构方案名格式参考:【业务架构师-类别-需求名称-八位日期--版本-已评审】+文件格式,如【wangjm-业务架构-支付系统设计一期-20211117-v1.0-已评审】.doc
3.2.3 技术架构
技术架构作为技术方案的第二环节。作为技术架构师,在进行技术架构前,必须深入研究《需求说明书》和《业务架构方案》,只有充分了解并掌握《需求说明书》和《业务架构方案》后,方可进行架构设计。
技术架构师在设计技术方案时,应重点考虑但不限于如下因素:
(一)掌握《需求说明书》和《业务架构方案》
作为技术架构师,必须深入研究《需求说明书》和《业务架构方案》,在研究中,遇到任何相关业务问题,应及时寻求相关业务人员、业务架构师等的帮助,避免对业务需求理解造成偏差,必须深入理解并掌握《需求说明书》和《业务架构方案》之后,方可设计《技术架构方案》。
(二)了解项目预算和项目周期
项目预算和项目周期,技术架构师在设计项目架构时,要充分考虑
(三)了解技术团队素质
应充分考虑技术团队素质,应着重考虑但不限于如下因素:
1.团队技术栈
2.团队技术人员梯队
应充分考虑当前技术团队梯队,如高级专家、技术专家、高级技术和初中级技术等。
3.规划参与项目开发的技术人员
充分了解《需求说明书》,《业务架构方案》,当前团队技术栈和团队技术人员梯队后,就可以规划实现需求的相关人员了,包括人数数量和人员级别,预计投入工作量等。
(四)确定技术方案
对(一)(二)(三)考虑充分后,即可进行技术方案的设计,在设计技术方案时,应重点考虑但不限于如下因素:
(1)开发语言选型
选择什么语言(或是混合语言,如java+php),应考虑诸多因素,如技术圈生态,团队技术栈,成本,开发周期等,然后综合权衡决定。
(2)前端框架
(3)后端框架
(4)缓存技术
(5)数据库技术
(6)中间件技术
(7)分布式技术
3.2.4 技术架构评审
作为技术架构师,在技术架构评审时,应重点评估如下要素。
1.当前公司技术现状、瓶颈、以及未来发展
2.技术框架的成熟度、稳定性、可伸缩性、风险性等
3.所选型的技术生态,国内外现状是怎样的?
4.无论是servlet,ssh,ssm,microservice还是domain designer,逻辑架构要清晰,提供如下两种架构模式参考:
模式一:servlet,ssh,ssm和microservice
说明:关于调用远程服务问题,可在controller层,也可在service层,具体放在哪层呢?提供一个标准:若业务逻辑复杂,则放在service层;若业务逻辑简单或基本没任何业务逻辑,则可放在controller。当然,也可单独将remote独立成一个模块。
编辑切换为居中
添加图片注释,不超过 140 字(可选)
如下是我在支付宝总部工作时,SofaStack逻辑架构,供参考:
编辑切换为居中
添加图片注释,不超过 140 字(可选)
模式二:领域化
关于领域和微服务建设,可采参考六边形模式:
逻辑架构:
编辑切换为居中
添加图片注释,不超过 140 字(可选)
3.2.5 方案评审参与人员
无论是《业务架构方案》还是《技术架构方案》,均需要评估,如下相关人员应参与方案的评估:
1.业务需求方
2.业务架构师、技术架构师
3.开发leader和开发相关人员
4.测试leader和测试相关人员
5.数据库Leader和数据库相关人员
6.运维leader和运维相关人员
3.2.6 技术选型参考
一、后端技术选型
对于新项目,技术选型应以如下技术选型为准;对于旧项目,迭代时,也应以如下技术选型为准。
1.后端框架:Spring,SpringBoot,SpringCloud
2.数据库访问技术:mybatis,hibernate(非特殊情况不用)
3.缓存技术:redis
4.存储技术:OSS
5.DB技术:MySql5.7
6.注册中心:Eureaka,Zookeeper,Nacos(建议用)
7.配置中心:apollo
8.分布式技术:hmily,seata
9.链路追踪:slueth
10.监控:cat
11.日志:ELK,log4j2
12.管理框架:springadmin
13.权限框架:OAuth2
14.分库分表:MyCat(暂定)
15.开发工具:Idea 2018+,Navicat,RedisClient,VisualVM2.0.7,FinalShell
16.容器:Tomcat9+
17.jdk:1.8
18.mq:Rocketmq,Rabbitmq(非特殊情况不用)
19.压测:jmeter
二、前端技术选型
1.基本前端技术:H5,CSS,JavaScript
2.框架:vue js(优先考虑),Angular JS
三、运维技术选型
1.自动化发布:Jenkins
2.jar包管理:Nexus
3.镜像管理:Harbor
4.编译工具:maven
5.压力测试:jmeter
6.容器:docker,k8s
7.代码管理工具:git
7.负载均衡:F5(优先考虑),Ngnix
3.3 开发维度
编辑切换为居中
添加图片注释,不超过 140 字(可选)
关于开发维度流程,对开发人员来说,还是比较清楚的,不多论述,补充一点:
在很多公司,其实是没有自测和自测报环节的,开发人员开发结束后,就直接发给测试人员测试,关于是否建立该环节,不同公司,有不同取舍,根即实际情况来定,但一般具备一定规模的公司,原则上需要有的,
3.4 测试维度
编辑切换为居中
添加图片注释,不超过 140 字(可选)
严格来说,测试人员应包括:自动化测试、黑/白盒测试。
当前,行业存在这样一种现象,IT文化不是很浓厚,或者从Donet转型到java的一些公司,测试人员一般仅仅测试业务功能的准确性,而不深入到实际的代码、代码日志、sql、数据准去性等,且公司的测试人员也不具备这样的能力。但我们不能说这样的测试就不好,要结合公司实际情况,我的观点是,但凡涉及到核心业务、涉及到金额的,测试人员必须要深入到代码、代码日志、sql、验证数据准确性等,不能单纯的点点页面校验业务逻辑。
无论公司测试类别是怎样的,测试人员应准备测试用例,测试结束后,要有测试报告。
3.5 线前评审
所谓线前评审,指上线前的代码评审,评审内容大致如下:
编辑切换为居中
添加图片注释,不超过 140 字(可选)
3.5.1 代码规范性
Java后端开发规范,目前暂时参考阿里Java后端开发手册,根据公司实际情况,逐步整合成属于公司自己的规范。具体可参考如下网站:
https://github.com/alibaba/p3c
中文版:阿里巴巴Java开发手册
English Version: Alibaba Java Coding Guidelines
MySQL数据库设计规范,目前暂时参考阿里MySQL设计规范,后期整合成属于公司自己的规范。
3.5.2 源码管理规范
统一采用gitlab和git来管理代码,在进行迭代开发时,统一采用如下标准流程:
编辑切换为居中
添加图片注释,不超过 140 字(可选)
迭代分支和开发分支命名规则:
(1)迭代分支命名规则:项目名_feature_八位日期时间格式_需求编号
eg:order_feature_20210616_需求编号
(2)开发分支命名规则;项目名_开发人员姓名拼音_八位日期时间格式
eg:order_wangjm_20210616 _需求编号
说明:关于开发分支,要灵活,若是多人协作开发,则按照master=>featrue=>dev 流程;若只是个人开发,则可直接在迭代分支上开发,即master=>featrue
3.5.3 代码评审
对于核心业务,核心模块,尤其是涉及到用户资产的功能,必须进行代码评审,架构师,项目leader,功能实际开发者和产品经理(需求方)参与代码评审,代码评审时,从如下几个方面进行:
1.代码业务逻辑评估,主要包括是否存在功能缺失,业务准确性等
2.数据逻辑评估(SQL业务逻辑,Redis业务逻辑,Hubble业务逻辑,mq业务逻辑)
3.代码覆盖率评估
4.日志评估
5.try...catch... 评估
6.三板斧评估(可监控、可回滚和可灰度)。关于这点,是我之前在支付宝总部工作时,上线前的必须条件,一些公司资源可能还达不到该要求,可根据实际情况取舍。
3.6 运维维度
原则来说,发布的职责应该由运维来做,但一般随着公司业务的发展,规模的壮大,运维人手严重不够,因此企业运维就推出了自动化发布平台,推出该平台后,运维将发布职责转交给具体的业务开发部门,不再肩负发布的职责,只为业务开发部门提供发布过程中,遇到的平台问题咨询服务。
作为业务部门,在发布时,注意几个点:
1.发布的顺序。dev=>test=>uat=>gray=>prod
2.发布的窗口,这个运维平台统一控制的
3.回退机制
对于规模不是很大的公司,一般具备标准的dev=>test=>uat=>gray=>prod流程,但中间环境存在很多不规范,如可直接跳过uat发prod。支付宝的发布流程是系统控制的,并且是一环扣一环的,只有前面环节过了,才能进入下一步环节,一般不能跨环节发布,如dev不能直接到uat,必须dev=>test=>uat。
3.7 线上追踪维度
1.发布后的1小时内,需要验证线上环境的正常性,如业务流准确性、数据准确性
2.验证人员包括:开发、测试、产品经理、架构
3.若出现异常,及时回退,立刻止血。具有一定流量的系统,一般是禁止线上排查和线上修复问题的。
4.做好线上问题记录,提供记录格式,仅供参考:
编辑切换为居中
添加图片注释,不超过 140 字(可选)
4 资源管理
根据公司实际情况,资源管理可选方案还是蛮多的,当前比较受欢迎的资源管理工具主要为语雀和wiki。
提供如下资源类别划分,仅供参考:
具体包括五大类别:技术文档,技术书籍,工具包,项目文档和产品文档。每个文档类别定义如下:
(1)技术文档:存放技术相关文档,如核心技术文档,技术攻关文档,团队技术分享文档等
(2)技术书籍:存放技术类相关书籍
(3)工具包:存放IT公用的工具,分为mac和windows两个版本
(4)项目文档:存放项目相关文档,具体项目又包含三类别文档:需求文档,开发文档和测试文档
(5)产品文档:存放产品相关文档, 此存储空间使用对象为产品
大致目录结构如下:
---资源管理
|--技术文档
|--技术书籍
|--工具包
|--mac工具包
|--win工具包
|--项目文档
|--项目名称
|--需求文档
|--开发文档
|--测试文档
资源获取:
大家点赞、收藏、关注、评论啦 、查看
关于研发规范化的一些实践和思考相关推荐
- DevData Talks | 微众银行有哪些研发效能实践与思考?一起来拓展认知边界!
本期 DevData Talks 直播活动中,我们非常高兴地邀请到了微众银行研发效能负责人余伟老师与我们分享微众银行在研发效能实践方面的经验与方法. 微众银行是一家面向互联网的银行,从诞生之日起就一直 ...
- 阿里云马劲:保证云产品持续拥有稳定性的实践和思考\n
对所有的技术人员来说,业务可靠性提升是一个系统工程,涉及网络管理.IDC管理.服务器管理.交付管理.变更管理.故障管理.监控管理.预案管理.根因分析.容量规划.容灾演练.标准化建设.集成测试.泛操作管 ...
- 阿里云马劲:保证云产品持续拥有稳定性的实践和思考
对所有的技术人员来说,业务可靠性提升是一个系统工程,涉及网络管理.IDC管理.服务器管理.交付管理.变更管理.故障管理.监控管理.预案管理.根因分析.容量规划.容灾演练.标准化建设.集成测试.泛操作管 ...
- 阿里云马劲:保证云产品持续拥有稳定性的实践和思考 1
对所有的技术人员来说,业务可靠性提升是一个系统工程,涉及网络管理.IDC管理.服务器管理.交付管理.变更管理.故障管理.监控管理.预案管理.根因分析.容量规划.容灾演练.标准化建设.集成测试.泛操作管 ...
- 百度SDN实践与思考
为什么80%的码农都做不了架构师?>>> 编者按:2015中国SDN/NFV大会在北京召开,本次大会围绕SDN/NFV展开讨论,来自运营商.服务提供商等业界巨头纷纷参与此次大会 ...
- 中小型研发团队架构落地实践18篇,含案例、代码
1 写在前面 中小型研发团队很多,而社区在中小型研发团队架构实践方面的探讨却很少.中小型研发团队特别是 50 至 200 人的研发团队,在早期的业务探索阶段,更多关注业务逻辑,快速迭代以验证商业模式, ...
- 学习工行MySQL研发管控和治理实践的过程
前两天碰巧看到了工行的魏老师在DAMS上演讲的主题<围剿慢SQL,工行MySQL研发管控和治理实践>,我们目前所做的一些工作和他讲的不谋而合,而且有些环节,值得我们思考和借鉴. 本文根据魏 ...
- 围剿慢SQL,工行MySQL研发管控和治理实践
本文根据魏亚东老师在[2021 DAMS中国数据智能管理峰会]现场演讲内容整理而成. 讲师介绍 魏亚东,中国工商银行 软件开发中心三级经理,资深架构师,杭州研发部数据库专家团队牵头人和开发中心安全团队 ...
- 水滴数据建设实践及思考:2大关键问题,4大破局措施
近日,水滴公司数据平台产品部负责人SKY在「让业务用起来 · 观远数据2022智能决策峰会暨产品发布会」北京站现场带来<水滴数据建设实践及思考>主题分享.SKY在分享中讲述了水滴数据团队在 ...
最新文章
- 如何在您的笔记本上搭建View 演示环境 -5.配置View Connection Server
- acm数论之欧几里得gcd
- SparkSQL介绍
- [PHP] 内部接口简单加密验证方式
- cocos label html文本,【cocos2dx】创建简单的文字Label——BMFont
- Hexo 博客自定义一个不使用主题模板渲染的独立页面
- 查看计算机80端口,电脑win10 80端口被占用的检测和解决方法
- libvirt 创建的文件
- 拓端tecdat|Matlab正态分布、历史模拟法、加权移动平均线 EWMA估计风险价值VaR和回测Backtest标准普尔指数 SP500时间序列
- 手机号码检测开通微信查询方法
- Linux下设置MTU值到9000
- python爬虫代码大作业_爬虫大作业
- 大脑简史(3)-大脑的结构
- MPC5748g基于源码实现ENET-PING实验(编译+调试)
- Win7 运行bat批处理文件时怎么隐藏cmd命令提示符窗口
- python网络编程学什么_python网络编程学习《一》
- 【Android】图像像素点理解
- Axapta program, involve MenuItem:程序定义MenuItem
- python脚本执行CMD命令并返回结果
- 定时闹钟课程设计c语言,基于单片机89c52定时闹钟的课程设计.pdf
热门文章