软件工程-提出问题、回答问题

一、提出问题

快速通读教材《构建之法》，并参照一中提问模板，提出3个问题。

1. 为什么单元测试必须由最熟悉代码的人（程序的作者来写）？

我看了一段文字

代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更合适的人选了。
——《构建之法》p25

通过这段文字，我有个问题：
代码的作者能想到的测试用例代码可能都已经改进优化了，对那些测试的容错性较好，所以最合适的测试人员是否应该是对代码大概有了解，而有自己的新测试用例想法的人

我查了资料，发现：

单元测试一般是有开发人员或测试人员来做。谁来做并没有一个绝对的标准，要根据公司的实际情况来决定。

开发人员做单元测试：
优点：开发人员对代码最熟悉，而且开发人员编程技能相对比较强，所以开发人员自己写单元测试效率上和覆盖率上都比较高
缺点：开发人员平时写业务代码就要花费很多时间，有时候确实没有时间写单元测试；而且大部分开发人员没有太好的测试思想，单元测试可能只是写个最简单的用例就完了；自己写的代码自己测，往往都是不靠谱！

测试人员做单元测试：
优点：测试人员有比较系统的测试思想，可以更好地保证用例的覆盖。而且通过写单测测试能更好地了解具体代码结构、流程，对于后续的业务测试也非常有利。
缺点：测试人员的编程技能相对比较弱，如果不同编程是无法开展单元测试的。并且测试人员对代码没有开发人员熟悉，效率会比较低。

原来还有专门的测试人员，我觉得测试人员做测试更合理一些，但书上为什么说写单元测试没有比作者更合适的人选了？

2.测试人员地位为什么在团队中未被足够重视？

软件团队中还有一个重要的角色：测试。
测试人员在一个冲刺中怎么工作呢？有敏捷专家建议测试人员可以担负起产品负责人的部分责任，同时掌握验收测试流程，对产品的最终质量负责。但是测试人员的开发技术能力在团队中并不占优（在有些中国公司中甚至是最弱的一环），他们在大家都要“烧光”所有任务的压力下，能担当起产品负责人这一责任么？
——《构建之法》p115

我提出一个问题：测试人员地位为什么在团队中未被足够重视？那么测试人员能否担当起产品负责人这一责任？
通过查找资料得知：

1. 无论是否熟悉互联网公司团队合作模式，相比产品人员、开发人员，测试人员工作往往由于处于项目的中后期，而产生了这样一个印象：

没有产品人员/开发人员，根本出不了产品；而没有测试人员，大概也是可以的。

2. 对于产品层面的直观印象是:

你的团队有测试人员，用户/其他人员不会觉得你的产品好牛逼；
但你的团队没有测试人员，用户/其他人员会觉得你的产品好 low。

3. 测试人员缺少强有力的数据支撑自己的重要性：

现在几乎所有大中小型公司，考核测试人员的指标都越来越偏向于开发能力了。如果测试人员能开发出一个测试工具/平台，彰显自己的开发能力，不仅可以通过分享、工具推广来增加自己的影响力，更可以在晋升答辩中获得优势；

而对于产品层面的直接影响，缺少类似开发能力这么明显的衡量标准。除非负责的产品直接有关收入、用户量等指标，而测试人员又恰恰新提了一个方案，增加了收入、用户量等（当然这种机会实在是千年难遇，毕竟 90% 的产品可能非人为可以控制）；而实际项目往往面临的是下面的场景：

测试人员对产品层面进行了种种优化建议/改进，但除了多一些 bug 外，似乎也没有多少有力证据来证明测试人员对产品层面的影响。

没测试团队不意味着测试没必要,测试总是需要的，没专职团队承担，工作量必然(部分)沉降到开发或者产品，他们不是专职，工作回馈不具有连续性;用他们的时间来测试不是对团队时间的有效利用，产品的精力应该放在产品本身的定义上，开发应该专注更好的实现

因此测试人员地位在团队中未被足够重。
那么测试人员能否担当起产品负责人这一责任？

3.CMMI（能力成熟度模型集成）是什么？

我看了一段文字：

既然软件工程的质量对最终软件的质量有举足轻重的意义，人们当然希望衡量一下各个机构的软件工程质量究竟如何，其中一套比较成熟的理论是CMMI（Capacity Maturity Model Integrated，能力成熟度模型集成。
——《构建之法》p306

书中没有详细讲解CMMI，那么CMMI到底是什么呢？

通过网上资料我得知：

CMMI来源于业界的最佳实践。通过从业界收集的最佳实践进行分析，发现其中对项目开发的成功能起到至关重要作用的实践，再将这些实践进行整理后命名为过程域(PA)，这些实践按相关性可以分为过程管理，项目管理，工程，支撑四个领域，为组织在不同领域的改进提供指导。

