读《移山之道》的收获与疑问（阅读作业之刘明篇）

《移山之道》是一本介绍软件开发方法（MSF）和工具（VSTS）的书，这本书讲程序设计的基本原则，讲如何在工具的帮助下进行软件的开发、如何与人合作、如何管理软件工程，讲微软解决方案及方法论。

最开始我以为这本书只是单纯地介绍讲解软件工程的知识，读了此书才发现是以讲故事的形式写作的。我觉得这样的方式很有意思，相比于传统的教科书形式，我更喜欢这样的形式。

我在读其他的很多专业书籍时，都觉得光是读书上的内容是很难透彻理解书上的知识的，只有在实践中运用到这些知识或是遇到问题时，才能逐渐地吃透那些知识，将对所学内容的生搬硬套化为纯熟运用。《移山之道》这样的写作方式显然让我这样初次接触软件工程的菜鸟更容易理解。不过，也正如书中作者所说，这本书“太活了”，对我来说，这本书让我对软件工程开发的整体流程与细节均有所了解，但作为"查资料时的工具书"，却不太合适。

 

《现代软件工程讲义》是一套理论和实践相结合的，面向实践，强调“做中学”，通过丰富的材料讲人在软件工程中的不同角色和作用的一套讲义。

这套讲义很注重团队合作以及个人在团队项目中该如何发挥的问题，讲解了进行软件工程开发的整体流程，并且针对学习的不同阶段布置了大量的作业训练。

我认为这套讲义和《移山之道》这本教材相辅相成，配套阅读效果很好。讲义和教材一样，都很生动、很鲜活，我很喜欢这样的教学方式，这样的方式让我觉得教授知识与接受知识都很自然，而不是枯燥的在翻工具书。

 

下面主要叙述几个我觉得比较重要的问题。

一、MSF方法论

MSF敏捷开发模式，是一种方法论。

VSTS是一种全面系统的软件开发工具。

VSTS兼顾了MSF整个开发生命周期中各阶段和各方面的紧密联系将工作项的管理同源码管理和构建管理整合起来，形成一个功能强大而使用方便的应用环境。其他各种开源工具如CVS和ANT往往都只专注于开发流程中的某一方面，需要人为地在整合上花费精力。

在《白话MSF》那一篇里，开篇果冻问阿超的那段话，确实让人纠结，有好多句子我完全读不通，心中发堵。。不过阿超同学的白话解析让我有种豁然开朗的感觉。书中说到MSF对“大企业才有用处，而且容易被人用来忽悠”。MSF对我们现在所进行的团队项目帮助大吗？？就像爱因斯坦的相对论和牛顿经典力学的关系一样。对于我们现在所做的小型项目，遵循MSF的原则是否大材小用，导致过程复杂麻烦没有必要？

若自己目前所进行的任务是由带头人分配的。那么怎样才能确定自己每天所做的任务是对实现“共同的远景”有帮助的？若我认为自己所做的事情收益较低，但一时间又没有更好的办法，有必要向老板提出来吗？

MSF提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间，即让真正做这件事的人按照自己的估计去完成任务。这样的方式，可能会让某些对自己不够自信的成员故意延长自己需要的时间，拖整个团队的后腿。而且，没有来自上级的压力，成员给自己制订的时间足够充裕，懒懒散散地完成任务，很难使个人得到磨炼获得进步。当然我也隐约觉得是我这种思想太落后了，不适应现在的企业发展了。。。

需求的变化可能导致未完成的产品“过时”，不再具有商业价值。面对这种情况，我认为，预防是最好的措施，但我们怎样才能做好这个预测呢？

二、提高个人技术

我是个基础不够扎实的小菜鸟，编程经验少，对于团队项目难免有点畏惧心理，为了不给团队拖后腿，我重点关照了《提高个人技术》这一章。

我也觉得看别人代码时很难看懂，除非知道这个代码是要做什么的，这样还能根据需求推出来代码中每一部分的作用。对于根据代码搞明白程序要解决什么问题这种事，简单的我还能做到，复杂一些的就无能为力了。。更何况也许还有好多著名的算法我都不知道不了解。不过看代码有什么技巧吗？难道是看得多了就会看了吗？

这一章的内容通篇看下来，我发现，并没有太多的提到编程技巧，甚至是几乎未出现。而是主要讲解了由MSF而来的移山精简方法论，以及需求分析、性能测试和效能分析。这些是属于工程的前期和后期工作，书中显然对这一部分更加注重。

三、代码复审

代码复审是要求自己、同伴以及团队对代码共同进行审查的，看起来是性能测试与效能分析的正式版与加强版。

既然要求同伴和团队都对代码进行审查，那他们自然是要先对代码进行研究的，然后发散思维对代码创作者提出很多问题，这个过程中，可能会出现一些代码创作者原本没有考虑到的问题，集思广益嘛，但是也不能保证这些未考虑到的问题都是重要的、必要的，实际上可能大部分问题都是无足轻重的，也许最后得出的结论是解决这个问题的成本远远高于所获得的收益，于是这个问题自然就跳过。

若想要对代码提出一些确实有必要的、能大幅度提高效率的问题，显然要对代码的理解很深，而论到对代码的了解程度，有谁能比得上写代码的人呢。然而，写代码的人一开没有发现的问题，也不是他再对代码复审几遍就可以发现的。

代码复审确实是很有存在的必要，但是我觉得效率不够高。代码复审可能经常发现不了什么有意义的问题，直至这个产品在众多用户的使用过程中，无意识地发现问题。产品的很多缺陷都是由此才会被发现的。