《移山之道》这本书是我们这个学期软件工程课程的课本，非常荣幸的是这本书的作者就是我们课程的授课老师。
读书就要思考，不然也就失去了读书的意义。
在这里和大家分享五个问题，算是抛砖引玉，其中有的已经初步解决了，有的待解决的欢迎大家讨论。
1、Bug的来历
程序中出现的问题为什么叫bug呢？
记得还在小学的时候，一个知识渊博的同学非常得瑟的和我们说，程序了的错误叫bug。后来就记住了，可是从来都没有去深究这里面到底有什么渊源？赋予了这个单词这么有科技感的含义。
原来，最早的计算机是由真空管设备组成的，并用很多电，而且计算机运行时发光发热。难免引得一些小虫钻进真空管。引起机器发生故障，技术人员耗费了半天终于查出原来是这只小虫（bug）引发了问题。移除小虫后，机器恢复正常。从此，Bug一词被沿用下来，用来表示程序或电脑系统中隐藏的错误、缺陷、漏洞等。
2、敏捷开发的到底是什么？
说实在的，敏捷开发那段把我看得一头雾水，关键是他怎么就敏捷了没有掌握清楚精髓。很需要把这个问题弄弄清楚。我想通过下面的总结我认识的更清楚了。
敏捷开发，追求的是开发速度，也就是快速开发。简单地说就是只跟随客户当前提出的需求，而不去挖掘或揣摩那些潜在的功能扩展，当客户再提出新的需求或变更时再继续开发。表面上看这么做很轻率，效率肯定也不会高，事实上这么干实际上对开发和设计人员有更高的要求。
成功的敏捷开发建立在高内聚低耦合的基础上，工作表面上看起来是不考虑以后的扩展性能，但实际上真正的敏捷开发必须做到：当客户新的需求提出来，我们能很快做出响应，拿出对策。这就意味着，我们不但要对项目的整体业务有比较深刻的认识，还要有高内聚低耦合的编码功力。
只有这样，敏捷开发才是真事，而不是彼此忽悠。
以上这个问题我会提出我想主要原因是，我们的项目经验还很少。如果有了丰富的经验，那么学起软件工程的很多成果来一定会产生内心的共鸣，从而更加容易懂并且提升日常的工作。当然，我们现在早早知道并没有坏处。也许今后的某一天重新复习软件工程的经典段落，又是一番滋味呢。
3、整个书像是在讲故事，是用一群任务和他们所做的事串起来的，这种形式的课本到底好不好呢？
1）我的感觉呢是，开始看起来非常有意思，王屋村的村民们踌躇满志、大干一场、人才济济，看的饶有兴致。后来各种不熟悉的专业名词一来，稍微枯燥，有点小晕。新事物第一遍总是这样，尤其对于中人之资的初学者。
2）相比较于传统的照本宣科的讲法，无疑这种叙事方法更加生动，趣味性随之增加。
3）并不是每个人都对此很满意，也有读者表示“作者试图写的很有意思，可惜最后不伦不类。”
一千个读者眼中有一千个哈姆雷特。至少这本书是软件工程书中的一种创新，是非常值得肯定的。
4、双人合作到底有无必要？难道不是人力浪费吗？
一件工作本来一个人可以完成，为什么要分给两个人呢？这难道不是一种人力的浪费呢？其实只要想想结对编程带来的好处，便能得出结论，这种工作模式也有很有存在的价值的。
按照我的体会，具体的说。
1）结对编程能够提供更好的设计质量和代码质量，两个人合作能够够有更强的解决问题能力。
2）结对编程给我们带来了更多的信心，你不是一个人在战斗。
3）结对编程能够更有效地交流，相互学习和传递经验。
相应的挑战和付出的代价，当然是随之而来的交流沟通成本，不过我认为还是非常值得的。
5.、TFS系统的用户状况到底怎么样？
课程项目开发时我们使用了TFS系统来管理项目，我们发现它也又一些不足，比如
1）连接速度慢，经常卡掉了要反应很久，比较影响工作效率。
2）VS系统本身是一个很臃肿的系统，我的很多同学都为此抱怨。
3）TFS关联了许多MS Office的产品，也对其产生了依赖。
4）各种需要填写的表格、信息管理系统、权限管理系统稍显复杂，用户是否易用。
我们的软件工程项目被绑定限制在了必须在TFS上完成，如果没有这一要求是否同学们还会坚持在这个平台式操作。实际软件产业中，依赖TFS进行项目开发的除了微软的研发部门，其他企业的采用率是否足够高？
——Zhe Song @USTC
773
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
