第一次作业（个人作业）：阅读教材，提五个问题

2006040103黄馨怡 2022-10-06 22:04:31

这个作业的要求是：https://bbs.csdn.net/topics/608340396

作业内容：

问题一：
我阅读了教材2.1单元测试这方面的内容，书中给出了一系列“好的单元测试的标准”，但我没能理解“单元测试应该在最基本的功能/参数上验证程序的正确性”———如何定义“最基本”？如果按书中测试每一个基本单元，如在 C++/C#/Java 中的类，是否过于繁琐、工作量也随之增加？（虽然书中提到可以把单元测试自动化）
我个人对单元测试的理解是，针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。但是对于“单元”的含义，应该根据实际情况去判定，C语言中指一个函数，Java里指一个类，图形化的软件中可以指一个窗口或一个菜单等，但对于一个有经验的程序员来说会专门去测试一个函数、一个类吗？我觉得“不至于此”，书中说“在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成)”，比如初始化、绘图之类的功能也要逐一测试？那如果开发的是一个由诸如此类基本功能创建的大型系统，是否可以测试几个样例，保证其同类型功能没有问题就好（如创建账户，用邮箱创建和用手机号创建如出一辙，代码也大致相同，那我可不可以只测试二者之间一个功能是正确的就好）。“最基本”，从面向对象的设计原理出发，由类及其方法来表现。可实际应用中单元测试真的要做到测试 API 中的每一个方法及每一个参数吗？即使是仅仅本科生大多时候也能够保证编程环节中的这些基本问题不出错，对于商业化开发人员应该更“不屑于”逐一测试？所以虽然是所谓“好的单元测试的标准”，但实际应用中是不是并没有很多成熟的软件工程师会这样刻板执行。有些资料说：单元是可以由人为规定的最小的被测功能模块，那如何规定，应该是可以由程序员主观定义吧？
问题二：
教材3.2节“软件工程师的思维误区”中提到其中一个误区是过早优化，但我有些不理解。书中指出“一个复杂的软件似乎很多模块都可以变得更好。一个工程师在写程序的时候，经常容易在某一个局部问题上陷进去，花大量时间对其进行优化；无视这个模块对全局的重要性，甚至还不知道这个“全局”是怎么样的。这个毛病早就被归纳为“过早的优化是一切罪恶的根源。”为什么过早优化的后果会严重到成为“万恶之源”？
我理解的过早优化通俗来讲（可能不够准确）大概指在写代码的过程中，还没完成功能，就开始搞优化，例如写到一半，就去想刚才那个函数换个写法是不是效率更高或者兼容性更好。但这样的行为难道不是软件工程师严谨和追求尽善尽美的体现嘛？从我开始写hello world时老师就讲要编程风格良好、程序段的时间空间复杂度要低，可在软件开发的编程阶段考虑这些基本问题竟然成了万恶之源的“过早优化”？可能是我个人的完美主义让我无法理解这一点，在最基础的过程中精益求精难道不是更有利于最终整个系统的成功和完善吗？不在局部问题上进行优化，到了纵观全局的时候想要再去优化的成本不是更高了吗？而且书中没有提到（或者是我认为那个举例实在不贴切）的是，过早优化究竟会导致什么后果？为什么将这一行为称作“万恶之源”这么严重…从另一方面来看，我认为刻板固守“过早优化是万恶之源”的理念何尝不是部分人不愿意花精力琢磨写烂代码的借口…现在不优化，下次优化还得再测试一遍，为何不选择尽早优化？
问题三：
教材4.3.2提到“函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括 goto。”这实在是一个大槽点…因为之前的课程中有老师明确的指出良好的代码风格——少用goto。当然我也不是迷信权威对老师说的话深信不疑，只是经过个人思考觉得确实如此。
goto可以用来替代掉if，for，while，do，函数调用，返回，等所有形式的分支与跳转，用这种方法组织起一个程序真的会觉得用goto很糟，只为了达到单一出口的目的滥用goto本身就不可行，更不能谈得上有助于程序逻辑的清晰体现。我个人理解goto本质就是流程控制，但是流程这个东西，基本上也就只有子流程、循环和条件分支，这三者分别对应函数调用，for、while循环和if、switch。此外还有跳过（continue）和跳出（break、return），这些流程控制符已经基本让我们可以控制所有的流程了，而且这些东西的语义明显比goto好得多。写一大堆goto，等于是人肉编译器，代码混淆器，底层代码生成器（…)虽然机器都是一样的读可代码是写给人看的，如果跟我结对编程的伙伴写了一堆goto放在我面前的话我真的会崩溃（…）
问题四：
教材7.4简单介绍了“MSF 过程模型”，即MSF 过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的，它把瀑布模型中基于里程碑的规划优势与螺旋模型中增量迭代的长处结合了起来。但书中介绍有些过于笼统和含糊，MSF 过程模型的基本元素是阶段和里程碑。团队用里程碑来检查工作是否结束和同步各个角色的进度，以此来确定当前阶段的目标是否已经实现，是否可以说里程碑是每一阶段任务的导向？里程碑标志着每个阶段的结束，此时任务目标应该变更，在上一个阶段产生的各种交付内容成为下一阶段的起始点。
我个人理解的“里程碑”相当于MSF模式中的中心，整个过程用里程碑来监控项目的进程，但不监控项目的质量，质量需要在每一个阶段中由每一个程序员来保证。查阅资料得知，MSF中的里程碑还可以分为“主里程碑”和“中间里程碑”。主里程碑是项目阶段的转换点。MSF中主里程碑有“远景/范围认可”、“项目计划认可”、“范围完成”、“发布就绪认可”、“部署成功”。中间里程碑是指两个主里程碑之间的小的工作目标指示物或工作成果。这是瀑布模型的思想，在此基础上迭代开发重复发生，代码、文档、设计、计划和其他的工作成果都以迭代的形式出现。这样的手段把软件过程分为几个阶段以后，可以针对某一阶段中存在的问题进行定位、分析和解决，为提高软件开发的成功率提供了有效保障。不过也确实有些太理想化了，谁都无法预料会在哪一个阶段出现什么差错、或是团队中每个人效率不统一，这样是否会直接影响后面所有阶段的进度。
问题五：
从第十章一直读到11.4从Spec到设计这一节，我心里一直有个疑问是：如果按照FDD方法，那么拿到设计文档之后，是否可以开始进行原型设计开发，还是说原型设计是和Spec同步、或作为Spec的一部分来完成定义软件需求和用户界面设计的任务？
教材中很少提到原型设计的重要性，但我认为在需求分析阶段要得到完全、一致、准确、合理的需求说明存在困难。在获得一组原始需求后，如何快速地使其“实现”，通过原型反馈，加深对系统的理解？如何满足用户基本要求，使用户在试用过程中受到启发，对需求说明进行补充和精确化，消除不协调的系统需求，逐步确定各种需求？如何获得合理、协调一致、无歧义的、完整的、可行的需求说明？原型设计是这些问题的解决途径，不仅解决了需求阶段的一致性问题，还能很好地将这种一致性的传递到产品研发过程中的系统设计阶段、视觉设计阶段、编码和测试阶段等过程。快速原型是非常有效的需求可视化呈现、传递和解释手段。但何时进行原型设计？把原型系统交给用户看后要怎么去实现和填充这个用户界面的“外壳”？当我在准备自己的小项目时为了迎合评委的需求，开发了一个初步可运行的高保真原型系统，向评委展示我们目标系统的雏形，但其仅仅做到了用户界面的功能展示，并且在开发完这个原型后我们变得不知所措，不知道接下来该做什么，我们想要去往这个原型外壳中填充进数据和代码让我们的系统变得真正可运行，但不知道该怎么去做，原型系统是“必须抛弃”吗？在后续的软件开发中必须把它推倒一步步重来？

...全文