php团队开辟规矩技巧_关于研发规范化的一些实践和思虑

研发类任务，更是一类严谨的事情，它不仅须要严谨的逻辑思维能力，更须要一个完善的研发规范流程。
对付程序员的我们，实在我们心里是比较讨厌规则的，在我们心里，只要把需求完成，上线就ok了，其他都是浮云，实在，这样的心里，我以前也是有过。

那么，一个标准的合理的研发规范，该当是若何的？

这篇文章，我将与大家分享自己认为的研发规范化该当是若何的， 若有任何问题，请大家及时在评论区提出与互换。

本规范适用于【技能部-各组】所有关联的干系职员，如产品、开拓、测试、运维等，技能部干系职员应严格遵守并实行。

俗话说，“不以规矩不成周遭”，磨刀不误砍柴工，良好的文档和文档管理是项目或产品成功的关键要素之一，它能有效地办理项目开拓中的极大部分问题，如业务规范，开拓职员职责划分，技能规范，项目管控、项目测试、项目上线、项目运营、bug追踪等问题。

无论是传统的瀑布式开拓、敏捷开拓，devops，还是多种办法结合的开拓模式，标准流程万变不离其宗，均可抽象成标准流程。

需求如何流转？这是个标准化流程问题。
根据我多年的研发、架构、团队管理等履历，与大家分享我的见地。

我个人认为，一个正常的需求流程应具备如下关键环节。

在实际研发中，不必完备按照该流程流转，我的建议是模块及模块以上的需求，按照该标准流程，模块及以下的需求，可根据实际情形，参照该流程的局部流程即可。

3.1 需求维度

关于需求，应包含如下五大阶段：

3.1.1 需求提出

需求提出为需求全体阶段的紧张环节。
对需求的后续环节影响非常大，因此良好的需求提出至关主要，为此，需求提出职员应做到如下两个方面：

（一）明确需求

明确需求，供应如下参考见地：

1.该需求背景是什么？

2.该需求紧张办理什么业务问题？

3.决定该需求成败的关键成分有哪些？

4.该需求涉及到哪些业务领域？

5.该需求涉及到公司哪些干系部门？

6.该需求的的调研办法有哪些？

7.该需求的本钱，如开拓本钱，人力本钱等

（二）需求应具备干系要素

3.1.2 需求调研

需求调研为需求五大阶段的第二环节。
采取的调研办法，调研结果直接影响需求的准确性，因此需求调研是非常主要，不可或缺的部分。

需求调研必须要办理需求提出阶段（一）明确需求的几个主要问题。

当调研结束后，要对调研的结果，获取的资料进行提取，加工，转换和剖析，然后将剖析的结果形成文档，并以一定的形式展示出来，方便后期需求评审等一系列事情。

需求定义为需求五大阶段的第三环节。
当完成需求调研后，需求攥写人要对需求五大阶段第二环节负责剖析，并在需求调研人的帮忙下完成需求文档的编写，当完成需求的定义及剖析后，须要将此过程书面化，要遵照既定的规范将需求形成书面的文档，我们常日称之为《需求剖析解释书》。

须要把稳的是，关于晦涩的业务需求点，需求攥写人应借必要工具进行建模剖析，展示，以方便技能开拓职员理解互换，除此之外，需求定义过程中常日会涌现的问题有内容失落实、遗漏、暗昧不清和前后描述不一致，需求攥写人也着重标注类似业务需求点，以只管即便减少或防止造成业务需求的二义性

需求评审为需求五大阶段的第四环节。
关于需求评审，应着重关注如下几个成分：

（一） 评审参与职员

原则上，需求评审应确保如下至少五方职员参与：

1.需求方：该需求提出人

2.开拓方：该需求开拓卖力人

3.测试方：该需求测试职员

4.DBA方：干系DBA职员

5.运维方：干系运维职员

（二） 评审内容

评审内容，应从如下几个方面进行：

1.需求方案可行性

应从需求业务代价可行性、技能可行性，运维可行性和本钱可行性等诸多成分考虑

2.业务需求准确性

应从需求是否可行，需求是否遗漏，需求是否准确等方面评估

（三）评审记录

需求评审阶段，必须对评审过程和终极结果进行记录，并归档

（四）评审修订

评审过程，势必会造成偏差，应对偏差进行纠正，并反复校验，从而形成终极需求文档

需求定稿为需求五大阶段的末了环节。
该环节将前四环节进行归档，并终极形成定稿《需求解释书》并归档，需求名建议格式：【需求卖力人-种别-需求名称-八位日期--版本-已评审】+文件格式，如【wangjm-需求文档-支付系统设计一期-20211117-v1.0-已评审】.doc

