第二次作业
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/zjlg/rjjc20 |
|---|---|
| 这个作业的目标 | <使用排版，清晰地表明观点，学会怎么表达疑惑> |
| 姓名-学号 | <金泓旭>-<2018339930011> |
1、问题一
出处
Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。——《构建之法》p15
观点
书中所说bug的数量可以衡量很多问题，但我觉得数量只能代表一半，除去数量还有个评判标准叫质量，一个bug对开发商造成的利益损失将是对一个bug的危害考究，我认为评判一个软件的好坏，应开发一种算法，从前期的bug数量与后期投入使用后的bug危害两者结合，来产生一个评判值。
链接
[CSDN]（https://blog.csdn.net/kevinkevin/article/details/5452381）
《软件系统的质量评判标准》
2、问题二
出处
过早的优化是一切罪恶的根源。——《构建之法》p49
观点
书中说工程师陷入某个局部问题，花大量时间优化，过早优化是一切罪恶的根源，可是在我们写代码的时候，经常其中一个循环结构之类的出错了导致整个程序运行不下去等问题，只有解决了优化了眼前的模块，才能在继续下去，这和我的实践有较大的冲突。
观点佐证
万恶之源其实是胡乱设计，打乱模块边界，破坏开闭原则，优化只是个表象，所谓的优化往往都是：
滥用输入数据的特性，比如现在只要处理两个汉字，就不考虑以后需要处理更长字符串的问题；
滥用现有流程，明明应该是后面过程一部分的功能，为了所谓效率强行合到前一级的过程里，或者假设前级只会以某种特定方式调用后级。
这些“优化”从一开始就绝对应该避免的，有的人不明白这个道理，以为是自己好心优化办了坏事，是只看到表象没有看到实质，实际上的问题是设计不合理或者没有严格遵循设计。
转自知乎
3、问题三
出处
单元测试必须由最熟悉代码的人来写。——《构建之法》p25
观点
单元测试由最熟悉的人来写是因为他熟悉，但正因为是同一个人，他跳不出自己的思维牢笼，都说当局者迷旁观者清，我认为单元测试要有至少一个更高水平的程序员或者多个同水平程序员来写，只有思维风暴才能考虑周全。我认为测试人员的存在就是这个观点最大的反证。
