第二次作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/zjlg/rjjc20
这个作业的目标	<通读构建之法，提出三个问题>
姓名-学号	<朱逸豪>-<2018330301070>
第一个问题
==============

• 原文：

有些规律是指明了变化的趋势，例如：向进度落后的项目中增加人员，会让项目更加落后。
-- 摘自《构建之法》第15页

• 我的疑问：为什么向进度落后的项目中增加人员会让项目更加落后？假如真这样，岂不是没有办法提高效率？

• 我的想法：通过查阅资料，我觉得这句话有一定的合理性，但却不是很全面。软件项目团队需要高强度的沟通和协助，不是单纯的工作组。假如项目中有n个工作人员，那么团队每增加一个人，就会增加n个接口。如果单纯就这样想，似乎得出这个结论是很自然的事，毕竟人数增加，沟通量就会增加，效率必然是会降低的。但我觉得如果这是一个很庞大的项目，这个结论是不是就不能成立了呢？与项目相比，沟通环节耗费的时间或许并不是很多，效率也就能提高了。

第二个问题

• 原文：

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

• 我的疑问：单元测试为什么要由代码的作者进行？

• 我的想法：单元测试的目的是为了明确程序模块的功能，以方便他人调用此模块。代码的作者创造了这个代码，按理说应该是最熟悉这个代码的人，但会不会存在“当局者迷旁观者清”的一种情况？就像我当初学习c语言一样，编写代码出错，有时查了好几遍也没有发现问题出现在哪，给别人一看，马上就发现了。因此，在单元测试时会不会两个人或者更多人进行会好些？

第三个问题

• 原文：

软件工程师的思维误区：分析麻痹：一种极端情况是想弄清楚所有细节、所有依赖关系之后再动手，心理上过于悲观，不想修复问题，出了问题都赖在相关问题上。分析太多，腿都麻了，没法起步前进，故得名“分析麻痹”。
-- 摘自《构建之法》第48页

• 我的疑问：为什么分析麻痹是一种思维误区？

• 我的想法：就像医生给病人看病，弄清楚所有细节难道不是更容易对症下药？我觉得软件工程师弄清楚细节能提高他们对代码和整个项目的理解，并且对之后的工作大有好处，毕竟“熟能生巧”。难道就因为工作量大会让工程师心理过于悲观，就忽视细节吗？因此我觉得弄清楚所有细节不应该是思维误区。