业务架构作为技能方案的紧张环节，若公司有业务架构师，应由业务架构师设计，否则由技能架构师设计。
业务方案的好坏直接影响技能架构和技能选型的设计，因此在设计业务方案时，应重点考虑但不限于如下成分：

1.该业务的代价是什么？直接利润、间接利润、流量、or其他？

2.定义业务种别，即该业务属于0到1创新型业务，还是1.1到1复制型业务，或局部创新型业务？

3.该业务是属于核心业务，非核心业务还是公共业务？

4.该业务的领域边界是什么，该业务领域与其他业务领域的关联关系是若何的，以及该业务对其他业务会产生若何的影响？

5.该业务的纵/横向是若何的？

6.当前的业务现状是若何的，深入挖掘过去，现在，以及未来可能的业务发展。

7.深入剖析当前的业务痛点、业务瓶颈等。

评估业务架构时，应重点考虑但不限于如下成分：

1.业务架构是否能准确描述《需求解释书》上的业务需求点？

2.业务架构是否存在遗漏《需求解释书》上的业务需求点？

3.业务架构是否结合公司技能栈，开拓团队、运维实际情形等成分综合考虑？

4.业务架构是否准确表示核心业务和非核心业务？

5.业务架构是否对业务进行类别的高度抽象与剥离？

6.业务架构是否考虑公司未来业务的发展等诸多成分？

7.业务架构师在设计前和设计时，应反复与需求方，产品经理和干系开拓小组leader充分沟通，缩小偏差

8.评审结束后，必须形成业务架构方案，业务架构方案评估通过后，形成业务《业务架构方案》并归档，业务架构方案名格式参考：【业务架构师-种别-需求名称-八位日期--版本-已评审】+文件格式，如【wangjm-业务架构-支付系统设计一期-20211117-v1.0-已评审】.doc

技能架构作为技能方案的第二环节。
作为技能架构师，在进行技能架构前，必须深入研究《需求解释书》和《业务架构方案》，只有充分理解并节制《需求解释书》和《业务架构方案》后，方可进行架构设计。

技能架构师在设计技能方案时，应重点考虑但不限于如下成分：

（一）节制《需求解释书》和《业务架构方案》

作为技能架构师，必须深入研究《需求解释书》和《业务架构方案》，在研究中，碰着任何干系业务问题，应及时寻求干系业务职员、业务架构师等的帮助，避免对业务需求理解造成偏差，必须深入理解并节制《需求解释书》和《业务架构方案》之后，方可设计《技能架构方案》。

（二）理解项目预算和项目周期

项目预算和项目周期，技能架构师在设计项目架构时，要充分考虑

（三）理解技能团队本色

应充分考虑技能团队本色，应着重考虑但不限于如下成分：

1.团队技能栈

2.团队技能职员梯队

应充分考虑当前技能团队梯队，如高等专家、技能专家、高等技能和初中级技能等。

3.方案参与项目开拓的技能职员

充分理解《需求解释书》，《业务架构方案》，当前团队技能栈和团队技能职员梯队后，就可以方案实现需求的干系职员了，包括人数数量和职员级别，估量投入事情量等。

（四）确定技能方案

对（一）（二）（三）考虑充分后，即可进行技能方案的设计，在设计技能方案时，应重点考虑但不限于如下成分：

（1）开拓措辞选型

选择什么措辞（或是稠浊措辞，如java+php），应考虑诸多成分，如技能圈生态，团队技能栈，本钱，开拓周期等，然后综合权衡决定。

（2）前端框架

（3）后端框架

（4）缓存技能

（5）数据库技能

（6）中间件技能

（7）分布式技能

作为技能架构师，在技能架构评审时，应重点评估如下要素。

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和运维干系职员

一、后端技能选型

对付新项目，技能选型应以如下技能选型为准；对付旧项目，迭代时，也应以如下技能选型为准。

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

关于开拓维度流程，对开拓职员来说，还是比较清楚的，不多论述，补充一点：

在很多公司，实在是没有自测和自测报环节的，开拓职员开拓结束后，就直接发给测试职员测试，关于是否建立该环节，不同公司，有不同取舍，根即实际情形来定，但一样平常具备一定规模的公司，原则上须要有的，

严格来说，测试职员应包括：自动化测试、黑/白盒测试。