另一方面，通过对不同项目实践分析，发现实施不同的实践组合和次序会带来不同的结果。例如，如果没有良好的项目管理，项目就不能有效的执行，那么项目管理是项目能够成功的基础，所以首先要实施项目管理的相关实践。通过几个项目的成功实施后，发现还有除了项目管理，工程技术方面的实践也对项目的成功至关重要，于是将这个过程固化下来，这样就形成了组织标准开发过程，是一个组织成熟的表现。

CMMI将过程能力分成了5个成熟度等级，也就是常说的初始级，已管理级，已定义级，定量管理级和优化级，在CMMI中叫阶段式表示法，也叫成熟度等级。CMMI模型认为具有不同成熟度的研发组织具有不同的过程能力，拥有不同的研发和管理能力，也就是项目能够成功的能力。成熟度等级为组织级改进提供了一个预定义的路线图。还有一种连续型表示法，是支持单个过程域的改进方式，组织可以根据自身的情况，选择某个特定的过程域进行实施，以提升和改进组织在某一特定领域的能力，这叫能力等级。选择哪种方式作为改进方式，需要依据组织自身情况来确定。

回到了CMMI是什么的问题上，从这里可以看出， CMMI是一个模型，是实践，它不是标准，也不是流程，所以它并不会告诉你具体要怎么做。它给我们提供了一个框架，一个可预期的改进线路图。

为什么要集成?

CMMI与CMM是什么关系，有什么不同?

仅从字面上看只差了一个“I”，Integration集成。这不是CMMI与CMM的唯一区别，但却是一个很大的改变，为什么要集成呢？

随着软件领域的CMM的推出和在业界的成功应用。许多其他学科和国际组织开始模仿CMM的方式推出自己的模型，例如系统工程领域的SE-CMM，采购领域的SS-CM，人力管理方面的People CMM等。就像这张关系图所示，这些模型、标准的关系也是极其复杂的。试想，如果在一个组织中使用这些模型会是一个什么样的情形：不同领域、不同部门的人说着不一样的“语言”，工作的方式和标准也不一样，彼此间难以交流。

就像在《圣经》巴别塔的故事中，由于上帝改变了人类的语言，使得人际交流困难，最终导致巴别塔的修建失败。而在过程改进的现代版故事中，为了适用于各种开发学科，人们创建了不同的过程改进模型，开发了多种开发语言，和巴别塔的故事一样，这种多样性对沟通会产生不利影响。CMMI就是用来改变这种情况，通过提供一种单一的“语言”，使多学科能够共享改进活动，并关注一个统一的过程改进目标。

二、回答问题

1.编写功能复杂的程序会遇到哪些问题？

• 难以管理复杂的代码结构和模块之间的依赖关系。
• 需要处理大量的数据和算法，容易引发性能问题和内存泄漏。
• 难以保证程序的稳定性和可靠性，容易出现bug和难以调试的问题。
• 需要处理大量的复杂业务逻辑，容易导致程序设计不合理和维护困难。

通过网上查找资料，列出十个规范：

1. 遵循单一职责原则

函数是程序员的工具中最重要的抽象形式。它们能更多地被重复使用，需要编写的代码就越少，代码也因此变得更可靠。较小的函数遵循单一职责原则更有可能被重复使用。

2. 尽量减少共享状态

应该尽量减少函数之间的隐式共享状态，无论它是文件作用域的变量还是对象的成员字段，这有利于明确要求把值作为参数。当能明确地显示函数需要什么才可以产生所需的结果时，代码会变得更容易理解和重用。
对此的一个推论是，在一个对象中，相对于成员变量，更应该优先选择静态的无状态变量 (static stateless variables)。

3. 将“副作用”局部化

理想的副作用（例如：打印到控制台、日志记录、更改全局状态、文件系统操作等）应该被放置到单独的模块中，而不是散布在整个代码里面。函数中的一些“副作用”功能往往违反了单一职责原则。

4. 优先使用不变的对象

如果一个对象的状态在其构造函数中仅被设置一次，并且从不再次更改，则调试会变得更加容易，因为只要构造正确就能保持有效。这也是降低软件项目复杂性的最简单方法之一。

5. 接口高于类

接收接口的函数（或 C++ 中的模板参数和概念）比在类上运行的函数更具可重用性。

6. 对模块应用良好的原则

寻找机会将软件项目分解成更小的模块（例如库和应用程序），以促进模块级别的重用。对于模块，应该遵循的一些关键原则是：

