[I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	课程链接
这个作业的要求在哪里	作业要求
我在这个课程的目标是	提升代码水平，学会团队协作，通过敏捷开发开发出预期内的应用程序
这个作业在哪个具体方面帮助我实现目标	理解软件工程，体会协作、开发、测试等的原则

问题一：断言的意义何在？

在过往我所接触以及编写的代码中，只有在操作系统课程中看到过断言的使用，当时我也经常被那无穷无尽的断言所折磨，因为断言没有通过，所以我的代码有问题。文中写到（P76）：

如何验证正确性？那就要用断言(Assert)。断言和错误处理是什么关系？
当你觉得某事肯定如何时，就可以用断言。
Assert (p != NULL);
然后可以直接使用变量P。
如果你认为某事可能会发生.这吋就要写代码来处理可能发生的错误情况

我初看这段话的时候觉得非常合理，认为自己也同意其说法，但在阅读了几遍之后，我又会觉得困惑。我并没有质疑断言是验证正确性的工具，我赞成这一观点，我困惑的在于两个方面：

• 断言应该在什么地方使用，是在正常的开发代码中吗，如果是这样，我总会有一种上帝编程的感觉，似乎开发人员在开发过程中就已经知道了最终的效果，因为我认为开发人员很可能是还在编写代码的过程中就把断言添上了。
• 在我编写代码的过程中，我也会经常使用错误处理，文中说使用断言来验证正确性，但是难道错误处理不能验证正确性吗，如果设想的错误均没有出现，不就意味是正确的吗，同时错误处理还能检查是否有错误或者异常发生。

以上两个方面让我对断言的作用和意义产生困惑，当我们使用断言时，我们当然能够说这可以去验证正确性，但是在我们想要验证正确性时，我们当下最先想到的方式是使用断言吗。

问题二：结对编程当中，怎样才能实现两人之间的有效沟通

本书第四章为“两人合作”，其中介绍了结对编程。没有看书之前，我以为的结对编程即是两个人分好工去开发一个软件。但书中这样写道（P85）：

在结对编程模式下.一对程序员肩并肩、平等地、互补地进行开发工作：他们并排坐在一台电脑前、面对同一个显示器、使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。
结对编程不是程序开发者独到的发明。在现实生活中，也存在着类似的搭档关系：

越野赛车（驾驶，领航员）

驾驶飞机（驾驶，副驾驶）

这些任务都有共同点：在髙速度中完成任务、任务有较尚的技术要求、任务失败的代价很高

结对编程中有两个角色：

1. 驾驶员（Driver）:控制键盘输人。
   
2. 领航员（Navigator）:起到领航、提醒的作用。
   
   这两个角色是可以互换的

从“一台电脑”、“同一个显示器”等描述，我就知道书中所说的结对编程和我想的结对编程是并不一样的。
我看完书，对结对编程有两种理解，第一种就是整个过程都是一个人负责编写代码，另一个人负责提醒、审查。第二种是在第一种的基础上，两个人的角色不断地互换。
无论是哪一种理解，我都想知道怎样才能够保证两人之间有效的沟通。假如两人的代码水平并不相同，那会不会在第一种情况下，负责编程的人根本不会听取另一个人的意见，会不会在第二种情况下，在两个人角色互换之后，新的编程手又去修改另一个人之前写的代码。无论如何，我觉得这都会与结对编程的最终目的所相悖，并没有提升效率，反而可能变成了一加一小于一。
我认为有效的沟通需要做到让对方听懂自己的话以及让对方接受自己的话，在结对编程这个只有两个人的背景下，沟通如果无效，那一定会影响到整体工程、项目的进度与方向。

问题三：图形化建模在如今软件设计中的实用性与意义

书中第十一章在讲软件设计与实现的时候介绍了图形建模和分析方法，也就是在软件的设计分析阶段使用图形化建模，例如思维导图、实体关系图和UML图等。文中对图形建模的介绍是：

我们要给事物建造出一个“模型”，描述事物、事物的属性、事物之间的关系（静态的）以及各个事物之间的信息传递（动态的）。

我也明确知道图形化建模的优点，当我自己画出实体关系图或者UML图之后，也能感受到其直观与形象。但在之前面向对象程序设计课程当中，第四单元我们被要求在编写代码之前画出UML图，我当时也在疑惑，难道所有的软件设计都需要进行图形化建模吗？
我查阅了相关资料，发现虽然并不是一定要在写代码前进行图形化建模，但这仍然是大多公司或者程序员所推荐的。这仍然让我产生了困惑，因为在我看来，我身边的同学包括我自己，其实都不会在写代码之前先画图，我们更常做的是在写代码之前编写设计文档。我有一种这种推荐更多是公司要求的感觉。
但即使是要求，我仍然不认为图形化建模会比撰写文档有很大的优势，一方面是因为在代码没有任何着落的时候，我认为画图很难把设计说清，因为那时可能还没有那么清晰；另一方面是因为在后续真正实现软件的时候，大概率又会发现自己的图存在种种问题，甚至完全没有参考意义，而对图做修改或者重做的代价我认为是比修改文字高的，那么设计时就画图的意义何在？
我认为图形化建模是有意义的，现在每当一个项目完工时，当我们看到其架构图或者设计图，我们一定会被这些直观、形象的图直击心灵，可能一个几千字文档才讲清楚的项目，但一张图就能让我们了解大概。所以其实我认为，图形化建模在软件设计阶段的意义没有那么大，我认为在软件实现阶段才更有必要去图形化建模，帮助我们理清实现思路，查看当前问题。

问题四：AI时代下，怎样提升测试的效率

第十三章向我们介绍软件测试，当我阅读完之后，我发现测试的工作量其实是很大的，我也真正体会到了书中所说：

程序员写完功能的时候.我们感觉好像项目完成了 80%,殊不知后面的20%往往要花费80%的时间。

在之前，同样也是在面向对象编程课程当中，我们有写过单元测试，同时课程对我们测试的覆盖率有要求。当覆盖率要求设置较高时，我相信就算我们非常熟悉自己的代码，编写测试工作仍然是一件非常繁琐、耗时与耗精力的一件事，不仅要考虑自己的代码逻辑，还需要考虑数据范围和形式等。
在自己对自己编写的代码进行测试都是如此，那当我们去测试别人的代码，对别人代码不那么熟悉的情况下，我认为这更是一件艰巨的任务。
如今，AI发展迅速，AI已经常被用在软件开发当中。在之前的面向对象课程的互测环节中，我相信除了自己编写评测机外，也一定有同学询问ai的意见来编造高质量数据，以此来攻击别人代码。那么在真实的测试环境中，我们应该如何使用AI来帮助提升测试效率呢，那时面临的是庞大的代码量，复杂的架构……

问题五：当今时代，创新到底是什么，是否又只能于前沿科技发生或者伴前沿科技发生

第十六章向我们讲了IT行业的创新。我阅读完后，感觉有很多收获，但是也有一个很大的疑惑一直难以得到回答，那就是什么才算创新。
我觉得创新一定伴随着改变，但是改变不一定就是创新，那么什么样的改变才算做创新呢？如果改变之后反响变好、使用者增多，那这个改变就算创新吗？我觉得这个问题很难去真的回答清楚，拿生活中的例子，一家手机公司在其下一个系统推出了一套全新的和其他厂商都不同的ui设计，那这个叫做创新吗？一个领域产出了一个很优秀的产品，但这个产品在一个很微小的方面表现不太好，我通过微调等手段让其在这个方面表现好了很多，这叫做创新吗？比亚迪的电池技术不断升级，这个叫做创新吗？
与之而来的，目前大模型、具身智能、智能体大火，目前似乎只要一个网站、软件等引入了这些火热的领域，那人们似乎就会说这个东西得到了创新。而如果只是把之前的技术拿来使用，哪怕在功能上得到了很好的效果，人们似乎也只会说，其扩展了业务，填充了功能。那么创新是只能在前沿科技本身或者与前沿科技沾边才会发生吗？