当前，行业存在这样一种征象，IT文化不是很浓厚，或者从Donet转型到java的一些公司，测试职员一样平常仅仅测试业务功能的准确性，而不深入到实际的代码、代码日志、sql、数据准去性等，且公司的测试职员也不具备这样的能力。
但我们不能说这样的测试就不好，要结合公司实际情形，我的不雅观点是，但凡涉及到核心业务、涉及到金额的，测试职员必须要深入到代码、代码日志、sql、验证数据准确性等，不能纯挚的点点页面校验业务逻辑。

无论公司测试种别是若何的，测试职员应准备测试用例，测试结束后，要有测试报告。

所谓线前评审，指上线前的代码评审，评审内容大致如下：

3.5.1 代码规范性

Java后端开拓规范，目前暂时参考阿里Java后端开拓手册，根据公司实际情形，逐步整合成属于公司自己的规范。
详细可参考如下网站：

https://github.com/alibaba/p3c

MySQL数据库设计规范，目前暂时参考阿里MySQL设计规范，后期整合成属于公司自己的规范。

统一采取gitlab和git来管理代码，在进行迭代开拓时，统一采取如下标准流程：

迭代分支和开拓分支命名规则：

（1）迭代分支命名规则：项目名_feature_八位日期韶光格式_需求编号

eg：order_feature_20210616_需求编号

（2）开拓分支命名规则；项目名_开拓职员姓名拼音_八位日期韶光格式

eg：order_wangjm_20210616 _需求编号

解释：关于开拓分支，要灵巧，若是多人协作开拓，则按照master=>featrue=>dev 流程；若只是个人开拓，则可直接在迭代分支上开拓，即master=>featrue

对付核心业务，核心模块，尤其是涉及到用户资产的功能，必须进行代码评审，架构师，项目leader，功能实际开拓者和产品经理(需求方)参与代码评审，代码评审时，从如下几个方面进行：

1.代码业务逻辑评估，紧张包括是否存在功能缺失落，业务准确性等

2.数据逻辑评估(SQL业务逻辑，Redis业务逻辑，Hubble业务逻辑，mq业务逻辑)

3.代码覆盖率评估

4.日志评估

5.try...catch... 评估

6.三板斧评估(可监控、可回滚和可灰度)。
关于这点，是我之前在支付宝总部事情时，上线前的必须条件，一些公司资源可能还达不到该哀求，可根据实际情形取舍。

原则来说，发布的职责该当由运维来做，但一样平常随着公司业务的发展，规模的壮大，运维人手严重不足，因此企业运维就推出了自动化发布平台，推出该平台后，运维将发布职责转交给详细的业务开拓部门，不再肩负发布的职责，只为业务开拓部门供应发布过程中，碰着的平台问题咨询做事。

作为业务部门，在发布时，把稳几个点：

1.发布的顺序。
dev=>test=>uat=>gray=>prod

2.发布的窗口，这个运维平台统一掌握的

3.回退机制

对付规模不是很大的公司，一样平常具备标准的dev=>test=>uat=>gray=>prod流程，但中间环境存在很多不规范，如可直接跳过uat发prod。
支付宝的发布流程是系统掌握的，并且是一环扣一环的，只有前面环节过了，才能进入下一步环节，一样平常不能跨环节发布，如dev不能直接到uat,必须dev=>test=>uat。

1.发布后的1小时内，须要验证线上环境的正常性，如业务流准确性、数据准确性

2.验证职员包括：开拓、测试、产品经理、架构

3.若涌现非常，及时回退，急速止血。
具有一定流量的系统，一样平常是禁止线上排查和线上修复问题的。

4.做好线上问题记录，供应记录格式，仅供参考：

4 资源管理

根据公司实际情形，资源管理可选方案还是蛮多的，当前比较受欢迎的资源管理工具紧张为语雀和wiki。

供应如下资源种别划分，仅供参考：

详细包括五大种别：技能文档，技能书本，工具包，项目文档和产品文档。
每个文档种别定义如下：

（1）技能文档：存放技能干系文档，如核心技能文档，技能攻关文档，团队技能分享文档等

（2）技能书本：存放技能类干系书本

（3）工具包：存放IT公用的工具，分为mac和windows两个版本

（4）项目文档：存放项目干系文档，详细项目又包含三种别文档：需求文档，开拓文档和测试文档

（5）产品文档：存放产品干系文档， 此存储空间利用工具为产品

大致目录构造如下：

---资源管理

|--技能文档

|--技能书本

|--工具包

|--mac工具包

|--win工具包

|--项目文档

|--项目名称

|--需求文档

|--开拓文档

|--测试文档