![](https://img-blog.csdnimg.cn/20201014180756928.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
软件工程
文章平均质量分 73
软件工程
码海拾贝2023
享受技术
展开
-
UML详解
基本图形开发过程与UML关系用例图用例图,从用户角度描述系统行为功能(行为),并指出各功能的操作者参与者(actor) 一个人 一个系统 又称“主角”用例(use case) 参与者使用用例系统(system) 硬件和软件的结合体 业务问题的解决方案基本图形关系泛化:继承关系,子用例将继承基用例的所有行为,关系和通信关系,也就是说在任何使用基用例的地方都可以用子用例来代替includ...原创 2023-03-15 09:33:12 · 2104 阅读 · 1 评论 -
(十八)技术调研规范
目录1、什么时候做技术调研?2、如何去做这个技术调研?3、技术调研的流程和规范4、编写技术的培训手册5、对团队里的成员进行培训6、就可以将这个新技术用到我们的项目的技术设计中去了7、课程里,就会对每个技术的学习,都模拟成是,你现在要为你的公司引入这门技术,然后你学习就是在做调研。完全模拟公司里真实的技术调研和引入的环境和流程以及场景。Spring Boot和设计模式。1、什么时候做技术调研?一般来说是在做完了需求评审之后,我们已经评审完了需求,知道了要做一个什么样的系统,原创 2023-03-14 21:00:17 · 348 阅读 · 2 评论 -
(十七)需求变更管理
案例式的讲解比如说我们项目干到一半儿了,突然有一天,PM过来找你,这个项目的负责人,他说,有一个XX功能,能不能改一下实现方式,或者修改一下这个功能的运作流程,或者是对这个功能加强一下,比如说有一个查询的功能,商品查询。本来预定的商品查询的条件是4个,商品名称,商品编号,品牌,类别。整个咱们的这个系统和代码,都是按照这个预定义的需求去做的,包括这个功能的代码实现,包括这个功能内部的一些运转流程,包括之前设计好的设计模式,都是针对这个需求来的。结果这个PM跑过来找你说,诶,我发现这个需求好像不太...原创 2023-03-14 21:02:00 · 324 阅读 · 0 评论 -
(十六)风险管理规范
风险管理讲过,项目管理的过程中,一定是会遇到一些风险的。那么有些风险是比较小的,或者没有提前预料。如果没有提前预料到的一些风险,发生了,其实就是在我们每天的站立会里,就会问每个人,执行每项工作,是否遇到了一些问题,那么那些问题就是发生的一些风险。但是对于这种风险的话,一般会通过问题的处理方案和补救措施来解决,那么这样的话呢,我们之前就已经讲解过了这样的一种情况。但是如果每次都是光靠风险发生了,问题都发生了,然后事后我们第二天才知道,才开始想办法去如何解决,采取什么样的对策,那可能有的时候就晚了。因为原创 2023-03-14 21:01:49 · 132 阅读 · 0 评论 -
(十五)项目执行规范
目录1、执行计划2、类百度的站立会制度3、个人周报4、每个人的下周执行计划5、项目周报1、执行计划项目管理的一大重要实践准则:从多年项目的血与火的锤炼中,总结出来的真理和真谛。项目的执行计划,绝对是要在执行的时候,定到非常非常详细的一个颗粒度。务必细化到每个人每天要干什么,每天要干的事情,要写的非常的详细。接下来,做项目执行监控的时候,是完全按照每天的一个粒度,去检查每个人这一天干活儿干的怎么样,事儿干完了没有,有没有什么问题。为下一周执行详细的执行计划,务必非常仔细,细化到原创 2023-03-14 21:01:41 · 254 阅读 · 0 评论 -
(十四)项目计划规范
目录1、活动清单2、网络图3、进度计划(甘特图)4、资源配置表1、活动清单活动清单,一般是每个人对自己负责的那个部分,需要自己在这个表格里填充对应的排期,因为只有自己负责的这个部分,自己是最熟悉的,大概是知道自己要做多长时间的。最终会汇总到一个完整的活动清单中去活动清单汇总完成之后,需要由架构师仔细审查每个人定的活动清单的人/日排期。最主要的是,根据架构师的丰富项目经验,要判断一下,每个人的每个工作,有没有多排期(职场里有很多老油条,是不好好干活的,比如说只要1天可以做完,2天,原创 2023-03-14 20:59:40 · 120 阅读 · 0 评论 -
(十三)线上运维规范
目录1、线上故障反馈群2、线上bug的分级标准3、线上bug反馈的模板4、团队里的值班机制5、定位bug原因6、解决bug7、将bug的完整过程记录到一个bug文档中去8、将bug文档同步给团队里的leader和其他同学线上运维,最基本的一个事情,其实就是说线上系统,如果没有其他的什么技术挑战的话,主要就是出bug。如果出了bug,你怎么来解决,按照什么流程,谁来解决,解决之后,需要记录什么东西下来。线上bug处理的SOPStandard Operation Pr原创 2023-03-14 21:01:20 · 308 阅读 · 0 评论 -
(十二)上线规范
目录一、上线checklist二、上线文档三、执行上线一、上线checklist每个在本次要上线的版本中负责开发的同学,都需要提交自己的上线checklist,最终合并到同一份上线checklist文档中去。上线checklist文档,就是在里面要写清楚每个人负责的那个部分,那个子系统的整个软件工程流程过程中,沉淀下来的所有文档,都需要附加在这份checklist文档中,一般比如说可以用一个word文档,在这个word文档中,附加上你每个过程对应的一个截图和报告。1、各系统的测试报告原创 2023-03-14 21:00:58 · 1053 阅读 · 0 评论 -
(十一)测试规范
(一)单元测试针对的是代码中的每个类,一个类认为是一个代码组件,对每个代码组件都编写一个单元测试类。这个单元测试类中会有多个方法,通常至少对要测试的类中的每个方法都编写一个对应的测试方法。单元测试,面向的是代码组件的级别,它是最小最细粒度的测试单元通常而言,通过单元测试检查出来的bug是最多的,所以它是位于测试金字塔模型的最底端初步的一些规范:(1)单元测试类,必须以test来结尾,以要测试的类来打头(2)针对每个类,一般都要写一个单元测试类来进行测试(3)单元测试中的每个方法原创 2023-03-14 21:00:51 · 304 阅读 · 0 评论 -
(十)编程规范
(一)命名风格【强制】代码中的命名均不能以下划线或美元符号 开始/结束。【强制】代码中的命名严禁使用拼音/中文。【强制】类名使用 UpperCamelCase 风格,必须遵从驼峰形式,但以下情形例外: DO/BO/DTO/VO/AO【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格,必须遵从驼峰形式。【强制】常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。【强制】抽象类命名使用 Abstract 或 Base 开头 ; 异常类命原创 2023-03-14 20:58:50 · 562 阅读 · 0 评论 -
(九)版本控制规范
1、Git工作流初步定的是基于GitFlow工作流来做(1)feature分支进入一个版本的开发之后,每个人自己拉对应的feature分支。feature分支的拉取,按照一个子系统一个feature分支;一个模块一个feature分支;一个需求一个feature分支;一个功能一个feature分支。不是固定死的,是根据当时的人力的任务分配情况,来定,怎么划分这个feature分支。比如说我们现在,假设电商v1.0版本要做15个子系统,1+4的小team...原创 2023-03-14 21:00:37 · 270 阅读 · 0 评论 -
(八)工程初始化规范
1、每个人本地搭建好开发环境(1)JDK(2)开发IDE:eclipse、IntelliJ IDEA(3)maven:配置nexus私服的地址,settings.xml(4)git2、完成资源申请对你的技术架构中,所有需要使用的技术相关的资源进行申请如果是在大公司里面:需要跟对应的dba、redis运维团队、RabbitMQ运维团队,申请你需要使用的数据库、redis集群、RabbitMQ资源还有你的java服务需要部署的机器资源,也需要跟SRE...原创 2023-03-14 20:58:35 · 119 阅读 · 0 评论 -
(七)详细设计评审规范
每个人都完成各自的负责的子系统的详细设计之后,每个人各自要召开自己的详细设计评审会这个详细设计的评审,就不是从其他部门请来一些架构师来评审,人家精力有限,不会给你过那么细节的东西,概要设计评审的时候,给你看看主要的架构的设计详细设计,就落实到具体的细节的层面,主要是靠架构师来对自己的团队内的各个成员的详细设计来进行评审1、数据库设计的评审重点关注一下数据库设计的索引,索引要确保说未来系统中已有的和可能有的各种功能,都可以用到索引,不会出现全表扫描的情况...原创 2023-03-14 21:00:19 · 184 阅读 · 0 评论 -
(六)详细设计规范
1、数据架构设计1.1 数据库ER模型图PowerDesigner ER建模数据库的ER建模,ER,Entity Relationship,实体关系,一个表就是一个实体,设计表与表之间的一个关系,也就是实体与实体之间的一个关系包括每个实体包含哪些属性,表包含了哪些字段一般就是根据需求分析以及概要设计中的内容来考量,就是说负责的这个模块,具体需要哪些数据库表去承载,才能实现出来将所有需要的表,全部在一张ER模型图中体现出来1.2 数据库逻辑...原创 2023-03-14 21:00:05 · 340 阅读 · 0 评论 -
(五)概要设计评审规范
1、要评审的一些点负责评审的同学,需要对架构设计方案,从以下的角度考虑:(1)并发性:考量一下,现有的系统架构,能支撑多高的并发,如果说未来并发持续上升的话,这套架构会不会扛不住(2)伸缩性:考量一下,如果未来系统架构撑不住并发量了 ,现有的这套系统架构,是否是可伸缩的,就是能否在需要的时候,通过加机器,扩容,来增强它能抗住的并发量(3)可用性:现有的这套系统架构,是否可能会出现不可用的情况,比如说某个外部依赖挂掉了,或者是流量激增,等等,会不会有哪些情况导致系统跨掉了(4)扩展性:如果原创 2023-03-14 20:57:54 · 681 阅读 · 0 评论 -
(四)概要设计规范
1、引言1.1 编写目的1.2 面向对象1.3 参考文档2、逻辑架构采用技术栈架构,包含业务架构,以及系统整体技术架构2.1 逻辑架构图没有固定的格式,将整体技术架构画清楚即可2.2 设计细节对架构设计中各个环节进行文字说明3、运行架构3.1 系统核心流程时序图将系统整体的各个核心流程的时序图画出来,子系统之间的交互就很清楚了,要求粒度到每一个用例级别,每个子系统的用例都要在时序图上有所体现...原创 2023-03-14 20:59:32 · 460 阅读 · 0 评论 -
(三)需求分析规范
1、引言1.1 编写目的表明这份需求分析文档的核心目的是什么,比如说是用来定义系统的核心功能的,指导后续的系统设计的1.2 面向对象该文档编写出来之后,是要给谁看的?其实主要是给RD看的,让工程师明白系统要做哪些东西1.3 参考文档(1)需求文档2、概述2.1 开发意图描述清楚咱们这个系统开发出来是用来干嘛的,主要的作用是什么2.2 功能结构图2.3 功能简介2.3.1 XX子系统...原创 2023-03-14 20:59:18 · 250 阅读 · 0 评论 -
(二)需求评审规范
目录需求是否足够清晰对需求中不合理的地方提出改进建议对不需要做的需求提议砍掉需求是否足够清晰要判断这个需求,你看了以后,是否脑子里能完全展现出来整体的图,就是包括界面是怎么操作的,在界面上用户的操作流程是什么样子的?每一步操作,要显示什么表单、什么表格?查询条件的默认值?是否要分页? 原则,你必须要看了需求以后,脑子里直接出来一个产品的界面操作图,然后后台系统的一些流程,基本都出来了。对需求中不合理的地方提出改进建议查询菜单,是默认就查询两级,或者是三级,但是我们考虑到了可能有原创 2023-03-14 20:58:58 · 1186 阅读 · 0 评论 -
(一)软件开发流程与图
软件工程与图原创 2023-03-14 20:58:40 · 2152 阅读 · 0 评论