除了老板，我认为大多数人讨厌规则，因为它们限制了我们的自由。然而，无论是个人还是组织，规则都是发展中不可或缺的一环，尽管很难看到规则的直接价值。
研发。d任务是一种严谨的工作，不仅需要严谨的逻辑思维能力，更需要完美的研发；标准流程。对于我们程序员来说，其实我们心里讨厌规则。在我们心中，只要完成了要求，上线就可以了，其他的一切都只是浮云。其实我以前也有过这种心。
那么，一个标准合理的研发应该是什么样的呢？诺姆是吗？
在这篇文章中，我将与你分享我对研发的看法；d标准化应该是。如有疑问，请及时在评论区提出和交流。
# 1范围
本规范适用于【技术部-各组】所有相关人员，如产品、开发、测试、运维等。技术部相关人员应严格遵守并执行。
# 2目的
俗话说，“方圆不能靠规则来实现”。好的文档和文档管理是项目或产品成功的关键因素之一。它可以有效解决项目开发中的大部分问题，如业务规范、开发人员职责分工、技术规范、项目控制、项目测试、项目启动、项目运营、bug跟踪等。
无论是传统的瀑布开发、敏捷开发、devops还是多种方式结合的开发模式，都可以将标准流程抽象为标准流程。
# 3需求如何流动？
需求是如何流动的？这是一个标准化的过程问题。基于我多年的研发经验；d、架构和团队管理，我想和大家分享一下我的看法。
我个人认为一个正常的需求流程应该有以下几个关键环节。
在实际研发中；d、没有必要完全遵循这个过程。我的建议是模块及以上的需求。按照标准流程，模块及以下的需求可以根据实际情况参考本流程的局部流程。
# 3.1需求维度
需求应包括以下五个阶段：
# 3.1.1需求提交
需求呈现是整个需求阶段的第一步。对需求的后续环节影响很大，所以好的需求呈现非常重要。因此，需求展示人员应做好以下两个方面的工作：
（一）明确需求
定义要求并提供以下参考意见：
1.需求背景是什么？
2.这个需求主要解决哪些业务问题？
3.决定这种需求成败的关键因素是什么？
4.需求涉及哪些业务领域？
5.该需求涉及公司哪些相关部门？
6.这个需求的研究方法是什么？
7.需求的成本，如开发成本、人工成本等。
（二）需求应具备相关要素
# 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独立成一个模块。
如下是我在支付宝总部工作时，SofaStack逻辑架构，供参考：
模式二：领域化
关于领域和微服务建设，可采参考六边形模式：
六边形模型：
逻辑架构：
# 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 开发维度
关于开发维度流程，对开发人员来说，还是比较清楚的，不多论述，补充一点：
在很多公司，其实是没有自测和自测报环节的，开发人员开发结束后，就直接发给测试人员测试，关于是否建立该环节，不同公司，有不同取舍，根即实际情况来定，但一般具备一定规模的公司，原则上需要有的，
# 3.4 测试维度
严格来说，测试人员应包括：自动化测试、黑/白盒测试。
当前，行业存在这样一种现象，IT文化不是很浓厚，或者从Donet转型到java的一些公司，测试人员一般仅仅测试业务功能的准确性，而不深入到实际的代码、代码日志、sql、数据准去性等，且公司的测试人员也不具备这样的能力。但我们不能说这样的测试就不好，要结合公司实际情况，我的观点是，但凡涉及到核心业务、涉及到金额的，测试人员必须要深入到代码、代码日志、sql、验证数据准确性等，不能单纯的点点页面校验业务逻辑。
无论公司测试类别是怎样的，测试人员应准备测试用例，测试结束后，要有测试报告。
# 3.5 线前评审
所谓线前评审，指上线前的代码评审，评审内容大致如下：
# 3.5.1 代码规范性
Java后端开发规范，目前暂时参考阿里Java后端开发手册，根据公司实际情况，逐步整合成属于公司自己的规范。具体可参考如下网站：
https://github.com/alibaba/p3c
* 中文版:阿里巴巴Java开发手册
* English Version: Alibaba Java Coding Guidelines
MySQL数据库设计规范，目前暂时参考阿里MySQL设计规范，后期整合成属于公司自己的规范。
# 3.5.2 源码管理规范
统一采用gitlab和git来管理代码，在进行迭代开发时，统一采用如下标准流程：
迭代分支和开发分支命名规则：
（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.做好线上问题记录，提供记录格式，仅供参考：
# 4 资源管理
根据公司实际情况，资源管理可选方案还是蛮多的，当前比较受欢迎的资源管理工具主要为语雀和wiki。
提供如下资源类别划分，仅供参考：
具体包括五大类别：技术文档，技术书籍，工具包，项目文档和产品文档。每个文档类别定义如下：
（1）技术文档：存放技术相关文档，如核心技术文档，技术攻关文档，团队技术分享文档等
（2）技术书籍：存放技术类相关书籍
（3）工具包：存放IT公用的工具，分为mac和windows两个版本
（4）项目文档：存放项目相关文档，具体项目又包含三类别文档：需求文档，开发文档和测试文档
（5）产品文档：存放产品相关文档， 此存储空间使用对象为产品
大致目录结构如下：
\---资源管理
|--技术文档
|--技术书籍
|--工具包
|--mac工具包
|--win工具包
|--项目文档
|--项目名称
|--需求文档
|--开发文档
|--测试文档
