大道至简

出版时间：2012-8  出版社：电子工业出版社  作者：周爱民  页数：204  
Tag标签：无  

内容概要

本书提出了审视软件工程的全新视角和软件工程的体系模型（EHM，软件工程层状模型）。本书用非工程的方式重新解析软件工程现象，全面、细致而深刻地分析了工程中各个环节的由来、价值及其内在关系。综合论述开发、工程二者的现状，例如对程序员“工匠思想”的起源进行广征博引的分析，也对工程中“敏捷过程”的经验主义本质进行深至髓质的论证。全书语言轻快，可读性强，薄且有味。　　本书是在“思想方法学”这一软件工程尚未涉足过的领域中的实习之作。作者亲历国内软件工程的英雄时代、泡沫时代，从失败中醒觉而创建独特的思考方法，对软件开发、工程中的现状深刻反思，从而完成这本专著。在缺乏独立思维、对国外工程理论亦步亦趋的国内工程界、开发业界，该书无疑是一份激荡新思的佳作。本书是第一本讨论软件工程思想本源的书籍，也是第一本从工程实践出发溯源而论的佳作。　　本典藏版在内容上以该书第二版为底本并进行了大量的文字修订，补充追加了第三版中的“具体工程”一章。并且，考虑到典藏的价值，本书收录了公开文档“幕后故事”的精华摘选。

作者简介

周爱民(Aimingoo)，有十余年的软件开发、项目管理、团队建设的经验。曾任多家软件公司高级程序设计师、项目经理、部门经理、区域总经理等职，前支付宝（中国）公司业务架构师，前盛大网络平台架构师。目前主要从事软件工程、体系架构和语言基础方面的研究与实践。
■ 2001 年，主持完成的“极光数据处理仓库中心系统”被河南省信息产业厅授予
省高新技术产品二等奖。
■ 2003 年，被美国Borland 公司授予“Borland Delphi 产品专家”称号。
■ 2004 年，出版《Delphi 源代码分析》，被誉为“Delphi 领域精品著作”。
■ 2005 年，发布《大道至简——软件工程实践者的思想》第一版（电子版）。
■ 2006 年，发起开源项目Qomolangma OpenProject，探讨语言系统基础技术。
■ 2008 年，出版《JavaScript 语言精髓与编程实践》，电子工业出版社。
■ 2008 年，发起开源项目derlang，探讨erlang in delphi，以及erlang 的应用技术。
■ 2009 年，在开源项目QoBean 中尝试Meta Language 与DSL 等实现。
■ 2009 年，发布《动态函数式语言精髓》（电子版）。
■ 2012 年，出版《JavaScript 语言精髓与编程实践（第2 版）》，电子工业出版社。
■ 2012 年，出版《大道至易——实践者的思想》，人民邮电出版社。
■ 2007 年至2012 年，出版《大道至简——软件工程实践者的思想》第二版、第三
版（点评版）、第四版（典藏版），电子工业出版社。

书籍目录

