大道至简:软件工程实践者的思想

在第 5.5 节“刻（告鸟）类鹜”与“画虎类狗”中，作者介绍了一个成语典故，提出了在软件开发过程中到底是选择“架子”还是“骨子”的命题。通过这两个成语故事的类比，爱民得出的观点是：

“同样，以得失而论，在瀑布模型与 RUP 模型之间，学习前者而不成，可思过程的本质；学习后者而不成，可得文字的架子。—— 用不好 RUP 的人，总会说自己终归还有一堆文档模板可以抄，便是这个缘故。”

这算什么类比，什么逻辑？事实上，学习瀑布模型而不成，同样“可得文字的架子”，如今国内软件工程的现状不就是如此吗？而另一方面，学习 RUP 而不成，同样“可思过程的本质”，RUP 同样具有一个简单、敏捷的本质内核。而且，我们同样可以说，“用不好瀑布模型的人，总会说自己终归还有一堆文档模板可以抄”。可见，作者的以上这段话完全是废话，而且我们可以看出，作者对于 RUP 带有一种明显的偏见，作者因不能理解瀑布与迭代的本质区别而不能理解 RUP。

我看，作者无非是嫌 RUP 内容太多了，他看不懂，而瀑布模型很简单，容易懂。不错，我大体上同意作者所说的“越是简单的东西，往往越是接近于本质”，可是“接近于本质”，并不等同于“就是本质”。

瀑布模型确实很简单，比 RUP、XP 的迭代要简单得多，可是，瀑布模型就是软件开发的本质吗？No，瀑布模型并不能反映软件开发的（全部）真相。经过 30 多年的实践，人们发现采用瀑布模型的项目往往具有很高的风险。请问，在国内做工程的人们真正做到了“需求冻结”吗？软件项目只发布一次，只在项目结束前进行测试，这样的做法真的很聪明吗？于是，从实践得来的经验教训中，人们发现应该用提倡多次发布、尽早测试、允许需求变更的现代迭代递增模型来取代简单的、不合用的、高风险的、一厢情愿的瀑布模型。

作者写道：

“过程理论中，如果懂得了所谓的模型原本都演化自那个简单的瀑布，那么文档是按 XP 写还是按 RUP 写，也就可以应时、应需、因地制宜、择善而从了。本质的东西若能理解得透，架子还不是随手搬来就可以用的吗？”

后半句不错，我们确实应该应时、应需、因地制宜、择善而从，本质的东西若能理解得透，架子确实也可以随手搬来就能用的。可问题的关键是：瀑布是否就是那个本质（即作者所说的骨子），而 RUP 或者 XP 是否就是那个架子？答案是否定的。

瀑布与迭代是一回事吗？一个是线性的、顺序的，一个是非线性的、螺旋的、并发的，两者显然不是一码事。据我们了解，国内团队真正会用 RUP、XP 的并不多，因为传统软件工程教育的关系，很多人不会迭代，不知道迭代与瀑布的真正的、本质的区别。

没错，所有的过程模型都源于那个简单的瀑布模型，这是历史的必然。瀑布模型的问题是它不完备，也不完善，不能很好的消除项目风险，所以既简单也幼稚，而后代的过程模型如 RUP、XP、Scrum 等要比瀑布模型更先进，更完善，能更好地应对项目风险，所以虽复杂却成熟，同时在复杂的表象后面拥有一个简单统一的内核。

虽说迭代是对瀑布的继承和发展，迭代中有瀑布的影子，但二者还是存在着显著的差异。如果你只是把瀑布这个本质“理解得透”，并不代表你理解了迭代那个本质。如果只懂瀑布不懂迭代，说什么 RUP、XP 可以信手拈来、随手搬来，那无疑是一句空话。

www.zhangxun.com

注：本文来自马维峰先生个人博客http://www.cnblogs.com/maweifeng/archive/2005/12/20/300919.html

周爱民先生（http://www.doany.net/）的《大道至简——软件工程实践者的思想》大概几个月前就看了，本来想在Blog上推荐一下，但因为什么原因忘记了，不过这本书没有忘记，时常想起。

个人觉得，这本书最大的价值在于这是一本程序员写的软件工程的书，因此，对于任何一个Coder出身，又有过管理或负责一些软件项目的程序员，都会产生一些共鸣。对于任何系统、软件，最大的问题不是技术，而是技术的应用，大概所谓软件工程。

很早以前做教育，最烦恼的是如何复用，如何通过工具、技术或者平台使很多事情自动化，修改和变更简单，也做过一些框架性的平台，自动生成一些内容的平台，但实际中基本没有使用，越到后来，发现问题远不是这些，关键还是事情和人的流程。

这几年做GIS，最关注的是设计模式之类，这些的应用对于提高开发质量很好，很有帮助，不过设计不会解决所有问题，例如，你设计的和客户的需求根本是2个东西或者说差别很大，怎么办？在实际工作中，对于客户需求，或者说其工作流程和内容，没有一段时间，很难真正了解他们需要什么，不了解或者一知半解，会发现需求很简单或者很复杂，但实际上可能是中间状态。因此重构或者推倒重来肯定是常事。另一方面，一个需求或者功能模块，可以实现有很多方法，如何选取才是关键。对于一般的GIS二次开发，个人的经验，70％的系统熟练Coder可以在1个月完成，那么，关键问题就是如何使用技术完成任务，所谓软件工程。

因此，一个合作的团队，加上简单的工具，有效的沟通才是项目成功的保证。对于程序员，要关注技术，钻研技术，但不能沉迷于技术。

页码不是很多，买过的多说说看。

很轻松的一本读物，作者的思考很有意思

看过电子版，说实话是看不下去了。
废话太多，过多的引经据典，语句无力。
遗憾