《构建之法》阅读有疑 与 个人Week1作业
《构建之法》阅读有疑
在用将近五节课的时间将邹欣老师的书《构建之法——现代软件工程》第二版大致看完。虽然全书是以轻松的口吻与”移山公司”员工的一些趣味谈话来传输一些理念和思想的，但是读完并理解依旧不是一件很容易的事情，并且在这过程中我对书中的一些看法抱有怀疑的态度，现将问题所在列在下面。
- P68页：我不是很认同邹老师的“精通”魔方的判定方法。就好像在软件工程开发中，一个人解决了一个bug。解决了bug却不算是“精通”，还得能恢复bug，再现bug才算是懂得各中原理吗？我觉得作为一个软件开发者，我们掌握解决bug的技巧与能力即可，不需要掌握复现bug的手段。
- P79页：关于goto的使用。说实话这是我第一次看到goto的好话。我只见过goto在操作系统底层源码使用的情况，当然，在操作系统底层有些时候使用goto跳到错误处理避免无谓的重复。但是使用goto即使是在操作系统底层也应该慎重使用，不知道邹老师认为还有什么样的情况属于“有助于程序逻辑的清晰体现？”。
- P89页：在这里关于结对编程我有一个困惑：如果结对编程的伙伴不与我沟通，并且对于结对编程没有热情，这样的结对编程反而只会让效率低下。在这种情况下，除了换结对伙伴外（一般出门在外，身不由己），怎样能提高结对编程的效果？
- P85页：真的有必要对不可能运行到的代码路径进行单元测试吗？尤其是在本来封装性很好的情况下，为了单元测试而强行拆解函数，把类增加了很多无用的方法？老师如何看待这种问题？
- P117页：关于敏捷开发。敏捷开发的模式可以说是种轻便的模式，但是有一个严肃的问题摆在我们面前：小的创业团队一旦敏捷开发了一款创意优秀的软件并且在完善它到很好的程度前就发布了。这样会不会引来大公司的创意剽窃？尤其是在财力，人力都不如大型公司的情况下，怎样解决这种在敏捷开发中可能遇到的问题？
- 还有一个个人问题想问老师：为什么初入行业的软件工程师总是对自己的代码风格与效率盲目自信，而总想重构他人的代码？一个项目进展到什么样的程度才能叫不可维护，在怎样的情况下才有正当的理由被重构？
软件和软件工程的出现
软件一词在: 1958 年Turkey在论文“The Teaching of Concrete Mathematics”中提出。
wiki原文为：
In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey’s 1958 paper “The Teaching of Concrete Mathematics”contained the earliest known usage of the term “software” found in a search of JSTOR’s electronic archives, predating the OED’s citation by two years.
软件工程一词是 Margaret Hamilton 在NASA设计阿波罗号电脑上的软件时提出的新名词。
