第一章 初识软件工程
学好每一门科目是我给自己最基本的要求，大学三年我在努力让我的每门成绩达到90分以上，甚至100分哈哈哈 ， 很高兴我基本上都按计划完成了。所以初识软件工程，我想知道学好软件工程需要什么样的基础？如果我的基础还不够，那我继续去学。
迄今为止，我会的语言也只不过是JAVA、C和一点点 C++，之前自学时发现网课里都是用的python，我不是不想学习新的语言，我只是想知道其他语言会不会更容易上手软件工程。
现在我已经大三了，如果不出意外我是会继续深造读研，我在对研究生专业的选择有点迷茫，因此想了解一下软件工程的前景。
由于时间或者其他因素的影响，有时候我们可能无法顾及所有方面。因此在软件开发中，在有限的时间内，我们应该更注重哪个方面？
想了解维护成本这么高的原因，然后看能不能降低维护成本。
456其实是连续的问题，我在百度静态代码检查时看到别人提出的，但是并未看到准确的回答。
单元测试是对软件中的最小单元进行测试和验证，通俗来讲就是代码中的一个函数或一个类，单元测试一定是白盒测试。
输入：被测试函数的输入参数、被测试函数需要的全局变量、被测试函数的内部私有变量、函数内部调用子函数的数据、函数内部调用其他模块的数据、函数内部调用外部服务的数据等。
输出：被测函数的返回值、被测试函数的输出参数、被测试函数修改的全局变量、被测试函数修改的内部变量、被测试函数增删改的数据库数据等、被测试函数进行的文件更新、被测试函数进行的消息队列的更新等。
并不是所有的项目都适合进行单元测试，即使进行单元测试，也应该是一些基础底层模块或者核心模块进行单元测试；
选择合适的单元测试框架，Java中的TestNG、JUnit，Python中的Unittest、Pytest，PHP中的PHPUnit；
将单元测试集成到CI流程当中。
它提出了软件开发的系统化的、顺序的方法。其流程从系统开始，随后是需求分析、设计、编码、测试、支持。这种模型是最早也是应用最广泛的软件过程模型(虽然这种模型会引起“堵赛状态”)。
优点：1.它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。2.虽然有不少缺陷但比在软件开发中随意的状态要好得多。
缺点：1.实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。2.经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎具有二义性问题存在的。3.客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的。4.采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去，有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。
适用范围：1. 用户的需求非常清楚全面，且在开发过程中没有或很少变化。2. 开发人员对软件的应用领域很熟悉。3. 用户的使用环境非常稳定。4. 开发工作对用户参与的要求很低。
显著特点：按工序将问题化简，将功能的实现与设计分开，便于分工协作。
1.P（Plan）软件规格说明
2.D(Do)软件开发
3.C(Check)软件确认
4A(Action)软件演进
1.易理解性
2.可见性
3.可支持性
4.可接受性
5.可靠性
6.健壮性
7.可维护性
8.速度
优点：敏捷确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品。敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。
缺点：但敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题。
适用范围：1.项目团队的人数不能太多.。2.项目经常发生变更。3.高风险的项目实施。4.开发人员可以参与决策。
1.迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短，通常为一到六周。
2.增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。
3.开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。
4.持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。
5.开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。
1.冲刺计划会议：
团队完成计划会议的这两个部分之后，即已完成以下工作：
创建了冲刺 (sprint) 积压工作，并确定了每个用户情景的任务和工时
承诺完成将在该冲刺 (sprint) 中交付的用户情景
作为一个自我组织的团队，了解应如何协作以履行其承诺。
2.每日Scrum会议：
Scrum 主管严格控制会议结构，确保会议准时开始并在 15 分钟或更短时间内结束。 在此会议中，每个团队成员都需要回答以下三个问题：
自上次 Scrum 以来我完成了哪些工作？
至下次 Scrum 之前我将完成哪些工作？
哪些阻碍性问题或障碍可能影响我的工作？
3.冲刺 (sprint) 评审会议：
在冲刺 (sprint) 的最后一天，团队将与产品所有者、客户和利益干系人召开会议，对已完成的工作进行验收并确定新的要求。 在冲刺 (sprint) 的过程中，团队可能已收集并合并了反馈。 此外，团队应已对每个完成的用户情景执行验收测试。 在该会议中，团队演示了在冲刺 (sprint) 中完成的每个用户情景。 产品所有者、客户和利益干系人对达到预期的用户情景进行验收。 在许多情况下，客户在观看演示后会更全面地了解其附加需求，并将确定和讨论他们所需的更改。
根据此会议，一些用户情景将会作为已完成的工作进行验收。 未完成的用户情景将保留在产品积压工作中，并且新的用户情景将添加到产品积压工作中。 将对这两组情景进行分级，并将在下一次冲刺 (sprint) 规划会议中进行评估或重新评估。
在此会议及追溯会议后，团队将会计划下一个冲刺 (sprint)。 因为业务需求变化很快，所以可利用此次与产品所有者、客户和利益干系人召开的会议，再次评审产品积压工作的优先级别。
4.追溯会议：
在此会议中，团队将审视和检查它在 Scrum 过程中的工作历程。 根据此分析，团队可以决定调整其过程，以便提高其自身的有效性、效率、质量和满意度。 此会议和取得的改进成果对自律行为的敏捷原则非常关键。
如果您的团队未完成指派给冲刺 (sprint) 的所有用户情景，您将在追溯会议中讨论其原因。 团队将确定是否会调整其过程，以降低出现此类问题的可能性。 此外，还需对影响团队整体有效性、效率、质量和团队对项目的满意度的问题展开讨论。
1.云端部署效率工具：
Cloud Toolkit 是一款 IDE插件，可以帮助开发者更高效地开发、测试、诊断并部署应用。借助这个工具，开发者能够方便地将本地应用一键部署到任意机器，或 ECS、EDAS、Kubernetes，并支持高效执行终端命令和 SQL 等。点此了解详情。
2.MacOS 搜索利器：
MacOS 自带的聚焦搜索（Spotlight），可以将文稿、邮件、应用等整合在一起，通过关键词匹配来进行搜索。Alfred 可以看作是Spotlight的增强版，是计算机依赖者的效率神器，支持添加自定义网络搜索引擎，指定规则精准定位本地文件，以及在命令框内使用计算器、词典等实用工具。
3.画图效率工具：
系统架构图是为了抽象的表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。通过架构图，可以让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体，所谓一图胜千言。点此了解详情。
4.JSON 浏览效率插件：
对于 JSON 的数据，如果不编排，格式查看起来会很费劲。JSON-handle 是一款对 JSON 格式的内容进行浏览和编辑，以树形图样式展现 JSON 文档的插件，支持实时编辑。
5.Java 代码规约扫描效率插件：
这是一款 Java 代码规约扫描工具，旨在以工具的手段进行代码规约的落地，项目包含三部分：PMD规则实现、IntelliJ IDEA 插件、Eclipse 插件，帮助开发人员在工程研发的多个阶段进行代码规约检查， 降低故障率、提升编码效率和质量。点此了解详情。
作为一个技术经理或研发经理配合项目经理进行软件开发团队的管理，那需要和项目经理规划好开发工作的重点工作任务计划，落实到责任人，然后结合PDCA的方法去进行管理：P=Plan：做好开发工作重点工作计划D=Do：按计划执行工作任务C=Check：检查当前工作任务完成情况如何，外界环境变化情况，目前的计划、资源是否需要调整？A=Action：前期计划、执行过程中遇到了什么问题？能否总结提炼一些标准化的方法，应用到软件开发团队中？经过PDCA不断的循环，软件开发团队打磨得也会越来越高效。最后一点，所有的软件开发团队都是为业务进行服务，所以在方向上一定不能错，带好开发团队一定要和业务方向的人多沟通，做好随时调整团队的工作重点准备。
团队管理最重要的是：沟通、协调、执行、目标、合作
团队是由员工和管理层组成的一个共同体，有共同理想目标，愿意共同承担责任，共享荣辱，在团队发展过程中，经过长期的学习、磨合、调整和创新，形成主动、高效、合作且有创意的团体，解决问题，达到共同的目标。
产品规划：在平台中进行产品结构设计，完成产品定义，业务模块定义， 发布定义（可以是安装盘形式，也可以其他某种形式如war包）
开发设计：完成开发模块定义、开发模块与业务模块关系定义
初始配置：代码配置库的建立，可以按开发模块建库。
持续集成：集成构造、集成打包、集成测试、集成做盘（生成安装宝过程）、安装部署、系统测试
版本发布：根据测试结果和发布评估后，可以直接在集成版本库中提取，最后的安装盘进行发布
补丁发布：根据每次集成过程的代码提交信息获取获取需求或缺陷列表， 通过集成状态结果可以清晰的指到那个需求已经被集成，在那个版本的安装盘中，是否被测试通过等等信息。 根据这些信息选择要打入补丁的需求，根据需求id查找代码提交事件id，根据事件id找到文件变更信息。 依次就可以打出一个比较完成的补丁包，并可以附加上所有集成和验证的信息。
精确要求，精准成果。敏捷开发不似瀑布模式的开发，从一个点开始却会以一大片结束。这样的开发会导致成果与出发点严重偏离，重点无法被作为重点开发出来，而是与原来的构想相差甚远。敏捷开发似接力比赛，每一段赛道都不长，并且还能把握好每次交接棒的时机，遵循计划更响应变化，这使成果变得十分精准。
质量有保障。敏捷方法对每一次迭代周期的质量都有严格要求。敏捷开发团队拥有高水平的开发方法，有的会在正式开发功能代码之前先开发该功能的测试代码，质量可保证。
客户合作胜过合同谈判。好的团队会更在乎与客户合作的这个过程。
投资回报率高。在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。
较高的速度是敏捷开发最显著的优点之一。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。
工作在小的团队中
团队是跨功能的-包括测试人员，开发人员，文档开发人员等等
短迭代-利用短迭代方法来交付软件
相较于文档，敏捷开发更注重面对面的交流
敏捷不是一个过程，而是一个软件开发的形式或者方法
敏捷可以与软件过程如CMMI等一起实施
1．开发高层的业务模型
所谓应用领域，即目标系统的应用环境，如银行、电信公司等。如果系统分析员对该领域有了充分了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求。然后通过迭代，更深入地了解应用领域，之后再对业模型进行改进。
2．定义项目范围和高层需求
在项目开始之前，应当在所有利益相关方面建立一个共同的愿景，即定义项目范围和高层需求。项目范同描述系统的边界以眨与外部事物(包括组织、人、硬件设备、其他软件等)的关系。高层需求不涉及过多的细节，主要表示系统需求的概貌。
3．识别用户类和用户代表
需求获取的主要目标是理解用户需求，因而客户的参与是生产出优质软件的关键因素。因此，首先确定目标系统的不同用户类型；然后挑选出每一类用户和其他利益相关方的代表，并与他们一起工作；最后确定谁是项目需求的决策者。
用户类可以是人，也可以是与系统打交道的其他应用程序或硬件部件。如果是其他应用程序或硬件部件，则需要以熟悉这此系统或硬件的人员作为用户代表。
4．获取具体的需求
确定了项目范围和高层需求，并确定了用户类及用户代表后，就需要获取更具体、完整和详细的需求。
5．确定目标系统的业务工作流
具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则。采取需求调研的方法获取所需的信息。例如，针对信息系统的需求调研方法如下。
(1)调研用户的组织结构、岗位设置、职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。
(2)调研每个子系统的工作流程、功能与处理规则，收集原始信息资料。用数据流来表示物流、资金流、信息流三者的关系。
(3)时凋研内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个需求的层次。
6．需求整理与总结
必须对上面步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求等。
需求获取、需求分析、需求定义、需求验证。
通过调查与分析，获取用户需求并定义产品需求。