敏捷软件开发(原书第2版)
点击看大图
基本信息
- 原书名： Agile Software Development: The Cooperative Game (2nd Edition)
- 原出版社： Addison-Wesley Professional
- 作者： (美)Alistair Cockburn [作译者介绍]
- 译者： 苏敬凯
- 丛书名： 华章程序员书库
- 出版社：机械工业出版社
- ISBN：9787111231660
- 上架时间：2008-3-7
- 出版日期：2008 年1月
- 开本：16开
- 页码：388
- 版次：2-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 软件方法/软件工程
编辑推荐
第17届Jolt大奖获奖作品，大师Cockburn讲授敏捷开发之道。
“这是一本激动人心的书。作者以其丰富的实践经验，为我们提供了一部融合敏捷方法的力作。”
——Tom Gilb，著名的软件工程和系统工程专家
本书是国际知名软件开发专家Alistair Cockburn通过采访项目开发组和总结自己20多年的开发和管理经验，撰写的一本介绍软件开发新思想——敏捷软件开发方法学的著作。
本书从更新软件开发就是“创造和沟通的合作博弈”这一强大的模型开始。在这些新观念之中，Cockburn引入了：利用竞争产生动力而不破坏合作，从精益制造中学习教训以及为了沟通而平衡战略。作者还解释了如何在业务和工程项目上而不仅仅是在软件开发上进行合作博弈。
作者系统地演示了敏捷模型，展示了敏捷模型的演进，并且回答了开发人员和项目经理最常提出的问题，其中包括：
·哪些地方适合敏捷开发？
·如何将敏捷观念与其他观念融合在一起？
·如何对敏捷观念进行扩展？
书中呈现了造成很多敏捷项目失败的至关重要的错误概念。例如，将项目管理策略编码到固定的过程中会导致低效率的战略决策和高成本的错误。此外，本书还深入讨论了关于敏捷方法和用户体验设计之间的有争议的关系。
Cockburn讨论了为团队建立敏捷方法学这一实践上的挑战，解释了如何对方法学进行调整并持续地再创造，以及如何管理不完全的沟通。
第2版主要增加了以下内容：
·敏捷与CMMI。
·自顶向下地介绍敏捷。
·重访“客户合同”。
·用“贴纸”来创建变更。
另外，Cockburn还更新了关于Crystal方法学的讨论，这种方法利用了“合作博弈”作为其核心的隐喻。
无论是敏捷开发新手，还是有经验的软件开发人员和项目管理人员，都会从本书中受益。
内容简介回到顶部↑
本书提示了敏捷软件开发的真正内涵。全书以“软件是创造和沟通的合作博弈”为中心向读者展示一个看待软件开发的崭新视角。全书共13章，包括创造和沟通的合作博弈、个人、团队的沟通与合作、方法集、敏捷与自适应、以及crystal方法集等内容。
本书适合软件开发人员、管理人员、架构师等技术人员参考。
本书适合软件开发人员、管理人员、架构师等技术人员参考。
作译者回到顶部↑
本书提供作译者介绍
Alistair Cockburn，国际知名软件项目管理方面的专家，用例技术，对象技术和敏捷方法大师，于2001年和2002年两次获得Jolt生产力奖。他是Humans and Technology公司的資深顾问，负责帮助客户成功地进行面向对象项目。他在软硬件开发方面有20多年的项目管理经验，所涉及的领域有保险业，零售业，电子商务公司，并曾在大公司（如挪威中心银行和IBM）中任职。除本书外，他还著有《编写有效用例》（本书中文版已由机械工业出版社出版）、《OO项目求生法则》和《Crystal Clear：小团队的敏捷开发方法》。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
译者序
第2版前言
第1版前言
第0章 不可知和不可说
0.1 和解析体验相关的问题
0.1.1 解析模式的冲突
0.1.2 检测解析模式
0.1.3 思考不准确的思想
0.2 沟通的不可能性
0.2.1 内部重新组织
0.2.2 触及共享体验
0.2.3 管理不完美的沟通
0.3 聆听的三个层次
0.3.1 三个层次和方法集
0.3.2 三个层次与本书
0.3.3 守-破-离
0.4 那么，明天我做什么
第0a章 不可知和不可说：演进
0a.1 沟通和共享的体验
0a.2 守-破-离
第2版前言
第1版前言
第0章 不可知和不可说
0.1 和解析体验相关的问题
0.1.1 解析模式的冲突
0.1.2 检测解析模式
0.1.3 思考不准确的思想
0.2 沟通的不可能性
0.2.1 内部重新组织
0.2.2 触及共享体验
0.2.3 管理不完美的沟通
0.3 聆听的三个层次
0.3.1 三个层次和方法集
0.3.2 三个层次与本书
0.3.3 守-破-离
0.4 那么，明天我做什么
第0a章 不可知和不可说：演进
0a.1 沟通和共享的体验
0a.2 守-破-离
译者序回到顶部↑
作为《敏捷软件开发宣言》和《相互依赖声明》的合著者，Alistair Cockburn的这本书揭示了敏捷的真正内涵。.
“软件是创造和沟通的合作博弈”，这一隐喻向我们展示了一个看待软件开发的崭新视角，它告诉我们：软件开发的首要目标是交付有用、可工作的软件，次要目标是为下一轮博弈做好准备。因为“编程就是构建理论”，而“理论”中的大部分意会知识不能或很难用文档来传达，而要靠沟通来传达，所以提高信息沟通的效率就提高软件开发效率的最有效的方式。
人不是生产线上的智能机器，人的特点是：人在沟通、学习和解决问题方面都不同于智能机器。以管理生产设备的方式管理人，显然不能最大程度地发挥人的潜能。
软件开发团队是一个交付软件的生态系统。团队的成功依赖于合作、沟通和协调。方法集就是你的团队同意遵循的那些协约。不同的协约适合不同类型的项目，没有放之四海皆适用的方法集，设计方法集时要“针对情形而制定策略”。
敏捷意味着有效率并且灵活机动。敏捷的过程既轻量又充足，轻量使它机动灵活，充足使它能够继续进行博弈。要不厌其烦地进行反思，才能使方法集自适应。..
本书在论述敏捷软件开发的同时，还详细讲解了如何在团队内跨越沟通鸿沟交流信息，如何建设团队；以及方法集设计的常见错误和设计原则，敏捷的最佳击球点，在运行中构建和优化方法集，反思研讨会等内容。本书还详细讲解了XP和Crystal家族等敏捷方法集。
在书中，作者不仅把敏捷的思想推广到软件开发之外的领域，而且还深入地分析了对于敏捷的常见误解，全面回顾了各种敏捷方法集和理论的最新发展，并介绍了组织级敏捷方法集的设计，以及“最佳击球点和下降”、“敏捷与CMMI和ISO9001”等由来已久的问题。
本书的内容深厚宽广，论述每个问题时都提供了生动的例子或案例。本书的附录也不应被读者忽略，其中的《敏捷宣言》、《相互依赖声明》，还有宫本武藏的《五轮书》片段，都能很好地帮助读者理解敏捷、理解本书的内容。
感谢机械工业出版社华章公司的编辑一直以来对我们的翻译工作的支持和鼓励。能够翻译这样一本荣获Jolt大奖的书籍，是译者的荣幸。翻译本书的过程同时也是一个学习和提高的过程。
参加本书翻译的还有尚计升、史红伟、祝国志、张峰峰、张文军、张艳军、王小财和周宝华张勇、杜兴平、刘志飞、沈海峰、谢扣林、乔义峰、刘查强、王义强、刘国际、杨传辉、王建华、汪明军、朱兆涛、毛付安。由于时间仓促，译者水平有限，翻译的错误和不妥之处在所难免，欢迎广大读者批评指正。
译者于北京
2007年10月...
“软件是创造和沟通的合作博弈”，这一隐喻向我们展示了一个看待软件开发的崭新视角，它告诉我们：软件开发的首要目标是交付有用、可工作的软件，次要目标是为下一轮博弈做好准备。因为“编程就是构建理论”，而“理论”中的大部分意会知识不能或很难用文档来传达，而要靠沟通来传达，所以提高信息沟通的效率就提高软件开发效率的最有效的方式。
人不是生产线上的智能机器，人的特点是：人在沟通、学习和解决问题方面都不同于智能机器。以管理生产设备的方式管理人，显然不能最大程度地发挥人的潜能。
软件开发团队是一个交付软件的生态系统。团队的成功依赖于合作、沟通和协调。方法集就是你的团队同意遵循的那些协约。不同的协约适合不同类型的项目，没有放之四海皆适用的方法集，设计方法集时要“针对情形而制定策略”。
敏捷意味着有效率并且灵活机动。敏捷的过程既轻量又充足，轻量使它机动灵活，充足使它能够继续进行博弈。要不厌其烦地进行反思，才能使方法集自适应。..
本书在论述敏捷软件开发的同时，还详细讲解了如何在团队内跨越沟通鸿沟交流信息，如何建设团队；以及方法集设计的常见错误和设计原则，敏捷的最佳击球点，在运行中构建和优化方法集，反思研讨会等内容。本书还详细讲解了XP和Crystal家族等敏捷方法集。
在书中，作者不仅把敏捷的思想推广到软件开发之外的领域，而且还深入地分析了对于敏捷的常见误解，全面回顾了各种敏捷方法集和理论的最新发展，并介绍了组织级敏捷方法集的设计，以及“最佳击球点和下降”、“敏捷与CMMI和ISO9001”等由来已久的问题。
本书的内容深厚宽广，论述每个问题时都提供了生动的例子或案例。本书的附录也不应被读者忽略，其中的《敏捷宣言》、《相互依赖声明》，还有宫本武藏的《五轮书》片段，都能很好地帮助读者理解敏捷、理解本书的内容。
感谢机械工业出版社华章公司的编辑一直以来对我们的翻译工作的支持和鼓励。能够翻译这样一本荣获Jolt大奖的书籍，是译者的荣幸。翻译本书的过程同时也是一个学习和提高的过程。
参加本书翻译的还有尚计升、史红伟、祝国志、张峰峰、张文军、张艳军、王小财和周宝华张勇、杜兴平、刘志飞、沈海峰、谢扣林、乔义峰、刘查强、王义强、刘国际、杨传辉、王建华、汪明军、朱兆涛、毛付安。由于时间仓促，译者水平有限，翻译的错误和不妥之处在所难免，欢迎广大读者批评指正。
译者于北京
2007年10月...
前言回到顶部↑
2001年，软件开发的敏捷模型给世界带来了一场风暴。一年中，全世界出现了很多关于敏捷的著作和会议。在5年中，它影响了每一件事，从项目管理和公司经理们如何编写与客户的合同，到军事采购的过程，甚至到大学的课程。.
是该看一下都发生了什么变化的时候了，看一下我们能从敏捷模型和（更具普遍意义的）合作博弈中学到什么。
在2001年2月写《敏捷软件开发的宣言》的时候，我已经深入到了编写一本关于“软件开发就是合作博弈”和“剪裁方法集以适合不同的项目”的书之中。这一宣言只不过是对我和其他人已经在做的事情的附和。
敏捷模型给世界带来了风暴。数以百计的开发人员在网上的签名板上签名（最初的非正式的敏捷联盟，不要与后来成立的敏捷联盟公司相混淆，后者负责管理在美国的召开的敏捷大会），以表示他们与敏捷宣言的价值观和原则一致。
在最初的关于“这是什么意思？”的问题之后，人们会问：
·“它什么地方适合所有开发的各种情形？”
·“我们如何将这些思想与其他思想混合在一起？”
·“我们如何将这些思想扩展到其他领域？”
在第2版中，新增的文字就是来解决这些问题的。
合作博弈模型在与敏捷模型一起成长。最初构建它是为了解释软件开发，但它引起了商业人士的共鸣，他们肯定地发现：大多数商业也是一个创造和沟通的合作博弈（并且是一个竞争博弈）。
你可以想象的到，在过去的这5年里，有些事情的出现使我感到惊讶。我着重说四点：
·工程化也是一个创造和沟通的合作博弈。经过一番重新表达之后，我们现在可以将软件工程定位为工程化领域中严格意义上的一员。
在第2版中，我只字未改地保留了我最初写下的那些反对“将软件开发看作是工程”的思想的相当激烈的话。之所以这样做的原因是：对于大多数仍然错误地看待工程学的人来说，这些话仍然适用，它能把人们从相应的管理软件开发的错误方式中拉出来。在第2版的文字中，我把研究方向转回到“什么是工程化”的问题上。
在第二次世界大战之后，对于应用物理学的学科上的嫉妒造成了工程研究领域的一厢情愿的想法，对于工程学的流行的理解脱离了轨道。在重新研究了工程学实践之后，我们注意到：它本身就是一个创造和沟通的合作博弈。由此，我们可以创建一个更新版的软件工程的概念，它在实践上和教育学上都有意义。..
·在最近五年中，用户体验设计这一专业领域已经产生了强有力的扩展。过去，它被宣言的作者们忽略了，现在，它应该受到大家认真的关注。
所有这些早期的方法集都完全跳过了这一问题，可能是因为没有一个敏捷宣言的作者在这个领域有很强的专长。这个领域一直是并且还将继续是一个充满争议的领域，几乎没有可靠的结论。我将在这一节中讨论这些结论和争论的观点。
·我已经学会了如何将项目管理策略与方法集区分开。
我们往往会把项目管理的策略当作是公司的过程或方法集的一部分，这是错误的。把那些应当是根据具体情况而制定的策略编写成一个固定的政策，这往往会迫使管理者们制定出没有效率的策略决策，并极大地增加组织的成本。因此，学会区分这两者非常重要。
·更加令人惊讶的是：自从写作本书的第1版以来，围绕着本书（“敏捷软件开发”）的所有开发都发生了。
这意味着有很多需要讲述的话题，还有很多关于敏捷软件开发的含义和实践的误解需要澄清。
是该看一下都发生了什么变化的时候了，看一下我们能从敏捷模型和（更具普遍意义的）合作博弈中学到什么。
在2001年2月写《敏捷软件开发的宣言》的时候，我已经深入到了编写一本关于“软件开发就是合作博弈”和“剪裁方法集以适合不同的项目”的书之中。这一宣言只不过是对我和其他人已经在做的事情的附和。
敏捷模型给世界带来了风暴。数以百计的开发人员在网上的签名板上签名（最初的非正式的敏捷联盟，不要与后来成立的敏捷联盟公司相混淆，后者负责管理在美国的召开的敏捷大会），以表示他们与敏捷宣言的价值观和原则一致。
在最初的关于“这是什么意思？”的问题之后，人们会问：
·“它什么地方适合所有开发的各种情形？”
·“我们如何将这些思想与其他思想混合在一起？”
·“我们如何将这些思想扩展到其他领域？”
在第2版中，新增的文字就是来解决这些问题的。
合作博弈模型在与敏捷模型一起成长。最初构建它是为了解释软件开发，但它引起了商业人士的共鸣，他们肯定地发现：大多数商业也是一个创造和沟通的合作博弈（并且是一个竞争博弈）。
你可以想象的到，在过去的这5年里，有些事情的出现使我感到惊讶。我着重说四点：
·工程化也是一个创造和沟通的合作博弈。经过一番重新表达之后，我们现在可以将软件工程定位为工程化领域中严格意义上的一员。
在第2版中，我只字未改地保留了我最初写下的那些反对“将软件开发看作是工程”的思想的相当激烈的话。之所以这样做的原因是：对于大多数仍然错误地看待工程学的人来说，这些话仍然适用，它能把人们从相应的管理软件开发的错误方式中拉出来。在第2版的文字中，我把研究方向转回到“什么是工程化”的问题上。
在第二次世界大战之后，对于应用物理学的学科上的嫉妒造成了工程研究领域的一厢情愿的想法，对于工程学的流行的理解脱离了轨道。在重新研究了工程学实践之后，我们注意到：它本身就是一个创造和沟通的合作博弈。由此，我们可以创建一个更新版的软件工程的概念，它在实践上和教育学上都有意义。..
·在最近五年中，用户体验设计这一专业领域已经产生了强有力的扩展。过去，它被宣言的作者们忽略了，现在，它应该受到大家认真的关注。
所有这些早期的方法集都完全跳过了这一问题，可能是因为没有一个敏捷宣言的作者在这个领域有很强的专长。这个领域一直是并且还将继续是一个充满争议的领域，几乎没有可靠的结论。我将在这一节中讨论这些结论和争论的观点。
·我已经学会了如何将项目管理策略与方法集区分开。
我们往往会把项目管理的策略当作是公司的过程或方法集的一部分，这是错误的。把那些应当是根据具体情况而制定的策略编写成一个固定的政策，这往往会迫使管理者们制定出没有效率的策略决策，并极大地增加组织的成本。因此，学会区分这两者非常重要。
·更加令人惊讶的是：自从写作本书的第1版以来，围绕着本书（“敏捷软件开发”）的所有开发都发生了。
这意味着有很多需要讲述的话题，还有很多关于敏捷软件开发的含义和实践的误解需要澄清。
评论交流
共有36人开贴评论 63人参与评论 30人参与打分 查看
评价等级：
发表于：2008-3-22 9:14:00
我仔细读过第一版两遍，这一版读得很快，没有感觉翻译上有太大的问题。不太习惯的是，第一版将game翻译为“游戏”，第二版将其翻译为“博弈”。也许“博弈”更准确一些，不过“游戏”缓解了紧张的气氛。人生如戏么，软件即便重要，也要放松心态啊。
我刚开始看第二版的时候，有些惊讶。第二版只是在第一版的基础上补充了1/4篇幅的内容（第一版的内容基本保留），为什么能再次获得Jolt大奖？由于看得太快，只能提出两个感觉。
第一、作者将敏捷软件开发的基本思想扩展到更广大的领域。对传统工程进行了剖析，指出它们（航空大楼的建设、高速公路的架设）也可以从敏捷方法中获益。个人感觉这是工程方法研究的重要进展。
第二、作者根据5年来的进展进行了再反思。看看敏捷开发中，哪些变化了，哪些没有变化，是很有趣、也很有价值的。
我刚开始看第二版的时候，有些惊讶。第二版只是在第一版的基础上补充了1/4篇幅的内容（第一版的内容基本保留），为什么能再次获得Jolt大奖？由于看得太快，只能提出两个感觉。
第一、作者将敏捷软件开发的基本思想扩展到更广大的领域。对传统工程进行了剖析，指出它们（航空大楼的建设、高速公路的架设）也可以从敏捷方法中获益。个人感觉这是工程方法研究的重要进展。
第二、作者根据5年来的进展进行了再反思。看看敏捷开发中，哪些变化了，哪些没有变化，是很有趣、也很有价值的。
)
评价等级：
发表于：2008-7-15 9:40:00
马上就要把这本书读完了，才发现这里面的评论这么差，要是最初看到这些肯定不会买了，还好没有看到，让我看到了这么好的一本书。
这里面的人都是评论说这本书翻译的有多么多么的不好，我承认这本书翻译的是有一些让人们很难理解，但是我看上来还好了，语言只是一种表达方式罢了，只要理解里面的思想就好了，编程序也是一种思想转化的过程。这个时候的情形和我05年读《人件》时候的情形差不多，人们刚开始都是评论书翻译的有多差，但是现在大家看看这本书的评论，可是说是平反了，好书永远不会被人遗忘的。我承认这本书的英文版确实可以用著作来形容，但是本人的英语能力实在有限，所以只有看翻译版本，我从不认为这本书翻译得很差。
这本书作者的思想是我一直想要在软件开发中达到的，就是如游戏一样进行软件开发，但是这个不可能的，怎么能够接近这个效果呢？作者向我们解释了什么是敏捷，什么样的团队才是敏捷，以一个敏捷宣言的撰写人角度来为我们诠释了里面的理论。这是一本理论性很强的书，有的看完可能会向我该怎么做？书里面确实花了大量的篇幅来说明理论，只有在最后的一章才介绍他的Crystal方法集。这个就如同哲学的世界观和方法论，前面的理论就是世界观，当你的世界观已经理解了敏捷是什么之后，方法论只是在面对问题的一种解决方法罢了。
我还喜欢这本书的一个原因是，这本书辩证的看待了现代流行的方法集，列出了这些方法集适应和不适应的团队，和在这些团队应该注意的事情。很喜欢作者的那个项目的网格。像作者把XP列为他的D6级别里面，也就是适合6个人完成没有生命危险的项目中；作者还对Scrum和自己的Crystal方法集都进行很好的研究。这本书作者只研究了在一个地点工作的团队如何应用敏捷，没有考虑分布式团队如何应用敏捷，这个确实很难，但是推动软件发展还是那些大型的软件公司，基本上都是采用分布式的团队管理来降低成本的，这个是这本书的局限。
很喜欢做的写作方式，每一章之后的演进都很好，让我能够很好的理解这一章的理论，这种布局谋篇很值得借鉴。
作为一个软件开发者来说，能够看到这么一本令我兴奋的书，我很高兴了，也很高兴没有看到这里面的评论。这是一本值得反复琢磨的书。
看自己的书，让别人评论去吧。
这里面的人都是评论说这本书翻译的有多么多么的不好，我承认这本书翻译的是有一些让人们很难理解，但是我看上来还好了，语言只是一种表达方式罢了，只要理解里面的思想就好了，编程序也是一种思想转化的过程。这个时候的情形和我05年读《人件》时候的情形差不多，人们刚开始都是评论书翻译的有多差，但是现在大家看看这本书的评论，可是说是平反了，好书永远不会被人遗忘的。我承认这本书的英文版确实可以用著作来形容，但是本人的英语能力实在有限，所以只有看翻译版本，我从不认为这本书翻译得很差。
这本书作者的思想是我一直想要在软件开发中达到的，就是如游戏一样进行软件开发，但是这个不可能的，怎么能够接近这个效果呢？作者向我们解释了什么是敏捷，什么样的团队才是敏捷，以一个敏捷宣言的撰写人角度来为我们诠释了里面的理论。这是一本理论性很强的书，有的看完可能会向我该怎么做？书里面确实花了大量的篇幅来说明理论，只有在最后的一章才介绍他的Crystal方法集。这个就如同哲学的世界观和方法论，前面的理论就是世界观，当你的世界观已经理解了敏捷是什么之后，方法论只是在面对问题的一种解决方法罢了。
我还喜欢这本书的一个原因是，这本书辩证的看待了现代流行的方法集，列出了这些方法集适应和不适应的团队，和在这些团队应该注意的事情。很喜欢作者的那个项目的网格。像作者把XP列为他的D6级别里面，也就是适合6个人完成没有生命危险的项目中；作者还对Scrum和自己的Crystal方法集都进行很好的研究。这本书作者只研究了在一个地点工作的团队如何应用敏捷，没有考虑分布式团队如何应用敏捷，这个确实很难，但是推动软件发展还是那些大型的软件公司，基本上都是采用分布式的团队管理来降低成本的，这个是这本书的局限。
很喜欢做的写作方式，每一章之后的演进都很好，让我能够很好的理解这一章的理论，这种布局谋篇很值得借鉴。
作为一个软件开发者来说，能够看到这么一本令我兴奋的书，我很高兴了，也很高兴没有看到这里面的评论。这是一本值得反复琢磨的书。
看自己的书，让别人评论去吧。
评价等级：
发表于：2008-3-26 14:24:00
近日我与我的一位学术部的主管闲谈什么样的书才是好书，我问他：很多人看不懂的一本书，你说这本书是好是坏？他告诉我，一本书的好与坏，要看能不能真正从书中学到知识，变为实践。看不懂的原因，也许是内容不好，也许是读者自身的理解水平不高，不然要老师有什么用！一句玩笑话，却说到点子上。说到评论，他建议我去网上看看图书评论，便给了我这本书的地址，因为他打算购买，却被评论搞晕了头。我看了这些评论，觉得很可笑，笑我的这位主管会被这种三俗的评论搞晕了头。我注意到，凡是客观的评论，且不谈褒贬，观点都在理上。但有些恶搞的评论，幼稚的可笑。有位出版业的朋友告诉我，有一种人，他们总是惯用很刻薄的语言攻击发表好评的人，说好评是出版社自己写的，而攻击者发表的内容也千篇一律，无外乎是给书挑刺，却无半点见术，他们实际上连书都没看过，朋友告诉我，这种惟恐天下不乱的攻击，其实是对手操作的。我不太了解出版业，所以不敢全信，我相信的确存在一些读者对书或者作者有不同的意见，若没有，就不正常了。但是表达的方式不应如此畸形。几年前我曾经与国家文物局王司长聊过中国古建筑，硬批社会对于中国固有的建筑及其附艺多加以普遍的摧残，西式楼房盛行于通商大埠以来，他们虽不是蓄意将中国建筑完全毁灭，而在事实上，国内原有很精美的建筑物多被拙劣幼稚的所谓西式楼房或门面取而代之，纯中国式之秀美或壮伟的旧市容也已然被非艺术之建筑所取代。想想谁之过？自己能力有限，当之不敢再批建史，踏踏实实为上策。中国的IT业，缺的是人才！不是口才！我若有能力，定要继承中国建筑之传统，我有吗？我有的是自知之明，所以我闭嘴！到不是体现我个人素质，因为我在文化人眼中，是个纯种的流氓。以Dearwolf为代表的这类IT专家，我想一定会有他们自己的见解，IT这个领域我是门外汉，所以我没有资格告诉这些专家应该怎么做，但提到人的格局，我以为，对事不对人，自己有见解很好，但应该用于实践，做出成绩，证实自己，反到更有说服力。网上的偏激，更像自我炒作，正面效果没有，反而对很多正在学习的入门者产生负面影响，如果这样，这类专家就是罪人了。我相信要当流氓，这类专家一定不如我专业，黑社会都是很低调的。如果素质再不如我，那真的是枉费有限的网络资源了。中国有句古话，叫以德服人，什么意思，自己琢磨去。
加载中...| 我要写评论 |
| 查看所有评论交流(共36条) |
