https://github.com/qiangmzsx/Software-Engineering-at-Google 谷歌的软件工程可参考
代码管理
gitlab - manage the code, and do things about cicd
将开发者账号集中管理, 使用时申请, 赋予权限, 离职注销
代码版本管理规范
cicd 配置
需求/bug管理
禅道 - 国产
jira
设计
蓝湖 - 国产
可以使用svn 管理权限
figma
基础技术框架
如果工作定性为外包公司，那就搭建脚手架、代码生成平台、测试发布和运维平台、定制常用的类库和吸纳开源类库，做到快速开发和代码复用。
如果是某个公司的技术部门，不以技术为主要盈利人数较少，那我觉得不要分布式和微服务，建议全部上云减少运维成本，用 nignx 做软负载均衡即可。
如果是技术型初创公司，建议是用手底下最常用的技术先快速实现业务，然后做的大一些时在用也就 java 体系、GO 体系来重写业务框架。
├── kyland-spring-boot-starter-parent -- starter父模块
├── kyland-spring-boot-starter-base -- 基础模块
├── kyland-spring-boot-starter-core -- 核心模块
├── kyland-spring-boot-starter-ds -- 数据源模块
├── kyland-spring-boot-starter-file -- 文件存储模块
├── kyland-spring-boot-starter-log -- 日志模块
├── kyland-spring-boot-starter-low-code -- 低代码模块
├── kyland-spring-boot-starter-message-queue -- 消息队列模块
├── kyland-spring-boot-starter-redis -- redis模块
├── kyland-spring-boot-starter-security -- 安全模块
├── kyland-spring-boot-starter-swagger -- 接口文档模块
├── kyland-spring-boot-starter-system -- 系统内置功能模块
├── kyland-spring-boot-starter-web -- web启动器
前端部分:
搭建脚手架工具
yarn create kyland-app
qiankun 微应用框架
基础能力中间件
nacos
kkfileview 文件预览
MINIO 文件存储
RabbitMQ/ kafka 消息队列
基础能力包装 sdk
任务调度
Socket
定义编码规范
安装 alibaba 风格插件, Basically we obey the Alibaba java coding style,
or
安装 checkstyle 插件, 通过checkstyle配置风格校验
标识符命名规范
注释规范
代码风格规范
接口及文档规范
数据库规范
前端规范
css语法规范
声明顺序要约定一致, 相关的属性声明应当归为一组
由于定位（positioning）可以从正常的文档流中移除元素，并且还能覆盖盒模型（box model）相关的样式，因此排在首位。
盒模型排在第二位，因为它决定了组件的尺寸和位置。
其他属性只是影响组件的 内部 或者是不影响前两组属性，因此排在后面。
.mod-example {
/* 定位 */
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
z-index: 100;
/* 盒模型 */
display: block;
float: right;
width: 100px;
height: 100px;
/* 排版 */
font: normal 13px "Helvetica Neue", sans-serif;
line-height: 1.5;
color: #333;
text-align: center;
/* 视觉效果 */
background-color: #f5f5f5;
border: 1px solid #e5e5e5;
border-radius: 3px;
/* 其他 */
opacity: 1;
}
避免使用 !important ，能不用坚决不用。
禁止使用层级过深的选择器，最多3 ～ 5级
运维
k3s 安装kubernetes
kuboard 管理面板
研发流程
常规研发流程:
<
>
紧急研发流程适用于紧急需求、生产环境重大故障或者其他紧急情况，该流程主要是为了针对紧急情况做出快速反应，因减少了审环节，同时也增大了项目的风险
关键节点
需求评审：由产品经理主持，UI设计、研发、测试以及其他相关人员参与，采用逐个需求串讲和现场答疑的方式进行。评审通过后，由设计、研发、测试评估相应的工时，并根据需求优先级和迭代总工作量决定是否纳入迭代内，评审不通过，则由产品经理重新对需求进行分析。
代码评审：当研发人员完成相应功能的编码工作提交合并代码请求之后，技术负责人对接提交的代码进行评审，评审不通过，则退回相应的研发人员修改，评审通过，则合并到相应的分支。
测试用例评审：需求评审结束后，待测试团队完成迭代内所有需求的测试用例的编写，由测试负责人主持，相应模块的测试人员主讲，产品经理和项目经理参与，对其测试用例进行评审，评审不通过的测试用例，则由相应测试人进行修改，评审通过，则将其纳入测试计划中。
关键文档
PRD文档/原型：就是将天马行空的概念具象化为实际的业务逻辑、UI页面、菜单按钮、字段定义、数据结果，最终辅导开发人员将系统研发出来。通常包含产品背景及定位、功能需求、逻辑架构、原型设计等信息。PRD文档是产品项目由“概念化”进入“图纸化”的最主要的文档，编写主要有几个目的：
概念具象化：产品人员搜集了各方的需求进行去伪存真的处理之后，需要对单个的需求点整合 –> 抽象 –> 具象，输出为黑字白纸的落地文档；并且的文档的编写过程中，可以从全局的角度和细节中去验证逻辑是否正确；
协助项目开发：从项目立项开始、到项目评审、项目开发、项目验收，PRD文档贯穿了整个产品的诞生过程，重要性可想而知；产品定版证据：产品文档编写完毕之后就要进行封版处理，不能在开发过程中频繁变动需求，否则交付会无限延期；
记录产品演进蓝图：若研发过程中需求有变动会首先排查文档的定版内容，对变动需求单独进行处理；若为版本迭代，也可以根据以前的版本记录进行追踪查源；
预防人员变动：若公司的人员流动性比较强，文档保存不当，会导致产品的持续性研发迭代变得异常困难。
产品计划：根据项目的重要交付节点将整个产品周期划分为多个里程碑计划，明确每个里程碑计划交付物（包括但不限于系统、文档等项目相关事项）以及交付时间，产品经理根据每个里程碑计划按时输出PRD文档/原型，并及时跟研发、测试、设计等相关团队评审并纳入相应的迭代计划内。
迭代计划： 根据项目的具体情况将整个开发过程划分为多个迭代周期，每个迭代周期时间的长短取决于当前项目的进度和实际执行情况。而迭代开发计划则发生在每一迭代之前，在确定迭代的开始和结束时间之后，根据需求的优先级、工作量以及人力资源，将已评审通过的需求纳入相应的迭代内，项目经理（研发）将需求拆解按功能模块拆分成具体的开发任务，并分配到指定的研发人员。
测试计划：根据迭代开发计划、测试任务的工作量以及人力资源情况，将已评审通过的测试用例，纳入到迭代测试计划中，并评估测定范围、工时、测试资源、测试进展和风险预警。
测试报告：每个迭代集成测试通过后，根据实际测试情况编写测试报告，并描述软件的测试过程、 测试环境、测试范围、测试结果的文档以及分析总结系统存在的风险以及测试结论。
角色和分工
产品经理：在需求前期负责需求调研、收集、分析和评审、需求说明文档（RRD）的编写和产品原型的设计。需求评审通过后，编写需求说明文档（RRD），然后跟研发、测试等相关人员做需求澄清。在需求后期负责产品需求的跟踪、验收和其他相关的工作。
项目经理（研发）：参与需求澄清以及负责迭代开发计划的制定，以及需求的功能模块拆分和开发任务的拆解，协调产品、研发和测试，确保项目研发进度的正常推进，并负责测试、仿真和正式各环境的项目上线工作。
技术负责人：负责项目前端/后端框架的选型和搭建、技术难点的攻关，参与需求评审以及负责核心业务功能的设计，负责前端/后端代码的评审工作以及确保交付项目前端/后端的代码质量。
UI设计师：负责项目整体UE/UI/VI设计风格，并根据已评审的需求完成相应的UE/UI/VI设计，并在研发过程中确保前端开发的界面是严格参照设计来实现的。
研发工程师：负责前后端需求的编码工作以及对自己编码的部分完成单元测试，并及时完成相关bug修复工作，对于评审不合格的代码及时按要求修改。
测试工程师：负责系统的测试用例的编写，依据经过评审通过后的测试用例完成集成测试、回归测试和冒烟测试各个阶段的相关工作，并及时反馈给相应的研发人员和实时跟踪bug的修复情况，在集成测试通过后，提供相应的测试质量报告，在冒烟测试通过后想相关人员同步上线结果。
部门分工
产品部：负责需求调研、收集、分析和确认，以及需求的进度跟踪和验收工作，是研发需求的唯一输入方。
研发部：负责产品需求的具体实现，并确保项目的高质量高效率高水平交付。
测试部：负责项目交付的质量保证，确保交付物的可用性和可靠性，是系统缺陷的唯一输入方
基本工作准则
1、每项需求和任务都需要确定负责人和评估完成所需的工时
2、关键工作完成以后，需要进行评审，且评审通过后才可以进行下一项工作，比如PRD文档和原型需要需求评审通过后才可以进入迭代开发，提交合并的代码必须代码评审通过后才可以合并到开发分支，测试用例完成评审后才开始测试计划的编写。
3、不能按计划完成的工作，在每日例会中需及时沟通，并给出原因，有风险及时暴露出来。
4、所有需求修改和变更必须经过相应的产品经理和项目经理评审后提交给研发，所有缺陷或者bug必须经过测试人员和项目经理确认后提交给研发。
5、迭代结束之前完成上线工作，如果因其他因素导致不能在迭代结束前完成上线，需给出情况说明。
管理规范
经验之谈
具体情况具体分析，不看公司规模和业务来就是耍流氓。 首先要看公司目的是什么？
至于使用分布式体系，以 java 为例，我觉得一般公司可以考虑下面的步骤： (1)所有服务采用统一的技术体系，推荐 Springboot (2)搭建统一的脚手架，可以参考开源的一些，包括不限于分布式框架选型(Dubbo、SpringCloud)，分布式缓存选型(Redis)、日志处理和格式(采集建议 ELK)、消息中间件选型(Kafak、RokatMq)、分布式定时任务选型(ElasticJob)、统一的工具类库(cooms、guvua、fastjson 等)、Mybatis、代码生成器、Mybatis-plus、分页插件、统一异常定义和处理、统一的请求拦截器等。 (3)编码规范定义，可以参考阿里规范，但要考虑实用性，不可能每个人都强制遵守，那些是重要的，必须遵守，那些是可以适度放宽的。Maven、git 命名、打包、发布规范。 (4)建立自动化发布运维的框架比如 jenkins、ELK、钉钉邮件预警、网关(zuul 普罗米修斯)流量监控报警，以及 WIKI 和类似禅道之类的 BUG 管理平台 (5)这些算是通用的底子，然后要根据现有的业务进行拆分，比如微服务的话可以对业务拆分，比如用户平台、权限平台、商品平台、交易平台、风控平台等。微服务之上可以考虑增加业务聚合服务，直接对应部分前端。所有对外服务都应通过网关统一对外暴露，在网关层面考虑用普罗米修斯之类的对调用做监控。对于用户平台需要考虑统一的登录注册，可以考虑在网关层增加对调用的管理。交易平台可能跟风控相关，通过日志采集发往相关的处理系统再回写到相关表中，风控提供相关接口。比如商品可能需要检索系统，那可以考虑在基础之上增加 ElasticSearch 对商品信息进行检索。比如活动平台可以考虑增加规则引擎，高度自定义规则，将规则配置移交给运营人员，减少重复开发。根据公司业务拆分成不同的小平台和业务，再根据其特点选择技术。 (6)原则上有开源的系统，就学习并使用开源产品，这样减少开发时间，但随着业务发展开源产品不能满足时，可以根据自身特点开发自己的产品，比如业界的工作流可能不能满足公司的需求，公司可以自己开发一套基于 XX 上的改进版本。就类似与 Dubbo->Dubbox，甚至开源出来回馈社区
最后技术只是为业务服务的，任何公司都是依靠业务发展的，追求优秀的技术是正确，但要一定要考虑公司自身的情况和寻找合适的时间>_<