软件开发流程知识概括

软件开发流程知识概括

• 软件开发流程简述
• 开发流程详解
• 软件开发流程涉及的图
• 软件开发总结

软件开发流程简述

研发流程简述：

研发流程详解：

• ①这个环节主要是产品爸爸给我们提需求，每个需求都是他们从用户，或者自己绞尽脑汁想出来的，但是产品爸爸还拿不准，不能直接敲定，所以就需要我们大家（产品，UI，前端，后端，客户端和测试）一起讨论一下，看看这个需求是否合理，或者这个需求是否有意义，能否达到预期，技术实现的成本，周期等等。
• ①这个阶段，产品爸爸会根据第一版聊下来的结果，大致出一个Demo版本的PRD，会画出初版的原型图，并且配上文字说明，所有涉及到的业务，还有交互细节都会罗列出来。
  ②这个时候大家又会围绕这一版本去开会讨论，敲定细节，这个环节会久点，因为细节比较认真，逻辑也不能出错，还有UI稿子也得敲定，这里如果不敲定逻辑，UI提前去画原型图，后面假如逻辑推翻，一切重来就会浪费大量时间。这一环节大家都会把细节问清楚，不了解的点也会去了解，测试，开发，UI我们都会在会议上提出自己的观点，自己的意见，然后等产品反馈，最后意见一致之后，产品当天就回改出敲定版本。UI就会按照产品爸爸的意思去作图，接下来就是交互设计评审了。
• ①UI会画出客户端，前端，H5开发所需要的UI图，基本上就是我们看到的产品的样子了，不过还是要敲定细节，比如按钮合理不，或者上面数据是否在这展示，或者这里展示的数据是否合理。这个环节会比较快，只要UI按照之前敲定的逻辑开发，出入不会很大，一般都是小改。
• ①这个是大厂程序员需求下来之后基本上都会做的一步，不过看需求大小，可能很多小需求直接就详细设计了，也有啥设计都不用做的小改动，具体需求具体分析嘛。很多不了解的同学可能会问，需要设计什么呢什么要设计呢术是把双刃剑，你用了技术之后你是不是需要列出他的优点缺点，出问题之后的解决方案，还有可能出现的问题，注意点等等。这么是为了让你能有把控力，比如你这个需求接入了新技术Es（Elasticsearch）你什么都不管你就是要接入它，你把他开发好了上线了，但是有啥坑你知道么线崩了怎么办br> ②这个环节你需要考虑这个需求涉及到哪些服务了，需要新增哪些接口，修改哪些接口，表有现场的还是要新建表，字段要新建么实远远不止这些问题，这就是我们做设计的主要原因，也是大家工作里面能成长的途径之一，你以为大佬们的经验是怎么来的/li>
• ①我们研发的时候整个流程往往很复杂，如果你理解不对直接就写代码，最后容易造成返工。花点时间做详细设计很有必要，你思路完全清晰了，写代码那就是分分钟的事情。
  ②涉及的都是流程图，时序图等等。
• ①测试会根据你的概要设计，评估你的影响范围，你的影响点，新增和改动的接口啥的，去编写自己的测试用例。测试用例，主要是为了把改动点影响点都考虑到，测全一点，免得上线了影响别的现有业务，也是为了把你开发的功能可能出现的bug给排除了。
• ①啥都敲定了，那就开发呗，开发差不多了，就得前后端联调了。这里有个小细节还是想说一下，一般开发前我们都会提前定义数据类型，接口名称，然后在公司的接口工具上给出链接和参数，方便前端爸爸mock数据。他总不能等我们后端开发完了，才去开发嘛，这样效率打折扣，所以都是后端先定义好，然后前后端并行开发的。
  ②后端开发好，一般都是会发布到联调环境，我们有哪些环境，联调环境在我们所有的环境中处于哪个地位呢br>
• 业务分析，主要处理的是业务领域的建模。解决的问题是业务上如何实现。然后是技术与架构方面的设计，主要针对的是技术实现，解决的问题是技术上如何实现。这两个方面是会互相影响的，设计的时候往往需要来来回回的考虑这两个方面。甚至系统开发时也时常会需要调整模型或者架构，当然相应的也需要更新文档。
  
  ②以特定的图形符号加上说明，表示算法的图，称为流程图
  
  ②系统架构图是为了抽象的表示软件系统的整体系统框架、各个组件之间的相互关系，以及软件系统的演进方向的视图。通常来说，我们绘制架构图的目的就是为了解决团队之间的沟通障碍，通过架构图很便捷的其他成员进行沟通，减少歧义，最终让整个团队成员能够达成共识。。系统架构图最经典的是4+1视图，分别为场景视图、逻辑视图、物理视图、处理流程视图和开发视图。
  
  ②状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。
  