目 录第一章 编程的精义　　　　1第一节 编程的精义　　　2第二节 能不能学会写程序的问题　3第三节 程序 = 算法 + 结构　　　　　4第四节 语言　　　　6第五节 在没有工程的时代　　6第二章 是懒人造就了方法　　　9第一节 是懒人造就了方法　　　　10第二节 一百万行代码是可以写在一个文件里的11第三节 你桌上的书是乱的吗　　　　　13第四节 我的第一次思考：程序 = 算法 + 结构 + 方法14第三章 团队缺乏的不只是管理　　　21第一节 三个人的团队　　　　22第二节 做项目 = 死亡游戏　24第三节 做ISO 质量体系的教训　　　　25第四节 谁动摇了你的制度　　　　27第五节 “那我们就开始开发吧”　28第六节 组织的学问：角色　　　　29第七节 跟随蚂蚁，但不要栽进蚂蚁洞里　31第八节 “什么是增值税发票？”　33第四章 流于形式的沟通　　　　　　37第一节 客户不会用C，难道就会用UML 吗38第二节 项目文档真的可以用甲骨文来写　39第三节 沟通的三层障碍　　　　　42第四节 最简沟通　　　　　　45第五节 为不存在的角色留下沟通的渠道　47第六节 流于形式的沟通　　　　　49第五章 失败的过程也是过程　　　　　　51第一节 做过程不是做工程　　　　52第二节 做过场　　　　　54第三节 实现，才是目的　　　　　54第四节 过程不是死模型　　　　　55第五节 “刻鹄类鹜”与“画虎类狗”　　　57第六节 工程不是做的，是组织的　　　59第六章 谁是解结的人　　　　　61第一节 是谁的问题　　　　　62第二节 正视你的成功　　　　64第三节 总得先做点儿什么吧　　　　　65第四节 你不是团队的腿　　　　　68第五节 三鼓而竭　　　　　　71第六节 先人后己　　　　　　74第七节 自相矛盾　　　　　　76第七章 从编程到工程　　　　　79第一节 语言只是工具　　　　80第二节 关注点　　　　　81第三节 程序　　　　　　82第四节 方法　　　　　　83第五节 过程　　　　　　84第六节 工程　　　　　　85第七节 组织　　　　　　87第八节 BOSS　　　　　　89第九节 上帝之手　　　　　　90第八章 你看得到工具的本质吗　　　95第一节 利器何以为先　　　　96第二节 神乎其技又有什么用呢　　　　97第三节 工具的本质　　　　　98第四节 惟手熟尔　　　100第五节 鲁班带了个坏头　　101第六节 工匠思想　　　103第七节 化而用之，融通与融同　105第八节 南橘北枳　　　109第九章 现实中的软件工程　　　　　113第一节 大公司手中的算盘　114第二节 思考项目成本的经理　　118第三节 审视AOP　　　121第四节 审视MDA/MDD　　　　　122第五节 审视AP 和XP　　　125第十章 具体工程　　　　　　131第一节 预言——《人月神话》及其地位　132第二节 错误的命题——对《人月神话》的反思136第三节 具体工程以及工程的具体化　139第四节 控制规模　　　142第五节 隔离问题域　　145第六节 这样是不是太简单了　　148第七节 郑人的履　　　150第十一章 是思考还是思想　　153第一节 软件工程三个要素的价值　　154第二节 其实RUP 是一个杂物箱　　　155第三节 UML 与甲骨文之间的异同　　　　156第四节 经营者离开发者很远，反之亦然　　　157第五节 矛盾：实现目标与保障质量　157第六节 枝节与细节　　158第七节 细解“法”与“式”　　159第八节 灵活的软件工程　　162附录一 愚公移山记　　　165附录二 愚公移山记（文言）　　　　　　173附录三 幕后故事（摘选）　　　　　179参考文献　　　　　　193前言后语　　　　　　195版本历史　　　　　　203

章节摘录

