问题一
·出处
·bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。——《构建之法》p15
·我的疑问
·书中所说bug的数量可以衡量很多问题,但我觉得数量只能代表一半,除去数量还有个评判标准叫质量,一个bug对开发商造成的利益损失将是对一个bug的危害考究,我认为评判一个软件的好坏,应开发一种算法,从前期的bug数量与后期投入使用后的bug危害两者结合,来产生一个评判值。
问题二
·出处
·软件工程师的思维误区:不分主次,想解决所有依赖问题。另一种极端是过于积极,想马上动手修复所有主要和次要的依赖问题,然后就可以“完美的”达成最初设定的目标。——摘自《构建之法》p.48 第3章软件工程师的成长。
·我的疑问
·想要解决所有问题为什么会是软件工程师的思维误区?软件工程师的终极目标应该是设计出一种“足够好的软件”,为了这个目的应该找到设计过程中的所有问题并将其解决,这样才算得上是对自己的作品负责。“想要解决所有问题”的这种想法在我看来也是开发者应有的精神,并且在解决这些问题的过程中,对开发者而言也是一种锻炼的好机会。所以我认为想解决所有依赖问题未必是思维误区。
问题三
·出处
·单元测试必须由最熟悉代码的人来写。——《构建之法》p25
·我的疑问
·单元测试由最熟悉的人来写是因为他熟悉,但正因为是同一个人,他跳不出自己的思维牢笼,都说当局者迷旁观者清,我认为单元测试要有至少一个更高水平的程序员或者多个同水平程序员来写,只有思维风暴才能考虑周全。我认为测试人员的存在就是这个观点最大的反证