第二次作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/zjlg/rjjc20
这个作业的目标	<阅读《构建之法》并提出三个问题>
姓名-学号	<叶易欣>-<2018330301028>
问题一：真正意义上好的软件是怎样的软件
======
源自：

Bug 的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。

--引用自《构建之法》P15

是否是Bug，取决于用户、开发者的不同角度。

--引用自《构建之法》P16

看法：书中说 Bug 的多少可以用来衡量一个软件的好坏程度，但是是否为 Bug，取决于用户和开发者的不同角度，因此，真正意义上的好软件，究竟是在开发者的角度看 Bug 的数量还是从用户的角度来看待，就好比一个用户下载了某个公司的一个软件，但是在用户不知情的情况下同时下载了另外几个软件，对于公司来说，这样一个软件可以增加公司软件的下载量，对公司来说这肯定不是一个 Bug，但是对于用户来说，他并没有同意下载这些软件，对他来说，这个肯定是存在的一个 Bug，因此站在不同的角度，一个软件是否存在 Bug 是存在争议的，因此在真正意义上，什么样的软件才是好的软件，到底是要站在开发者的角度来看待还是从用户的角度来看。

问题二：程序的作者一定是写单元测试的最佳人选吗？

源自：

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

--引用自《构建之法》P25

看法：通过查阅资料，进行单元测试的的意义是减少 Bug、提高代码质量、快速定位 Bug、减少调试时间等，虽然代码的作者确实是最了解代码的人，但是他在写代码的时候往往会忽视一些细节问题，并且这些细节问题往往是很难寻找出来的，而且在不同人的眼里，同一个代码可能存在着不同的问题，所以是否代写单元测试就是由代码的作者来写，而不是通过多个人来寻找出其中的不足之处，由多方面的思考和经验来完成单元测试。

问题三：过早优化真的是“一切烦恼的根源”吗？

源自：

这个毛病早就被归纳为“过早的优化是一切罪恶的根源”

--引用自《构建之法》P53

看法：虽然书上给出的例子来看，过早的优化是一切罪恶的根源是有一定道理的，但是这句话是不是太过绝对，在软件工程中，早一点进行改良和优化是否会带来更多的问题，早点发现问题并进行改善是否只会带来负面的影响，如果不能过早优化，在编程工作进行时具体应该如何操作。