　　第三节 沟通的三层障碍　　我们坐在一起“聚室而谋日”，只是解决了“沟通渠道”的问题。但沟通的双方被找来坐在一起，相互间都没有想过怎样跟别人阐述他的想法和道理，这样表述的内容当然让人难以理解。又或者是不同的人总在转述着相同的内容（例如你发现在会议中A多数时候都在重述B的言论）——显然，这是因为新的沟通或讨论必须在一种共识的基础上进行，所以每个人都在试图要求对方确认“我的理解是否正确”。　　这些其实都是“沟通质量”的问题。　　我不是语言学家或考古学家，因此坦白地说，我并不知道甲骨文的读音。然而这些未经组织的语言就好比是一种我们不知道读音的甲骨文：我们能大概地看懂文字的表面，却不知道讲述者在表述什么内容，或者他为什么要这样表述。　　所以沟通的第一层障碍，并不在于你要表达的内容，而在于你如何表达。换个说法：就是，“不知所云”。这种隋况下，你需要组织语言、学会说话。　　现在假设你花了半个小时在一家商店选购，结果你对店员小姐拿出的每一件物品都不满意。在你离开的时候，她可能会这样对你表达歉意：“对不起，先生，我们这里没有您想要的东西……”　　第一次听到这句话的时候，我就在想，她为什么不说“对不起，先生，您想要的东西我们这里没有”呢？这两句话到底有什么差异呢？　　仔细理解这两句话，前者在说的是“我们没有”，因而责任在我；后者在说的是“您想要的”，因而责任在您。看起来这两句话是在表述同一件事，但因为语言组织得不同，前一句的语气是在“致歉”，后一句则是在“推诿”。　　接下来又会发生什么呢？如果店员小姐说“对不起，我们没有……”，那么可能三天后这个商场就会有货了，因为她会有更主动的意识去解决问题；但如果她说“你想要的……我们没有”，那么你就不要指望在这家店里还能买到你想要的商品，因为在她看来，“你要什么东西”只是你自己的事情。　　因此，即使抛开这两句话是否舒适悦耳的比较，我们在潜意识中也在希望从这两句话中看到事件的后续发展。由此看来，从叙述中揣度结果，是人们在交流沟通过程中潜在的意识和行为：如果两个人在努力地交流，那么他们都一定会像分析这两句话的差异一样，无比细致地去分析对方的描述。因此，（注意！）他们事实上都会关注对方的措词、语气、句法，或者分析表达的前后逻辑与关联。而这样做，通常有两个目的：　　找到对方表达的潜在含义与目的；　　找到对方叙述中的逻辑错误。　　第一个是支持者的心态，第二个则是反对者的心态。然而你应该知道，这两种心态就是一个会议的全部内容。　　所以你会发现，重要的人很少说话，而重要的会议所需要的发言也很少。这样的角色，或者这样的场合下的言论都是经过充分组织的。——只有这样的表达，才会更有效。　　我的老朋友Soul有一句名言：“对于两个聪明人来说，正确的结论通常只有一个。因此如果出现了争执，那么讨论的一定不是同一问题。”　　这句名言最关键之处，是在于它首先设定了“两个聪明人”为前提。然而实际交流中，事实上我们经常会主动地让这个前提不成立：我们通常会把对方当成白痴，试图说服对方支持你的“聪明观点”。　　所以我经常会读到一种文档，这种文档没有前提，没有概要，开始就说“我们如何做”或者“为什么我们要这样做”。你大概得在翻很多页后，才能找到一个结论：哦，原来那个家伙在说这件事。　　通常，如果一件事正确，那它就是正确的。无论你分析的过程如何，结论也“不过如此”。所以你应该把结论放在文档的前面，把指导性的原则放在更前面，把事件的前因与目标以概要的形式放在最前面。一个聪明人只需要200字就可以说完的一件事，同样另一个聪明人也只需要这200字就能理解。　　……

用户评论 (总计13条)

•   本来图书馆里有这本书的第三版（点评版），但还是没有磨灭我想买这书的冲动，书中内容简练中肯，看得出这是作者的经验所致，故事讲得很吸引眼球，从大家都熟知的故事说起，从中挖掘的出大道理，很好滴阐述了作者的著书目的——大道至简！书中文字简练而且所讲的篇幅不多，这点是我非常欣赏的，比起大篇幅的谈论这些理论，我更喜欢这样的文字描述，很快就可以看完，而且还有要读第二次的冲动！书中讲述的思想之类的，是做软件人很值得学习和借鉴的，就是为了简化诸多的流程，软件工程才应运而生！最重要的是本书的写作方式 差不多是有点参照项目管理的流程和思想来写就的，对于现在要学项目管理的我来说，是一本很不错的参考教材！
•   没工作经验，还没看懂。。。
•   无论是质量还是内容、都是精品
•   还可以吧，就是优点贵了
•   受益终生！
•   内容主要讲的是软件之道，融会贯通即可，不是讲具体的软件例子，挺好；印刷质量也不错
•   很不错的书，适合一读
•   软件工程实践者的思想
•   讲工程的
•   真是垃圾书
•   提供一种思维方式
•   相对于厚度来说，价格偏贵，但内容不错
•   嗯，很有名啊，慢慢看来，希望得到真理。