大道至简:软件工程实践者的思想
点击看大图基本信息
编辑推荐
本书是在“思想方法学”这一软件工程尚未涉足过的领域中的实习之作。
在缺乏独立思维、对国外工程理论亦步亦趋的国内工程界、开发业界，该书无疑是一份激荡新思的佳作。
本书是第一本讨论软件工程思想本源的书籍，也是第一本从工程实践出发溯源而论的佳作。
推荐阅读
内容简介回到顶部↑
书籍
计算机书籍
本书提出了审视软件工程的全新视角和软件工程的体系模型（ehm，软件工程层状模型）本书用非工程的方式重新解析软件工程现象，全面、细致而深刻地分析了工程中各个环节的由来、价值及其内在关系。综合论述开发、工程二者的现状，例如对程序员“工匠思想”的起源进行广征博引的分析，也对工程中“敏捷过程”的经验主义本质进行深至髓质的论证。全书语言轻快，可读性强，薄且有味。
本书是在“思想方法学”这一软件工程尚未涉足过的领域中的实习之作。作者亲历国内软件工程的英雄时代、泡沫时代，从失败中醒觉而创建独特的思考方法，对软件开发、工程中的现状深刻反思，从而完成这本专著。在缺乏独立思维、对国外工程理论亦步亦趋的国内工程界、开发业界，该书无疑是一份激荡新思的佳作。本书是第一本讨论软件工程思想本源的书籍，也是第一本从工程实践出发溯源而论的佳作。
计算机书籍
本书提出了审视软件工程的全新视角和软件工程的体系模型（ehm，软件工程层状模型）本书用非工程的方式重新解析软件工程现象，全面、细致而深刻地分析了工程中各个环节的由来、价值及其内在关系。综合论述开发、工程二者的现状，例如对程序员“工匠思想”的起源进行广征博引的分析，也对工程中“敏捷过程”的经验主义本质进行深至髓质的论证。全书语言轻快，可读性强，薄且有味。
本书是在“思想方法学”这一软件工程尚未涉足过的领域中的实习之作。作者亲历国内软件工程的英雄时代、泡沫时代，从失败中醒觉而创建独特的思考方法，对软件开发、工程中的现状深刻反思，从而完成这本专著。在缺乏独立思维、对国外工程理论亦步亦趋的国内工程界、开发业界，该书无疑是一份激荡新思的佳作。本书是第一本讨论软件工程思想本源的书籍，也是第一本从工程实践出发溯源而论的佳作。
作译者回到顶部↑
本书提供作译者介绍
周爱民，有十余年的软件开发、项目管理、团队建设的经验。曾任多家软件公司高级程序设计师、项目经理、部门经理、区域总经理等职，现任上海盛大网络平台架构师。目前主要从事软件工程、体系架构和语言基础方面的研究与实践。
2001年，主持完成的“极光数据处理仓库中心系统”被河南省信息产业厅授予省高新技术产品二等奖。
2003年，被美国Borland公司授予“Borland Delphi产品专家”称号。
2004年，出版《Delphi源代码分析》，被誉为“Delphi领域精品著作”。
<< 查看详细
2001年，主持完成的“极光数据处理仓库中心系统”被河南省信息产业厅授予省高新技术产品二等奖。
2003年，被美国Borland公司授予“Borland Delphi产品专家”称号。
2004年，出版《Delphi源代码分析》，被誉为“Delphi领域精品著作”。
<< 查看详细
目录回到顶部↑
对第一版的赞扬
精彩在于思考
停下来，思考才是进步本质
屏幕上的第四种颜色
再版前言
致谢
第一章 编程的精义
第一节 编程的精义
第二节 能不能学会写程序的问题
第三节 程序=算法+结构
第四节 语言
第五节 在没有工程的时代
第二章 是懒人造就了方法
第一节 是懒人造就了方法
第二节 一百万行代码是可以写在一个文件里的
第三节 你桌上的书是乱的吗
第四节 我的第一次思考：程序=算法+结构+方法
第三章 团队缺乏的不只是管理
第一节 三个人的团队
第二节 做项目=死亡游戏
精彩在于思考
停下来，思考才是进步本质
屏幕上的第四种颜色
再版前言
致谢
第一章 编程的精义
第一节 编程的精义
第二节 能不能学会写程序的问题
第三节 程序=算法+结构
第四节 语言
第五节 在没有工程的时代
第二章 是懒人造就了方法
第一节 是懒人造就了方法
第二节 一百万行代码是可以写在一个文件里的
第三节 你桌上的书是乱的吗
第四节 我的第一次思考：程序=算法+结构+方法
第三章 团队缺乏的不只是管理
第一节 三个人的团队
第二节 做项目=死亡游戏
前言回到顶部↑
“你在做什么?”我经常这样反问那些跑来问我问题的人们。然后他们就愣住了。.
做了许多年的开发，其实有很多人并不知道“自己在做什么”。《愚公移山》的故事里面，愚公为山所阻，苦于“出入之迂”，然后就决定“移山”。看起来伟大而风光的工程，可能只是拍拍脑袋的一时主意——如果只是觉得绕路太远，那么劈山开路岂不是更加经济?
愚公移山只是一种精神追求，而做工程却不是追求精神目标。我们的目标是完成工程，但是你现在环顾一下你的团队：有多少人的眼光是落在工程本身上的呢?
程序员正在调试代码，项目经理在忙着开会，市场经理在请客吃饭，老板可能还在来公司的路上……总之，你的身旁没有什么人关注工程本身。即便有一个人或几个人在像模像样地画着模型图，或者写着需求、分析与设计书，但是对于他们来说，这只是例行的工作，而不是出于工程本身的需要。
其实这也是我在几年前的状态，同时身兼主程、团队负责人和项目经理的时候，我列出的工作清单排满了上班与下班的时间。我甚至忙到不知道自己有多忙。直到我将自己的角色分解到“工程层状模型(EHM)”中，我才渐渐地梳理出自己的工作方法。
《大道至简》这本书的名字并没有什么奥妙。因为是先有了EHM，所以这本书根本上是随着EHM的层次来展开的。它的第一版曾在《程序员》中选载过三期，那时我为了方便就以《从编程到工程》作为书名。后来出电子版时，才恢复到现在这个名字。而本质上来说，这本书还是讲的“从编程到工程”的各个环节。
至于“道”，其实在乎于你的认知。它不过是规律、本质的代名词。现在的书名，更像是一个以程序员出身的工程实践者，在历经10年后，终于领悟到“自己在做什么”时的一声感叹。
《大道至简》向你讲述两个内容：做什么和为什么做。“做什么”作为一种状态或者现象，通常是(阶段性)不变的，所以人们了解自己“在做什么”时大多只需要观察。简而言之，只需要自省，就可以了解自己的所作所为了。然而“为什么做”却相对更难于理解，因为这是“表象下的实质”，潜藏得很深：习以为常，便会根本上忘却“习”的来由。例如项目总监说要一份计划，你大概只需要拿一个以前做过的文档模板，很快就能写出一份项目计划案来。但在这个过程中，你已经忘掉了“项目计划案”真正存在的价值——写它的目的，并不是“完成工作”。
写一份项目计划案的时候，你的角色是项目经理，你的职责是计划与分工，你的目标是工程的时间、进度与质量的平衡。这份文档是工程的纲要，因此阅读群体是整个团队和项目干系人。所有这些，都可能导致文档的规格和措辞存在差异。
所以你需要认识“为什么做”。
这其实并不是非常困难。例如我在工程中经常问的问题是“可不可以不做”——哈哈，看起来我很偷懒似的。其实不然，。因为接下来我就会从不同的人那里得到“非做不可”的种种理由。
然而这是方法或者手法。《大道至简》并不告诉你这些具体的方法与手法。我只是叙述了基本的原理与思想。《大道至简》陈述的是一种途径、一个方面，以及一些探求途径、方面过程中的故事与思考。
做事有没有章法，在于你头脑够不够清醒；头脑够不够清醒，在于你是否视见到事物的本实。具体到如何做一件事(例如做软件工程)的方法与步骤，是本书所不能告诉你的。而反过来说，如果你认为你自己“足够清醒”，那么这本书原本也就不会告诉你更多。
你足够清醒吗?
第二版的增改
写这一版的《大道至简》，其实用掉的时间与整个第一版差不太多。但新添加的内容，也就两章三节而已：
第六章，谁是解结的人；
第八章，你看得到工具的本质吗；
第四章第三节，沟通的三层障碍；
第九章第五节，审视AP和XP；
做了许多年的开发，其实有很多人并不知道“自己在做什么”。《愚公移山》的故事里面，愚公为山所阻，苦于“出入之迂”，然后就决定“移山”。看起来伟大而风光的工程，可能只是拍拍脑袋的一时主意——如果只是觉得绕路太远，那么劈山开路岂不是更加经济?
愚公移山只是一种精神追求，而做工程却不是追求精神目标。我们的目标是完成工程，但是你现在环顾一下你的团队：有多少人的眼光是落在工程本身上的呢?
程序员正在调试代码，项目经理在忙着开会，市场经理在请客吃饭，老板可能还在来公司的路上……总之，你的身旁没有什么人关注工程本身。即便有一个人或几个人在像模像样地画着模型图，或者写着需求、分析与设计书，但是对于他们来说，这只是例行的工作，而不是出于工程本身的需要。
其实这也是我在几年前的状态，同时身兼主程、团队负责人和项目经理的时候，我列出的工作清单排满了上班与下班的时间。我甚至忙到不知道自己有多忙。直到我将自己的角色分解到“工程层状模型(EHM)”中，我才渐渐地梳理出自己的工作方法。
《大道至简》这本书的名字并没有什么奥妙。因为是先有了EHM，所以这本书根本上是随着EHM的层次来展开的。它的第一版曾在《程序员》中选载过三期，那时我为了方便就以《从编程到工程》作为书名。后来出电子版时，才恢复到现在这个名字。而本质上来说，这本书还是讲的“从编程到工程”的各个环节。
至于“道”，其实在乎于你的认知。它不过是规律、本质的代名词。现在的书名，更像是一个以程序员出身的工程实践者，在历经10年后，终于领悟到“自己在做什么”时的一声感叹。
《大道至简》向你讲述两个内容：做什么和为什么做。“做什么”作为一种状态或者现象，通常是(阶段性)不变的，所以人们了解自己“在做什么”时大多只需要观察。简而言之，只需要自省，就可以了解自己的所作所为了。然而“为什么做”却相对更难于理解，因为这是“表象下的实质”，潜藏得很深：习以为常，便会根本上忘却“习”的来由。例如项目总监说要一份计划，你大概只需要拿一个以前做过的文档模板，很快就能写出一份项目计划案来。但在这个过程中，你已经忘掉了“项目计划案”真正存在的价值——写它的目的，并不是“完成工作”。
写一份项目计划案的时候，你的角色是项目经理，你的职责是计划与分工，你的目标是工程的时间、进度与质量的平衡。这份文档是工程的纲要，因此阅读群体是整个团队和项目干系人。所有这些，都可能导致文档的规格和措辞存在差异。
所以你需要认识“为什么做”。
这其实并不是非常困难。例如我在工程中经常问的问题是“可不可以不做”——哈哈，看起来我很偷懒似的。其实不然，。因为接下来我就会从不同的人那里得到“非做不可”的种种理由。
然而这是方法或者手法。《大道至简》并不告诉你这些具体的方法与手法。我只是叙述了基本的原理与思想。《大道至简》陈述的是一种途径、一个方面，以及一些探求途径、方面过程中的故事与思考。
做事有没有章法，在于你头脑够不够清醒；头脑够不够清醒，在于你是否视见到事物的本实。具体到如何做一件事(例如做软件工程)的方法与步骤，是本书所不能告诉你的。而反过来说，如果你认为你自己“足够清醒”，那么这本书原本也就不会告诉你更多。
你足够清醒吗?
第二版的增改
写这一版的《大道至简》，其实用掉的时间与整个第一版差不太多。但新添加的内容，也就两章三节而已：
第六章，谁是解结的人；
第八章，你看得到工具的本质吗；
第四章第三节，沟通的三层障碍；
第九章第五节，审视AP和XP；
序言回到顶部↑
序一.
精彩在于思考
爱民的这本小书终于出版了。虽然对于大多数软件开发人员来说，写作并不是一件容易的事情，但书店里软件开发类的图书依然琳琅满目。只是书的价值却不容易衡量，书厚价高未必内容就好，畅销也不见得就很有价值。书是人类思考的结晶，是经验的宝藏。因此书的真正价值在于内容，在于作者的思考，在于读者能否从书中得到收获。宋太宗日阅《太平御览》三卷，因事有缺，暇日追补之，尝曰：“开卷有益，朕不以为劳也”，这就是“开卷有益”一语之由来。
真正的智慧就是洞察事物的本质和相互关系。本质的东西看起来都是很简单的，但本质的来源却是错综复杂的。“大道至简，知易行难”说的就是这个道理。
爱民有着深厚的软件开发功力，技术钻研深入系统核心，并不断地探求软件技术的本来面目。他的这本书虽然不厚，但容量却不小，项目管理、团队管理、过程管理、软件方法学都有所涉及。
尽管每个部分都值得独立成书，但实际上我们并不缺少那样的书籍。作者带给我们的是他对这些领域追本溯源的思考，我最喜欢看的是作者讲述自身的经历和思考的历程，这更接近我们在软件开发中面临的实际情况，也更有助于启发我们自身的思考。
这本书只适合于喜欢读书和思考的软件工作者，读书是两方面的行为，包括读者和作者。
宋儒程颐说：“读论语……有读了全然无事者，有读了后其中得一两句喜者，有读了后知好之者，有读了后不知手之舞之足之蹈之者。”
读者的经历和作者一样重要。读一本好书，就是与好的作者进行思想交流和对话。如果读者没有在这方面的经历，他就无法进行对话，也无从体会这些思想的价值。
“开卷有益”，这是一本闪烁着思考光芒的作品，它的精彩就在于作者深入的思考。
蒋 涛
2006年12月
序二
停下来，思考才是进步的本质
我个人的工作是非常忙碌和繁杂的，由于Borland/CodeGear同时拥有Win32、.NET和Java的产品和开发工具，因此我必须阅读和了解这三个平台的知识和技术。更不用说软件工程了，因为Borland/CodeGear近几年来除了有Together这个产品之外， Borland/CodeGear内部的许多R&D团队也开始使用敏捷开发（Agile Development）的软件工程来研发新产品，尤其是，Borland/CodeGear拥有目前.NET和Java平台上最先进的MAD/DDA技术和产品了。
因此我必须阅读大量的技术书籍，每天在Internet上不断地补充新知，以应付工作上的需要。长期的积累，虽然让我学习了许多技术，但是真正让我不断超越昨日自我的因素，并不光是这些单点的技术，而是多参考业界大师级人物的思想，以及更实际地看看我们同侪的思考，更重要的是，不时地停下来进行融合思考的结果。以前我非常享受在工作时与李匡正先生、苏国钧先生以及我的其他好友共同讨论的时光，盖因在这些好友的谈话和思想中，蕴藏了他们丰富的知识和智慧的精华，让我受益良多。
爱民是我大陆的好友，年轻有活力。每次我到大陆，如果有时间和他见面，他总是有许多话和我谈论。爱民和我还有一个共同点，那就是我们俩都是技术书籍的作者，这让我更进一步认识到在我了解的技术书籍作者中，爱民是一位非常有实力的佼佼者。
由于工作的关系我认识了爱民，也让我有机会能亲自聆听他的一些想法、经验和智慧的结晶，因此我非常幸运地能够藉由这个机缘不断的成长和进步。如果您不像我这么幸运，能够因成为爱民的好友而获益良多，现在您可以藉由阅读爱民的新作《大道至简》来撷取他的思想精华。适时的停下来，参考优秀软件人才的想法，搭配我们学习的各种技术，最后再加入自己融合思考的结果，您将会体验到从未有过的成就感。如果您还不知道这个成功秘诀的话，那么不妨就从《大道至简》开始吧。..
李 维
精彩在于思考
爱民的这本小书终于出版了。虽然对于大多数软件开发人员来说，写作并不是一件容易的事情，但书店里软件开发类的图书依然琳琅满目。只是书的价值却不容易衡量，书厚价高未必内容就好，畅销也不见得就很有价值。书是人类思考的结晶，是经验的宝藏。因此书的真正价值在于内容，在于作者的思考，在于读者能否从书中得到收获。宋太宗日阅《太平御览》三卷，因事有缺，暇日追补之，尝曰：“开卷有益，朕不以为劳也”，这就是“开卷有益”一语之由来。
真正的智慧就是洞察事物的本质和相互关系。本质的东西看起来都是很简单的，但本质的来源却是错综复杂的。“大道至简，知易行难”说的就是这个道理。
爱民有着深厚的软件开发功力，技术钻研深入系统核心，并不断地探求软件技术的本来面目。他的这本书虽然不厚，但容量却不小，项目管理、团队管理、过程管理、软件方法学都有所涉及。
尽管每个部分都值得独立成书，但实际上我们并不缺少那样的书籍。作者带给我们的是他对这些领域追本溯源的思考，我最喜欢看的是作者讲述自身的经历和思考的历程，这更接近我们在软件开发中面临的实际情况，也更有助于启发我们自身的思考。
这本书只适合于喜欢读书和思考的软件工作者，读书是两方面的行为，包括读者和作者。
宋儒程颐说：“读论语……有读了全然无事者，有读了后其中得一两句喜者，有读了后知好之者，有读了后不知手之舞之足之蹈之者。”
读者的经历和作者一样重要。读一本好书，就是与好的作者进行思想交流和对话。如果读者没有在这方面的经历，他就无法进行对话，也无从体会这些思想的价值。
“开卷有益”，这是一本闪烁着思考光芒的作品，它的精彩就在于作者深入的思考。
蒋 涛
2006年12月
序二
停下来，思考才是进步的本质
我个人的工作是非常忙碌和繁杂的，由于Borland/CodeGear同时拥有Win32、.NET和Java的产品和开发工具，因此我必须阅读和了解这三个平台的知识和技术。更不用说软件工程了，因为Borland/CodeGear近几年来除了有Together这个产品之外， Borland/CodeGear内部的许多R&D团队也开始使用敏捷开发（Agile Development）的软件工程来研发新产品，尤其是，Borland/CodeGear拥有目前.NET和Java平台上最先进的MAD/DDA技术和产品了。
因此我必须阅读大量的技术书籍，每天在Internet上不断地补充新知，以应付工作上的需要。长期的积累，虽然让我学习了许多技术，但是真正让我不断超越昨日自我的因素，并不光是这些单点的技术，而是多参考业界大师级人物的思想，以及更实际地看看我们同侪的思考，更重要的是，不时地停下来进行融合思考的结果。以前我非常享受在工作时与李匡正先生、苏国钧先生以及我的其他好友共同讨论的时光，盖因在这些好友的谈话和思想中，蕴藏了他们丰富的知识和智慧的精华，让我受益良多。
爱民是我大陆的好友，年轻有活力。每次我到大陆，如果有时间和他见面，他总是有许多话和我谈论。爱民和我还有一个共同点，那就是我们俩都是技术书籍的作者，这让我更进一步认识到在我了解的技术书籍作者中，爱民是一位非常有实力的佼佼者。
由于工作的关系我认识了爱民，也让我有机会能亲自聆听他的一些想法、经验和智慧的结晶，因此我非常幸运地能够藉由这个机缘不断的成长和进步。如果您不像我这么幸运，能够因成为爱民的好友而获益良多，现在您可以藉由阅读爱民的新作《大道至简》来撷取他的思想精华。适时的停下来，参考优秀软件人才的想法，搭配我们学习的各种技术，最后再加入自己融合思考的结果，您将会体验到从未有过的成就感。如果您还不知道这个成功秘诀的话，那么不妨就从《大道至简》开始吧。..
李 维
评论交流
共有50人开贴评论 66人参与评论 32人参与打分 查看
发表于：2007-5-30 21:15:00
在第 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
“同样，以得失而论，在瀑布模型与 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
)
评价等级：
发表于：2007-6-25 9:14:00
国内的程序员要么真正的高手不写书，要么就是那些半瓶子水的出来写书误导大家，尤其是一些看起来非常有名更容易误导大家，如软件架构设计，软件设计模式与精要之类书籍，这些书的作者确实是有一定水平，写一些基础书籍应该没问题，但如果写一些如设计这样的高端书籍就有问题了，因为他们都没有真正理解了理解了某些技术本质，在自己没有确保自己真正理解了所要讲的技术的本质的前提下又要为了出名急于出书，则会让很多他们的无知fans盲目崇拜，从而误导了很多读者更可怕的是，这些被误导的程序员还会在自己的项目中振振有词的说是某某书中教的，让本就混乱浮躁的中国软件业就更浮躁了。而且写这样高端的书籍又不提供讨论论坛，让大家讨论，通过讨论发现不足，实在是误人子弟
评价等级：
发表于：2007-5-29 7:43:00
注：本文来自马维峰先生个人博客http://www.cnblogs.com/maweifeng/archive/2005/12/20/300919.html
周爱民先生（http://www.doany.net/）的《大道至简——软件工程实践者的思想》大概几个月前就看了，本来想在Blog上推荐一下，但因为什么原因忘记了，不过这本书没有忘记，时常想起。
个人觉得，这本书最大的价值在于这是一本程序员写的软件工程的书，因此，对于任何一个Coder出身，又有过管理或负责一些软件项目的程序员，都会产生一些共鸣。对于任何系统、软件，最大的问题不是技术，而是技术的应用，大概所谓软件工程。
很早以前做教育，最烦恼的是如何复用，如何通过工具、技术或者平台使很多事情自动化，修改和变更简单，也做过一些框架性的平台，自动生成一些内容的平台，但实际中基本没有使用，越到后来，发现问题远不是这些，关键还是事情和人的流程。
这几年做GIS，最关注的是设计模式之类，这些的应用对于提高开发质量很好，很有帮助，不过设计不会解决所有问题，例如，你设计的和客户的需求根本是2个东西或者说差别很大，怎么办？在实际工作中，对于客户需求，或者说其工作流程和内容，没有一段时间，很难真正了解他们需要什么，不了解或者一知半解，会发现需求很简单或者很复杂，但实际上可能是中间状态。因此重构或者推倒重来肯定是常事。另一方面，一个需求或者功能模块，可以实现有很多方法，如何选取才是关键。对于一般的GIS二次开发，个人的经验，70％的系统熟练Coder可以在1个月完成，那么，关键问题就是如何使用技术完成任务，所谓软件工程。
因此，一个合作的团队，加上简单的工具，有效的沟通才是项目成功的保证。对于程序员，要关注技术，钻研技术，但不能沉迷于技术。
周爱民先生（http://www.doany.net/）的《大道至简——软件工程实践者的思想》大概几个月前就看了，本来想在Blog上推荐一下，但因为什么原因忘记了，不过这本书没有忘记，时常想起。
个人觉得，这本书最大的价值在于这是一本程序员写的软件工程的书，因此，对于任何一个Coder出身，又有过管理或负责一些软件项目的程序员，都会产生一些共鸣。对于任何系统、软件，最大的问题不是技术，而是技术的应用，大概所谓软件工程。
很早以前做教育，最烦恼的是如何复用，如何通过工具、技术或者平台使很多事情自动化，修改和变更简单，也做过一些框架性的平台，自动生成一些内容的平台，但实际中基本没有使用，越到后来，发现问题远不是这些，关键还是事情和人的流程。
这几年做GIS，最关注的是设计模式之类，这些的应用对于提高开发质量很好，很有帮助，不过设计不会解决所有问题，例如，你设计的和客户的需求根本是2个东西或者说差别很大，怎么办？在实际工作中，对于客户需求，或者说其工作流程和内容，没有一段时间，很难真正了解他们需要什么，不了解或者一知半解，会发现需求很简单或者很复杂，但实际上可能是中间状态。因此重构或者推倒重来肯定是常事。另一方面，一个需求或者功能模块，可以实现有很多方法，如何选取才是关键。对于一般的GIS二次开发，个人的经验，70％的系统熟练Coder可以在1个月完成，那么，关键问题就是如何使用技术完成任务，所谓软件工程。
因此，一个合作的团队，加上简单的工具，有效的沟通才是项目成功的保证。对于程序员，要关注技术，钻研技术，但不能沉迷于技术。
加载中...| 我要写评论 |
| 查看所有评论交流(共50条) |