总结：

• 活动图和时序图到底有什么区别啊br> ①二者都是为了描述系统的动态变化，侧重点不同。通俗点说活动图侧重的是整个活动的流程次序，也就是我们说的流程图（一个流程的确是活动的集合）。而时序图（也叫顺序图）体现的是对象之间的消息的次序关系，看出来了，时序图反映的重点是消息的时序，而活动图侧重的是整个流程。
  ②设计的时候，为了说明问题，可能二者都需要。很多时候画出来相似，但是反映和表达的意思不一致。
  ③时序图主要强调时间的顺序，活动图主要强调空间上类的交互。

• 因此活动图可以分为：
  ①
  

  

• uml图有很多个，它就像一个工具箱，我们开发系统并不需要用上全部的工具，这里只要介绍最重要的几个，使用这几个完全可以描述整个软件开发过程，用以下那几个图，足够描述一个软件系统了，其他不学也无所谓。
  ①用例图：可以用于描述组织的业务用例，也可以用于描述系统的用例。
  ②：可以用于描述组织业务的实现过程。也可以用于描述系统用例的实现过程。
  ③状态机图：用于描述系统类的状态，以及状态之间的转移
  ④类图：用于描述系统的组成以及他们之间的关系。
  ⑤：系统架构图是为了抽象的表示软件系统的整体系统框架、各个组件之间的相互关系，以及软件系统的演进方向的视图。
  系统组件图：用于描述系统组件的划分。
  系统部署图：用于描述系统组件的部署结构。

• 网络拓扑图与系统架构图：对于it系统，结构图和系统图基本相似，显示了系统各个组件之间的关系。

软件开发总结

简述：

• 链接：面向对象分析、设计、实现
• 真正的对象：
  ①我所理解的真正的对象就是现实生活中客观存在或不存在的真正的对象。这个对象有一个明显的特征就是它具有非常多的状态特征和行为特征。比如一个人是一个对象，他在一生中会经历无数个交互场景，在这个过程中，每个人的行为特征会不断增多，大部分行为是通过后天学习得到的，只有少数行为是先天就具有的；另一方面，对于状态特征也是在时不时的变化，比如你的身高、体重，等等。最后，人因为会参与到不同的交互场景，会导致和他关联的各种关联信息也会不断增多，比如你去上大学，老师给你一张借书卡，此时你就拥有了一张借书卡，可以理解为你多了一个关联信息；哪一天你去参加英语四级考试，考了70分，然后你拥有了一本四级考试证书，上面写这成绩为70分，此时你也同样多了一个关联信息，就是一本英语四级考试证书；
  ②这里我想表达的主要观点是：现实生活中的对象：
  1）兼具各种场景下的所有状态和行为特征；
  2）固有状态会时不时的变化，通过参与交互场景还会增加一些关联信息；
  3）行为会不断增多，一般是通过学习得到；因此，我们从中可以知道，现实生活中的对象肯定不是我们设计软件时候的对象，因为它是如此的复杂，包含了或关联了非常多的状态特征和行为特征；
• 面向对象分析阶段时的对象：
  ①既然是分析阶段，那我们就不要过多的考虑任何设计阶段的思想。我觉得在分析阶段，我们在分析对象时主要考虑两个方面：
  1）对象的状态特征变化规律；
  2）对象的行为特征变化规律；
  ②分析阶段，我们往往从某个场景出发，分析该场景中有哪些“对象”，此时的“对象”之所以加双引号是因为它不是真正的对象，而是真正的对象的某个方面，我们在某个场景下只关心对象的某个方面；我觉得分析阶段的对象和现实生活中的对象应该是一致的，或者至少是逻辑上是一致的。也就是说，在面向对象的分析阶段，我们应该将现实生活中我们所理解的对象的一切特征在脑子里描述清楚。比如同一个人，它在不同的场景下（一个场景代表了一个考虑问题的边界）会参与不同的交互活动。 这句话体现的含义是：
  1）同一个对象会参与不同的场景，行驶各种交互行为；
  2）同一个对象我们会根据我们不同的认识角度，对同一个对象的关注角度的不同，将其理解为不同的类型或角色；比如一个人，在家里可能是父亲，在公司可能是职员，在比赛场上可能是运动员。但无论我们给这个人授予什么样的称谓，这个人始终是同一个对象。所以，在面向对象的分析阶段，对象给我们的感觉是它在不停的变换其类型或角色；上面在谈到什么是真正的现实生活中的对象时提到，对象在参与到交互活动后会多出一些关联信息，这些信息是属于谁的呢案是：这些信息属于扮演了某个角色的对象的；之所以强调扮演了某个角色，是因为想让大家明确对象一定是在扮演某个角色参与到某个场景交互活动后才具有那些关联信息的。
  ③总结：我觉得在面向对象的分析阶段，我们分析的要点是：
  1）站在现实生活中真正的对象的角度去理解对象的状态特征和行为特征的变化规律；
  2）理解真正的对象和对象的某一个方面（即我们所关心的“对象”），
  3）理解同一个对象会扮演不同角色参与到不同交互场景；
  4）理解对象的关联信息如何产生，关联信息是属于谁的；