• 尽可能减少依赖
• 每个项目应该有一个明确的职责
• 不要重复自身
• 你应该努力使你的项目保持小巧和明确。

7. 避免继承

在面向对象编程中，继承 —— 特别是和虚拟函数结合使用时，在可重用性方面往往是一条死胡同。我很少有成功的使用或编写重载类的库的经历。

8. 将测试作为设计和开发的一部分

开始编码时先编写测试代码会使得代码十分自然地遵循许多指导原则。这也有助于尽早发现错误。不过要注意避免编写无用的测试，良好的编码实践意味着更高级别的测试（例如单元测试中的集成测试或特征测试）在揭示缺陷方面更有效。

9. 优先使用标准的库

我经常看到更好版本的 std::vector或 std::string ，但这几乎总是浪费时间和精力。一个明显的事实是 —— 你正在为一个新的地方引入 bug，其他开发者也不太可能重用你的代码，因为没有被广泛理解、支持和测试。

10. 避免编写新的代码

这是每个程序员都应遵循的最重要的教诲：最好的代码就是还没写的代码。你写的代码越多，你将遇到的问题就越多，查找和修复错误就越困难。
在写一行代码之前先问一问自己，有没有一个工具、函数或者库已经实现了你所需要的功能？你真的需要自己实现这个功能，而不是调用一个已经存在的功能吗？

2、何为开源软件？它与闭源软件有何本质区别？开源软件有何价值？

• 开源软件是指其源代码是公开可获取、可查看、可修改和可重新发布的软件。
• 闭源软件是指其源代码被保密或专有的软件。

开源软件与闭源软件的本质区别在于开源软件的源代码是公开的，任何人都可以查看、修改和重新发布；而闭源软件的源代码是私有的，只有软件开发者可以查看和修改。

开源软件的价值在于：

• 促进了技术的共享和交流，有利于技术的快速发展。
• 提高了软件的安全性和稳定性，因为有更多人参与审查和改进。
• 降低了软件开发和维护的成本，能够更快速地响应用户需求和问题。

选择开源或闭源软件通常取决于具体需求和情境。有时候，混合模式也可能是一个选择，其中开源和闭源软件结合以获得最佳的灵活性和支持。

3、高质量的软件有和特点？需要满足哪些方面的要求？

高质量的软件通常具有以下特点：

• 功能完备、易用性强、性能优越。
• 稳定可靠、安全性高、易于维护和扩展。
• 良好的用户体验、界面友好、符合用户期望。
• 支持和服务：好的软件开发团队需要提供良好的支持和服务。
  (包括软件的更新升级、问题解决、客户服务等方面。)

为了满足高质量软件的要求，软件需要在以下要求：

• 充分理解用户需求，设计合理的架构和功能。
• 遵循良好的编程规范和设计原则，编写可读性高且易于维护的代码。
• 进行全面的测试，确保软件的功能符合规格，性能稳定。

git小记

基础语法：

#创建gitTraining目录
mkdir gitTraining
#进入gitTraining目录
cd gitTraining
#将gitTraining初始化为一个本地仓库
git init
## #创建helloGit.txt
touch helloGit.txt
#将helloGit.txt添加到暂存区
git add helloGit.txt
#提交helloGit.txt至本地仓库的命令
git commit -m "add helloGit.txt"

#添加远程仓库
git remote add git /tmp/educoder.git
#拉取远程仓库git的master分支内容到本地
git pull git master:master -f

#将本地master分支的修改推送到远程仓库的master分支
git push -u git master master

#将远程版本库clone到本地
git clone /tmp/sample.git 

初学git，基础不扎实，产生的小问题

在 git pull origin master:master -f 中，冒号的作用是指定从远程仓库（origin）的 master 分支拉取并合并到本地仓库的 master 分支。这种语法可以让你指定从远程仓库的哪个分支拉取并合并到本地的哪个分支。

而如果使用 git pull origin master master -f，这样的语法会被解释为拉取并合并从远程仓库 origin 的 master 分支和 master 分支到当前分支，这并不是你想要的效果。

如果你不使用冒号，比如git pull origin master -f，这样就会将远程仓库 master 分支的内容拉取并合并到当前本地分支，而不会涉及到本地的命名分支。这种情况下，你也可以在拉取之后手动将远程分支合并到本地任何想要的分支。

因此，冒号 (😃 在 git pull 命令中的作用是明确指定要将远程分支的内容合并到本地的哪个分支，确保操作的准确性。

虽然两个测试都能通过，但具体原理不一样。
平台上两个测试都通过的原因其实前者是把远程仓库master 和master拉到当前分支（当前分支其实是master），而后者是把远程仓库master分支拉到本地master分支，
所以建议要用冒号！！！