大道至简
作者：周爱民
Tag标签：无
用户评论 (总计27条)
- 最近把大道至简读了两遍，还是蛮多收获，总体的结构上以软件工程的构成为主线，但是单独一章的内容来讲，结构上稍微乱一点点，主要是谈个人的经验，所以毕竟每个人的感受都是不一样的，所以不可能面面俱到。 作者本人对技术有较深的研究，所以在读本书的过程中可以看出重视软件工程本身，而不是某一技术，印象最深的应该就是“知律而变”，应该知道原理，为什么要这样子。很多时候，我们在学习各种技术、各种方法的时候，都是 为了写文档而写文档、为了画图而画图、为了看上去好看而作各种各样的表格无用的东西，已表明我们掌握了各种技术方法，但是实际上发现实际的应用中很难有成效，很难实际应用。很多时候工作也需要做表面功夫，但是不能忘记本质，也不能以表面功夫为理由，忽略本质的东西，因为只有本质的东西才能积累。
- 第二次读这本书，感觉还是有些有用的团队思维和经验。
但是作者大部分篇幅的文字让人难以提炼观点，不知道想表达什么，不知是否作者有意为之，总之有违书名“大道至简”。愚公移山的故事引入也不知何意，生硬之感。
如果是3年前第一次看此书的我，可能给5分，因为我看不懂。 但是现在只有3分，也是因为我看不懂
- 前几章都不错，一直到第七章。
思绪有点乱乱的，从需求到管理到维护都讲了一些，泛泛的，不过还是很有启发，有必要阅读第二遍。
后面的几章没看懂，下次读第二遍的时候看看。后面说道人月神话，说道愚公银山。
另外一些点评感觉扯淡，不应该出现
- 从图书馆借的书，里面被”前辈“们用铅笔画的条条杠杠的，在107页的右侧几个非醒目的大字”什么逻辑？“
看样前辈与我也有相同的看法，里面的例子很多都比较牵强……例子有点生搬硬套，有时候就是甚至是在说解文字。。
不否认作者的论点，也肯定作者有很多年的经验，对很多东西有深刻的理解，但作为读者的我，却没能很好的吸收作者的思想及经验。。
读书的过程中，对soul比较感兴趣，不知道他写过书没？想读一读。。。
经常在群里面听到一些人说”牛人都是用记事本来写代码的“…… 我经常在心里自惭形秽一翻。。。。
作者也说到自己书中的例子90%是用记事本写出来的，额，这真是装B青年必备利器呀，我以后也可以在群里大喊，人家牛人写代码都用记事本的，谁还用IDE咧！
唉，说这例子感觉没必要吧，你写例子，人家是做大项目，如果还用记事本……唉！ 我还是无法想象。这有点误人子弟呀……
还有一些其它其它……
不过里面还是有些观点不错的：
/////////////////////////////////////////////
项目经理需要时间来成熟的。他需要机会来承受错误，而不是一开始就享受成功。
流于形式的沟通。
沟通的第一层障碍，并不在于你要表达的内容，而在于你如何表达。
最好在见客户之前，就已经设计了所有问题和提问方式，避免造成沟通不畅或流于形式的沟通。（即有目的性的沟通，而不是与客户交流感情）
留下历史记录，记录下自己的决策过程等，方便后来者。
如果你不懂甲骨文，那么也不要指望你的用户懂UML。
实现才是目的。实现是软件开发的本质需求。
成功的经验往往最不可信，反而是失败的经验更有价值。
经验，是源于对过去的思考，而不是对过去的复制。
团队要有远期的目标，有共同的愿景。对短期的目标也要清晰，即里程碑。
“教官”的任务：协调、督促、激励、监督和凝聚。
工作上，先人后已，即先为团队服务，然后自己再完成一些细节的事。奖励，同样也要“先人后已”。
要关注整体目标。从全局上把握，某一局部出现问题之后，要能尽快发现，并迅速调整。
不要压抑你团队成员的激情，他们提出自己的想法之后，要鼓励与引导，即使你认为不合理，或有错误，也要以引导的形式，或者干脆让他去犯这个“小错误”，从而让他在这个上面有更深刻的认识与印象。
软件工程层状模型(EHM)
工具，是为了更好的实现结果。 - 7年前的书了，还是让人很受教，所以说很多时候需要学的东西真的很多
纵观现在软件界，相当多的模式，流程，其实本质的还是PAET，只是瀑布模型的变形而已，把握住本质
关键是时刻要有做工程的心态去做，而不要沉迷于技术，方法这些枝叶中
但是还是要学习那些相关的模式之类的，只有学会了，才能更好的忽略掉+ - 感觉有些空洞，那个愚公移山的故事，怎么看都有穿凿的感觉。其实大道理谁都懂，关键在于是否真对实践有足够的指导，并且能与实践相结合。
和《程序员修炼之道》、《代码大全》、《编程匠艺》之类的书差距不小。 - 看惯了论坛上对语言的无聊争论，但是工作了，却从来没有碰到这样走火入魔者。
也许是大公司里的，未必能力有多高，但大都都有招招即使九曲八拐还是不离主题。对于公司的盈利亏损： I am just a worker. 能混即可，发财不靠工资。I am justa a manager, 我只希望手下的人越来越多。什么xp, scrum， I just care my position.
也许那些入魔者还期望通过入魔来提高个人能力，加入大公司，没有想到大公司里根本没有这种讨论。 - 感觉副标题很确切，就是在描述一个实践者的心路历程，内容还算不错。
然而，里面的古文引用是在令人发指，无法忍受。。 - 这是一本需要反复阅读的书，我获得此书是在几年前下载到的电子版。每过一段时间都会找出来在读一遍，每次都有新的收获。书中是作者在实践中总结的经验和道理。作者对软件工程相关的问题有许多感悟，并且能够生动的表达。这些实践当中的总结十分宝贵，所以我每过一段时间都要再读一遍，一边读一遍总结自己的工作，受益匪浅。可贵的是思想而不是生动的小例子，大家都的时候仔细体会背后的思想，一定有所启发。
- 写代码之能力有余而管理之心不足。总之感觉缺乏很多，个人深感空洞而不厚实。遂信意寻项目管理知识加以补充，无意间看到，阅后颇有所得，特此共鸣一下。
当软件进入大规模工程化的年代，很多东西开始进入了工程的范畴，那就意味着是软件不再是简单的编码和coding，不是一堆的类，而是融入了管理，计划，方法论等一系列工程化的project，所以，考虑之处不能不谓周全。这就需要管理者从编码的细节里面跳出来，站在更高的台阶上开始统筹和总览整个工程，并且加以合理的规划和控制。当然，你首先得有基础的经验，无论是来自于编码，还是来自于管理。
原始的：软件＝算法+数据结构。
在集成化开发的今天被修正为，项目＝程序＋方法＋过程＋管理（工程＋组织）。
团队是项目的执行和实现者，项目成为整个团队的目标，所以以目标为导向的项目管理。建立在工程方法论的基础之上的过程，用于控制整个产品的周期，成本，质量。而对于细节，那只是技术经理所要关注的事情，但是作为一个身兼技术和项目的经理，必须进行统筹和规划。作为一个小的团队，一人身兼两职，的确是一种高效方式，首先节约了沟通的成本，其次解决了技术和管理之间定制方案所产生的分歧的比例。这就要求团队的Leader拥有很高的素质，无论是在管理，还是在技术上。
作者对道家和儒家的思想很有研究，对史记和古文也有一定的涉猎，作为基础的思想核心，来推动作者对技术和管理孜孜不倦的思考和探求。在技术中做长时间，难免会沉浸在技术中不可自拔，有苦有乐，当作为一种爱好，定然是孜孜不倦，全凭兴致发挥。然而作为一个管理者，单凭技术和爱好不免难以应对来自管理和工程方面的知识和方法论。所以充电是必然，MBA也是必然。
在作者的后记中犹有会心一笑，可叹时间如此飞逝，光阴如此堕落，吾落后于人也。
- 最早是在北京清华园旁边的一个小书屋内看到这本书，当时就被书名所吸引，昨天终于花了一晚上的时间将整本书过了一遍。真正有用的道理通常都是朴素简单的，年龄越大越是能体会到这一点。《大道至简》里重提了《你的灯是亮的吗》中关于智慧是认识事物本实这一道理，这引导我们透过现象观到事物本身的目的和内在的联系、可以看出，作者在软件工程领域确实是有一定经验的，对中国古典文化亦多有涉猎，这让我对软件工程领域之人的思想可以略窥门径，正如作者所言，在软件工程领域，讲方法的书很多，但讲思想的书确是不宜寻见，权且作为抛砖引玉吧。
道可以是至简的，但寻道之旅却是复杂甚至是漫长的。 - 面对副标“软件工程实践者的思想”，反躬自省，读了太多理论，甚至都忘了实践。我们总对新技术新概念趋之若鹜，总不曾触及它们背后的“大道”。作者用愚公移山的故事贯穿全书，解说了“智”与“愚”。我以为，软件工程的核心就是高质量的完成项目，语言、工具、理论等等只是手段，是“做工程”而不是“做过程”。
大概是为了凑页数，略扁的字体让我觉得很不舒服。 - 第一眼看到它，就爱上它不是因为书本身，而是因为李维的那句书评。仔细阅读，发现作者真的沉淀了很多很多，学习技能固然重要，更重要的是学到优秀的思想！
- 作者总结的很好，其中的一些想法一看就是多年经验的沉淀，对大公司的战略的分析让我学到了很多，不可多得的好书!
- 含混不清，岂能坐而论道。
这种东西居然可以出版。
都是大忽悠。 多少无知读者被忽悠了啊。悲哀。
- 沟通的第一层障碍： 不在于沟通的内容，而在于如何沟通。
写的不错，有时说一个简单问题 别人听得稀里糊涂的。。。 - 每一本书都是作者总结实践成功或走向成功过程中失败而得到的，
随手记录下一些阅读中的心得:
记忆最深的就是他的EHM(Engine Hierarchy Model),一圈圈像牛粪:) 。
几个计算公式(一看就知道作者是逻辑思维严密的程序员)
程序=算法+结构
方法=面向过程/oop/mda
过程=RUP/XP 模型与建模语言
工程=需求管理+过程管理+配置管理+文档化
管理=管理+计划
其中:程序、方法是实现，过程、工程是团队，我猜测管理应当算是财务了把，把团队能用的资源进行限制。
团队说明: p70
1.方法和目标明确
2.团队并分工协作
3.能意识分享并有规避策略
态度必须认可，至于"想法好不好"是技术问题 p73
所谓矛盾，大多是自找的。 p79
伟大的球员和普通的球员的差别，就在于伟大的球员总是说:"这不是个问题"
项目经理关注成本,成本=时间+人力+资金+客户成本=客户数量+客户的耐心
p50 History可以用wiki来实现
p60 可以读一下朱湘的《画虎》，里面有非常棒的论花匠和画师
p65 一个团队的特质是管理者在团队生活和行为过程中逐渐形成的团队特质，成功的经验往往最不可信，失败的才最可信。
p67 对失败的案例进行分析，并于团队中的成员分享可能要好很多。
p104 对于工程来讲，能让团队理解，统一执行，迅速而有效的实战技法，才是真实所需的。
p105 惟手熟尔
p106 工而制具、工而制艺
p108 工具+技法>工程;良匠是一种好的品质。
p105 融通是基于对"使用工具的方法、理论"的了解，融同，则是对这个工具存在的本质价值的认识。
记录了一下自己阅读到的内容，记下了自己当时最有体会的一些内容。如果你认真做过项目，被管理过或者管理过他人，你对其中的话一定深有体会，作者还是认真写了的。
- 我正在看本书，其实我觉的这本书虽然简单，但它却把我们工作中一些抽象的概念讲的却很容易理解，我想这或许就是作者的根本意图所在。
- 如果这本书出版了，可能会骂声一片吧，不是说内容太差，而是这样的形式在这个年代不适合印成铅字，就像《Java夜未眠》一样，可能因为那本比较早，所以评价还可以吧。
每件作品能让受众经历之后记住一点可算是成功的了吧（除了放在手边的工具类书籍），这本书看了之后记住了那张关于程序，方法，过程，工程，组织的图片，那也是作者一瞬间的灵光，可惜这里不能贴图。
作者的网站是MSN spaces下的很慢，我传了一个在51Files上：http://www.51files.com/?72KZD1N7L7N52UC3UNCD。 - 最近也在读《最后期限》，相比之下，《最后期限》还是更合我的口味呀，写的又通俗易懂。所以，力荐《最后期限》
《大道至简》这本书，闲暇时间可以翻一翻，抓住里面的一些关键点就行了 - 我觉得用记事本写代码的意思是，无论何时何地都在思考，即使不在电脑旁边时，也随时利用身边的笔和纸演算设计。
- 哈哈，楼主我居然和你读了同一本书。。深圳南山图书馆。
- 喔，太有缘份了，是在南山图书馆。。。 呵呵
- 我没得这本书，哎..老师要我们写这本书的读书笔记。
- 《大道至简》和《你的灯是亮的吗》确实思想上是一致的。
我也推荐 《你的灯是亮的吗》 - 语言没有会不会，只有喜欢不喜欢
- 写的乱。