• 面向对象设计阶段时的对象：
  ①首先说一下，目前的编程语言实现对象时，是以哪些方式让创建对象的。
  1）C#等基于类型的静态语言，类型规定了对象可以具有的状态特征和行为特征，对象的一切状态和行为都是由其所属的类型确定的；这又一个很明显的好处时，我们在任何时候都知道对象的类型或接口，从而就能明确知道其数据结构，也就知道对象的状态，从而可以方便的持久化对象的状态或者重建对象；但这种为对象带来状态和行为特征的设计思路同时也有一个缺点就是对象的类型或其表现出来的接口无法更改。这点是违背“真正的对象”或者“分析阶段的对象”的特征的；
  2）javascript等弱类型的动态语言，这种语言认为对象无类型，对象的状态和行为不需要从类型为模板获取，状态和行为可以随时附加到某个对象上。这种思路其实很好，因为很符合上面提到的真正的对象的状态特征与行为特征的变化规律。但是这种语言也有一些致命的缺点：
  1）由于没有类型，导致无法在使用时明确知道其具有哪些状态和行为，这会增加编程出错的可能性，只有在运行阶段在会检测到访问了不存在的状态或行为；
  2）同样是弱类型的原因，对象无法被持久化，因为不知道要持久化哪些状态，同样，更不用说重建对象了；所以，基于这两个缺点，我觉得动态语言不适合在服务器端大量使用去做工程实现业务逻辑，而在一些不需要持久化对象状态的客户端环境，只在内存中处理逻辑的情况下使用这种语言比较适合；
  ②当我们在设计软件时，如果是用C#等静态语言、基于类和接口的语言去设计对象时，该如何设计呢设计阶段，我觉得目标就是把分析阶段得到的对象用尽量平滑的方式转换为设计；需要把握的要点是：
  1）从一个基本的类创建出对象；
  2）用尽量平滑的设计思路去支持一个对象表现出不同类型或角色的特点；举个例子吧：
  3）xuehua这个对象首先是一个人，所以从Person这个基本类型中获取基本的状态特征和行为特征（如吃饭）；然后当xuehua去教书时，他会扮演教师的角色，扮演之后他就是一个教师了，然后他就具有了教师这个角色所赋予的行为（教书）了。上面的代码看上去和真正的对象在现实生活中的变化规律类似，非常平滑；这样做有几个好处：1）强类型；2）对象交互模型与现实生活中的交互模型完全一致，所以代码非常容易懂，可读性强；3）对象不会随着参与交互场景的增多而变得臃肿和复杂，因为由于引入了角色的概念，我们将交互模型实现为对象扮演某个角色参与交互活动的方式来设计，做到了对象动态被赋予身份，从而具有与该身份相关的状态特征和行为特征；4）对象参与交互场景后所关联的一些关联信息不会直接存放在对象上，而是放在了“扮演了某个角色的对象”上，在上面的例子中就是teacher对象；

• 面向对象实现阶段时的对象：
  ①那么如何实现这样的设计呢br> var teacher = xuehua.ActAs();
  ②其实很简单，可以类用装饰模式来实现，我们都知道，设计模式中的装饰模式可以动态给一个对象增加状态或行为。所以在实现阶段，我们可以设计一个Teacher类，大概设计如下：
  teacher就是实现阶段的对象，而Teacher类则是实现阶段的对象的类型；可以看到Teacher类关联了一个Person对象，同时实现了ITeacher角色接口。所以ActAs，
  var teacher = xuehua.ActAs();
  这个函数做的事情就是在内部创建一个Teacher类的实例，该实例对当前的Person对象有一个引用，然后返回。也许你会说，返回回来的teacher对象已经不是原来的xuehua对象了，而是一个新的对象，并且封装了xuehua这个对象；没错，所以说这是实现上的问题。我们在关注业务时，关心的不是当前对象的真正类型，而是关心对象的状态特征、行为特征，或者技术化一点来讲就是关心对象的交互模型，关心的是对象扮演什么角色在进行交互。

来源：GeorgeLin98