<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Tairan&#039;s Story &#187; 精彩文章</title>
	<atom:link href="http://www.tairan.net/index.php/category/reference/mvp-article/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.tairan.net</link>
	<description>「知之真切笃实处即是行，行之明觉精察处即是知，知行工夫不可离。」</description>
	<lastBuildDate>Fri, 02 Dec 2011 08:08:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
		<item>
		<title>如何成为一名黑客</title>
		<link>http://www.tairan.net/index.php/2009/09/18/how-to-become-a-hacker/</link>
		<comments>http://www.tairan.net/index.php/2009/09/18/how-to-become-a-hacker/#comments</comments>
		<pubDate>Fri, 18 Sep 2009 11:00:39 +0000</pubDate>
		<dc:creator>Daniel Wang</dc:creator>
				<category><![CDATA[Technology 转载]]></category>
		<category><![CDATA[参考消息]]></category>
		<category><![CDATA[精彩文章]]></category>
		<category><![CDATA[Hacker]]></category>

		<guid isPermaLink="false">http://www.tairan.net/?p=636</guid>
		<description><![CDATA[如何成为一名黑客 原版在这里http://catb.org/~esr/faqs/hacker-howto.html Copyright © 2001 by Eric S. Raymond 译文来自这里 http://www.aka.org.cn/Docs/hacker-howto_2001.html 翻译：Barret 允许未经作者及译者的同意进行非商业目的的转载，但必须保持原文的完整性。 内容一览 为什么会有这份文档？ 什么是黑客？ 黑客应有的态度 黑客的基本技能 黑客文化中的地位 黑客和书呆子(Nerd)的联系 风格的意义 其它资源 FAQ（常问问题解答） 为什么会有这份文档？ 作为 Jargon File 的编辑和一些其他有名的类似性质文章的作者，我经常收到充满热情的网络新手的email提问（确实如此） “我如何才能成为一名出色的黑客？”非常奇怪的是似乎没有任何的FAQ或者Web形式的文档来说明这个十分重要的问题，因此我写了一份。 如果你现在读的是这份文档的离线拷贝，那么请注意当前最新版本（英文版）在 http://www.tuxedo.org/~esr/faqs/hacker-howto.html可以得到。 注意：在这份文档最后有 FAQ（常问问题解答）。请在向我提出任何关于这份文档的疑问之前读两遍。 目前这份文档有很多翻译版本： 保加利亚语， 简体中文， 繁体中文， 丹麦语， 荷兰语， 法语， 德语， 匈牙利语， 印尼语， 日语， 朝鲜语， 葡萄牙语， 俄语及 瑞典语。注意由于这份文档时有修正，所以以上翻译版本可能有不同程度的过时。 什么是黑客？ Jargon File 包含了一大堆关于“hacker”这个词的定义，大部分与技术高超和热衷解决问题及超越极限有关。但如果你只想知道如何 成为 一名黑客，那么只有两件事情确实相关。 这可以追溯到几十年前第一台分时小型电脑诞生, [...]]]></description>
			<content:encoded><![CDATA[<p>如何成为一名黑客 原版在这里<a href="http://catb.org/~esr/faqs/hacker-howto.html" target="_blank">http://catb.org/~esr/faqs/hacker-howto.html</a></p>
<p>Copyright © 2001 by Eric S. Raymond</p>
<p>译文来自这里 <a href="http://www.aka.org.cn/Docs/hacker-howto_2001.html" target="_blank">http://www.aka.org.cn/Docs/hacker-howto_2001.html</a></p>
<p>翻译：Barret</p>
<p>允许未经作者及译者的同意进行非商业目的的转载，但必须保持原文的完整性。</p>
<p>内容一览<br />
为什么会有这份文档？<br />
什么是黑客？<br />
黑客应有的态度<br />
黑客的基本技能<br />
黑客文化中的地位<br />
黑客和书呆子(Nerd)的联系<br />
风格的意义<br />
其它资源<br />
FAQ（常问问题解答）</p>
<p><strong>为什么会有这份文档？</strong></p>
<p>作为 Jargon File 的编辑和一些其他有名的类似性质文章的作者，我经常收到充满热情的网络新手的email提问（确实如此） “我如何才能成为一名出色的黑客？”非常奇怪的是似乎没有任何的FAQ或者Web形式的文档来说明这个十分重要的问题，因此我写了一份。</p>
<p>如果你现在读的是这份文档的离线拷贝，那么请注意当前最新版本（英文版）在 http://www.tuxedo.org/~esr/faqs/hacker-howto.html可以得到。</p>
<p>注意：在这份文档最后有 FAQ（常问问题解答）。请在向我提出任何关于这份文档的疑问之前读两遍。</p>
<p>目前这份文档有很多翻译版本： 保加利亚语， 简体中文， 繁体中文， 丹麦语， 荷兰语， 法语， 德语， 匈牙利语， 印尼语， 日语， 朝鲜语， 葡萄牙语， 俄语及 瑞典语。注意由于这份文档时有修正，所以以上翻译版本可能有不同程度的过时。</p>
<p><strong>什么是黑客？</strong></p>
<p>Jargon File 包含了一大堆关于“hacker”这个词的定义，大部分与技术高超和热衷解决问题及超越极限有关。但如果你只想知道如何 成为 一名黑客，那么只有两件事情确实相关。</p>
<p>这可以追溯到几十年前第一台分时小型电脑诞生, ARPAnet 实验也刚展开的年代，那时有一个由程序设计专家和网络名人所组成的, 具有分享特点的文化社群。这种文化的成员创造了 “hacker” 这个名词。黑客们建立了 Internet。黑客们发明出了现在使用的 UNIX 操作系统。黑客们使 Usenet 运作起来， 黑客们让 WWW 运转起来。如果你是这个文化的一部分，如果你对这种文化有所贡献，而且这个社群的其它成员也认识你并称你为 hacker, 那么你就是一位黑客。</p>
<p>黑客精神并不仅仅局限在软件的黑客文化中。有人用黑客态度对待其它事情，如电子学和音乐—— 事实上，你可以在任何最高级别的科学和艺术活动中发现它。精于软件的黑客赞赏这些在其他领域的同类并把他们也称作黑客—— 有人宣称黑客天性是绝对独立于他们工作的特定领域的。 但在这份文档中，我们将注意力集中在软件黑客的技术和态度，以及发明了“黑客”一词的以共享为特征的文化传统之上。</p>
<p>有一群人大声嚷嚷着自己是黑客，但他们不是。他们（主要是正值青春的少年）是一些蓄意破坏计算机和电话系统的人。真正的黑客把这些人叫做“骇客”(cracker)，并不屑与之为伍。多数真正的黑客认为骇客们又懒又不负责任，还没什么大本事。专门以破坏别人安全为目的的行为并不能使你成为一名黑客， 正如用铁丝偷开走汽车并不能使你成为一个汽车工程师。不幸的是，很多记者和作家往往错把“骇客”当成黑客；这种做法一直使真正的黑客感到恼火。</p>
<p><strong>根本的区别是：黑客搞建设，骇客搞破坏。</strong></p>
<p>如果你想成为一名黑客，请接着读下去。如果你想做一个骇客，去读 alt.2600 新闻组，并在意识到你并不像自己想象的那么聪明后去坐五到十次监狱。关于骇客，我只想说这么多。<br />
黑客应有的态度</p>
<p>黑客们解决问题，建设事物，同时他们崇尚自由和无私的双向帮助。要被他人承认是一名黑客，你的行为得体现出你好像具备了这种态度一般。而要想做得好象你具备这种态度一般，你就得切切实实坚持它。</p>
<p>但是如果你认为培养黑客态度只是一条在黑客文化圈中得到承认的路子，那就大错特错了。成为具备这些特质的这种人对 你自己非常重要——有助于你学习，及给你提供源源不断的动力。同所有创造性的艺术一样，成为大师的最有效方法就是模仿大师的精神—— 不仅从智力上，也要从感情上进行模仿。</p>
<p>或许, 下面这首现代的禅诗很好的阐述了这个意思：</p>
<p>  <strong>  To follow the path:（沿着这样一条道路：）<br />
    look to the master,（寻找大师，）<br />
    follow the master,（跟随大师，）<br />
    walk with the master,（与大师通行，）<br />
    see through the master,（洞察大师，）<br />
    become the master.（成为大师。）</strong></p>
<p>嗯，如果你想成为一名黑客，反复读下面的事情直至你相信它们：</p>
<p><strong>1. 世界充满了待解决的迷人问题。</strong></p>
<p>做一名黑客会有很多乐趣，但却是要费很多气力方能得到的乐趣。 这些努力需要动力。成功的运动员从锻炼身体、超越自我极限的愉悦中得到动力。同样，做黑客，你得能从解决问题，磨练技术及锻炼智力中得到基本的乐趣。</p>
<p>如果你还不是天生的这类人又想做黑客，你就要设法成为这样的人。否则你会发现，你的黑客热情会被其他分心的事物吞噬掉——如金钱、性和社会上的虚名。</p>
<p>（同样你必须对你自己的学习能力建立信心——相信尽管当你对某问题近乎一无所知，但只要你一点一点地试验、学习，最终会掌握并解决它。）</p>
<p><strong>2. 一个问题不应该被解决两次。</strong></p>
<p>聪明的脑袋是宝贵的有限的资源。当世界还充满非常多有待解决的有趣的新问题时，它们不应该被浪费在重新发明轮子这类事情上。</p>
<p>作为一名黑客，你必须相信其他黑客的思考时间是宝贵的——因此共享信息，解决问题并发布结果给其他黑客几乎是一种道义，这样其他人就可以去解决 新问题而不是不断地忙于对付旧问题。</p>
<p>(你不必认为一定要把你 所有的发明创造公布出去，但这样做的黑客是赢得大家极度尊敬的人。卖些钱来养家糊口，租房买计算机甚至发大财和黑客价值观也是相容的，只要你别忘记你还是个黑客。)</p>
<p><strong>3. 无聊和乏味的工作是罪恶。</strong></p>
<p>黑客（泛指具有创造力的人们）应该从来不会被愚蠢的重复性劳动所困扰，因为当这种事情发生时就意味着他们没有在做只有他们才能做的事情—— 解决新问题。这样的浪费伤害每一个人。因此，无聊和乏味的工作不仅仅是令人不舒服而已，而且是罪恶。</p>
<p>作为一个黑客，你必须坚信这点并尽可能多地将乏味的工作自动化，不仅为你自己，也为了其他人（尤其是其他黑客们）。</p>
<p>(对此有一个明显的例外。黑客有时也做一些在他人看来是重复性或枯燥的工作以进行“脑力休息”，或是为了获得某种技能，或是获得一些除此以外无法获得的特别经验。但这是自愿的——有脑子的人不应该被迫做无聊的活儿。）</p>
<p><strong>4. 自由万岁。</strong></p>
<p>黑客们是天生的反独裁主义者。任何能向你发命令的人能够迫使你停止解决令你着迷的问题，同时，按照独裁者的一般思路，他通常会给出一些极端愚昧的理由。因此，不论何处，任何独裁主义的作法，只要它压迫你和其他黑客，你就要和它斗到底。</p>
<p>(这并非向所有权威挑战。儿童需要监护，罪犯要被看管起来。 如果服从命令得到某种东西比起用其他方式得到它更节约时间，黑客可以同意接受某种形式的权威。但这是一个有限度的，有意的交易；那种权威想要的个人服从不是你应该同意给予的。)</p>
<p>权威喜欢审查和保密。他们不信任自愿的合作和信息的共享—— 他们只喜欢由他们控制的所谓“合作”。因此，作为一个黑客，你得对审查、保密，以及使用武力或欺骗去压迫有行为能力的人们的做法有一种本能的敌意。同时你要有为此信念斗争的意愿。</p>
<p><strong>5. 态度不能替代能力。</strong></p>
<p>作为一名黑客，你必须培养起这些态度。但只具备这些态度并不能使你成为一名黑客，也不能使你成为一个运动健将和摇滚明星。成为一名黑客需要智力，实践，奉献精神和辛苦工作。</p>
<p>因此，你必须学会怀疑，并尊重各种各样的能力。黑客们不会为那些装模做样的人浪费时间，但他们却非常尊重能力—— 尤其是从事黑客工作的能力，不过任何能力总归是好的。具备很少人能具备的那些方面的能力尤其好，其中具备涉及脑力、技巧和专注方面能力的当然最好。</p>
<p>尊敬能力，你就会享受到提高自己能力的乐趣—— 辛苦的工作和奉献会变成一种高度娱乐而非苦差事。要想成为一名黑客，这一点非常重要。</p>
<p><strong>黑客的基本技能</strong></p>
<p>黑客态度重要，但技术更加重要。态度无法替代技术，在你被别的黑客称为黑客之前，有一些基本的技术你必须掌握。</p>
<p>这些基本技术随着新技术的出现和老技术的过时也随时间在缓慢改变。例如，过去内容包括使用机器语言编程，而直到最近才包括了HTML。总的来说现在主要包括以下技术：</p>
<p><strong>1. 学习如何编程。</strong></p>
<p>这当然是最基本的黑客技能。如果你还不会任何编程语言，我建议你从Python开始。它设计清晰，文档齐全，合适初学者入门。它是一门很好的入门语言，并且不仅仅只是个玩具；它非常强大、灵活，也适合做大型项目。我有一篇 Python评价详细说明这点。好的 教程 可以在Python网站得到。（译者：比较好的中文Python站点可能是http://pythonrecord.51.net。）</p>
<p>Java也是好的入门语言。它比Python难得多，但是生成的代码速度也快得多。它同时也是一种优秀的计算机语言，不止是用来入门。</p>
<p>但是注意，如果你只会一两门语言，你将不会达到黑客所要求的技术水平，甚至也不能达到一个程序员的水平——你需要学会如何以抽象的方式思考编程问题，独立于任何语言。要做一名真正的黑客，你需要学会在几天内通过一些手册，结合你现在所知，迅速掌握一门新语言。这意味着你应该学会几种截然不同的语言。</p>
<p>如果要做一些重要的编程工作，你将不得不学习C语言，Unix的核心语言。 C++与C非常其他类似；如果你了解其中一种，学习另一种应该不难。但这两种都不适合编程入门者学习。而且事实上，你越避免用C编程，你的工作效率会越高。</p>
<p>C非常有效率，节约你的机器资源。不幸的是，C的高效是通过你手动做很多底层的管理（如内存）来达到的。底层代码都是复杂极易出现bug的，会使你花极多的时间调试。如今的机器速度如此之快，这通常是得不偿失——比较明智的做法是使用一种运行较慢、较低效率，但大幅节省你的时间的语言。因此，选择Python。</p>
<p>其他对黑客而言比较重要的语言包括 Perl和 LISP。 Perl实用，值得一学；它被广泛用于动态网页和系统管理，因此即便你从不用Perl写程序，至少也应该学会看。许多人使用Perl的理由和我建议你使用Python的理由一样，都是为了避免用C完成那些不需要C高效率的工作。你会需要理解那些工作的代码的。</p>
<p>LISP值得学习的理由不同——最终掌握了它时你会得到丰富的启迪和经验。这些经验会使你在以后的日子里成为一个更好的程序员，即使你实际上很少使用LISP本身。</p>
<p>当然，实际上你最好五种都会（Python，Java，C/C++，Perl和LISP）。除了是最重要的黑客语言外，它们还代表了截然不同的编程思路和方法，每种都会让你受益非浅。</p>
<p>这里我无法给你完完全全的指导教会你如何编程——这是个复杂的技能。但我可以告诉你，书本和上课也不能作到（最好的黑客中，有许多，也许 几乎都是自学成材的）。你可以从书本上学到语言的特点——只是一些皮毛，但要使书面知识成为自身技能只能通过实践和虚心向他人学习。因此要作到 （一）读代码及（二）写代码。</p>
<p>学习如何编程就象学习用优美的自然语言写作一样。最好的做法是读一些大师的名著，试着自己写点东西，再读些，再写点，再读些，再写点…… 如此往复，直到你的文章达到你体会到的范文的简洁和力量。</p>
<p>过去找到适合阅读的好的代码是困难的，因为几乎没有大型程序的源代码能让新手练手。这种状况已经戏剧性地发生变化；开放源代码软件，编程工具和操作系统（全都由黑客写成）现在已经随处可见。让我们在下一个话题中继续讨论……</p>
<p><strong>2. 得到一个开放源代码的Unix并学会使用、运行它。</strong></p>
<p>我假设你已经拥有或者能使用一台个人电脑（今天的孩子们真幸福 <img src='http://www.tairan.net/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />  ）。新手们能够朝学习黑客技能迈出的最基本的一步就是得到一份Linux或BSD-Unix的一种，安装在个人电脑上，并运行它。</p>
<p>没错，这世界上除了Unix还有其他操作系统。但它们都是以二进制形式发布的——你无法读到它的源代码，也不可能修改它。尝试在运行DOS或Windows或MacOS的机器上学习黑客技术，就象是带着脚镣学跳舞。</p>
<p>除此之外，Unix还是Internet的操作系统。你可以学会上网却不知道Unix，但你不了解Unix就无法成为一名Internet黑客。因此，今天的黑客文化在很大程度上是以Unix为中心的。（这点并不总是真的，一些很早的黑客对此一直很不高兴，但Unix和Internet之间的联系已是如此之强，甚至连Microsoft也无可奈何。）</p>
<p>所以, 安装一套UNIX——我个人喜爱LINUX但还有其他种类的（是的，你可以同时安装Linux及DOS/Windows在同一电脑上)。学习它，使用它，配置它。用它在Internet上冲浪。阅读它的源代码。修改它的源代码。你会得到比在Microsoft操作系统上更好的编程工具（包括C，LISP，Python及Perl）。你会觉得乐趣无穷，学到在你成为大师之前意识不到的更多的知识。</p>
<p>想知道更多关于学习Unix的信息，访问 The Loginataka。</p>
<p>想知道如何得到一份Linux，访问 我在哪里可以获得Linux。（译者：对于中文读者来讲，最简单的方式未过于前往附近的D版/正版光盘店。）</p>
<p>你可以在 www.bsd.org找到BSD Unix的求助及其他资源。</p>
<p>我有写一篇关于 Unix和Internet基础的入门文章。</p>
<p>（注：如果你是一个新手，我不推荐自己独立安装Linux或者BSD。安装Linux的话，寻求本地Linux用户组的帮助；或联系 Open Projects Network。 LISC维护着一些 IRC频道，在那里你可以获得帮助。）</p>
<p><strong>3. 学会如何使用WWW和写HTML</strong></p>
<p>黑客文化建造的大多东西都在你看不见的地方发挥着作用，帮助工厂、办公室和大学正常运转，表面上很难看到它对非黑客的普通人的生活的影响。Web是一个大大的例外。即便政客也同意，这个巨大耀眼的黑客玩具正在改变整个世界。单是这个原因（还有许多其它的），你就需要学习掌握Web。</p>
<p>这并不是仅仅意味着如何使用浏览器（谁都会），而是要学会如何写HTML， Web的标记语言。如果你不会编程，写HTML会教你一些有助于学习的思考习惯。因此，先完成一个主页。（网上有很多好的教程； 这是一个。)</p>
<p>但仅仅拥有一个主页不能使你成为一名黑客。 Web里充满了各种网页。大多数是毫无意义的，零信息量垃圾——界面时髦的垃圾，注意，垃圾的水准都类似（更多信息访问 The HTML Hell Page）。</p>
<p>要想有价值，你的网页必须有内容—— 它必须有趣或对其它黑客有帮助。这是下一个话题所涉及的……</p>
<p><strong>4. 如果你不懂实用性的英语，学习吧。</strong></p>
<p>作为一个美国人和一个以英语为母语的人，我以前很不情愿提到这点，免得成为一种文化上的帝国主义。但相当多以其他语言为母语的人一直劝我指出这一点，那就是英语是黑客文化和Internet的工作语言，你需要懂得以便在黑客社区顺利工作。</p>
<p>这一点千真万确。大概1991年的时候我就了解到许多黑客在技术讨论中使用英语，甚至当他们的母语都相同，英语对他们而言只是第二语言的时候；据我知道的报导，当前英语有着比其他语言丰富得多的技术词汇，因此是一个对于工作来说相当好的工具。基于类似的原因，英文技术书籍的翻译通常不令人满意（如果有翻译的话）。</p>
<p>Linus Torvalds，一个芬兰人，用英语注释他的代码（很明显这对他来说不是凑巧）。他流利的英语成为他能够管理全球范围的Linux开发人员社区的重要因素。这是一个值得学习的例子。<br />
黑客文化中的地位</p>
<p>象大部分不涉及金钱的文化一样，黑客王国靠声誉运转。你设法解决有趣的问题，但它们到底多有趣，你的解法有多好，是要由那些和你具有同样技术水平的人或比你更厉害的人去评判的。</p>
<p>相应地，当你在玩黑客游戏时，你得认识到你的分数主要靠其他黑客对你的技术的评价给出（这就是为什么只有在其它黑客称你为黑客时，你才算得上是一名黑客）。这个事实常会被黑客是一项孤独的工作这一印象所减弱；也会被另一个黑客文化的禁忌所减弱（现在逐渐减弱但仍强大）：拒绝承认自我或外部评估与一个人的动力有关系。</p>
<p>特别地，黑客王国被人类学家们称为一种奉献文化。 在这里你不是凭借你对别人的统治来建立地位和名望，也不是靠美貌，或拥有其他人想要的东西，而是靠你的奉献。尤其是奉献你的时间，你的创造和你的技术成果。</p>
<p>要获得其他黑客的尊敬，基本上有五种事情你可以干：</p>
<p><strong>1. 写开放源代码软件</strong></p>
<p>第一个（也是最集中的和传统的）是写些被其他黑客认为有趣或有用的程序，并把程序源代码提供给整个黑客文化使用。</p>
<p>（过去我们称之为“free software （自由软件）”，但这却使很多不知 free 的精确含义的人感到困惑。现在我们很多人，根据搜索引擎网页内容分析至少有2：1的比率，使用“ open-source”software（开放源代码软件）这个词）。</p>
<p>黑客王国里最受尊敬的偶像是那些写了大型的、好用的、具有广泛用途的软件，并把它们公布出去，使得每人都在使用他软件的人。</p>
<p><strong>2. 帮助测试并调试开放源代码软件</strong></p>
<p>黑客也尊敬那些使用、测试开放源代码软件的人。在这个并非完美的世界上，我们不可避免地要花大多数的开发时间在调试阶段。 这就是为什么任何有头脑的开放源代码的作者都会告诉你好的beta测试员（知道如何清楚描述出错症状，很好地定位错误，能忍受快速发布中的bug，并且愿意使用一些简单的诊断工具）象红宝石一样珍贵。 甚至他们中的一个能判断出哪个测试阶段是延长的，哪个是令人精疲力尽的噩梦，哪个只是一个有益的小麻烦。</p>
<p>如果你是个新手，试着找一个你感兴趣的正在开发的程序，做一个好的beta测试员。你会自然地从帮着测试，进步到帮着抓臭虫，到最后帮着改程序。你会从中学到很多，并且与未来会帮你的人结下友谊。</p>
<p><strong>3. 公布有用的信息</strong></p>
<p>另一个好事是收集整理有用有趣的信息做成网页或文档如FAQ列表，且让他们容易获得。</p>
<p>主要技术FAQ的维护者受到几乎同其他开放源代码的作者一样多的尊敬。</p>
<p><strong>4. 帮助维护基础设施的运转</strong></p>
<p>黑客文化（还有Internet的工程方面的发展，就此而言）是靠自愿者运转的。要使Internet能正常工作，就要有大量枯燥的工作不得不去完成——管理mail list，新闻组，维护大型软件库，开发RFC和其它技术标准等等。</p>
<p>做这类事情的人会得到很多尊敬，因为每人都知道这些事情是十分花时间又不象编程那样好玩。做这些事情需要奉献精神。</p>
<p><strong>5. 为黑客文化本身服务</strong></p>
<p>最后，你可以为这个文化本身做宣传（例如，象我这样，写一个“如何成为黑客”的正面的教程 <img src='http://www.tairan.net/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />  ）（译者：不知道Barret把它翻成中文算不算？）。这并非一定要在你已经在这个圈子呆了很久，因以上四点中的某点而出名，有一定声誉后才能去做。</p>
<p>黑客文化没有领袖。精确地说，它确实有些文化英雄、部落长者、历史学家和发言人。若你在这圈内呆的够长，你或许成为其中之一。记住：黑客们不相信他们的部落长者的自夸的炫耀，因此大举追求这种名誉是危险的。与其奋力追求，不如先摆正自己的位置等它自己到你的手中——那时则要做到谦虚和优雅。</p>
<p><strong>黑客和书呆子(Nerd)的联系</strong></p>
<p>同流行的迷思相反，做一名黑客并不一定要你是个书呆子。但它确实有帮助，而且许多黑客事实上是书呆子。做一个深居简出的人有助于你集中精力进行十分重要的事情，如思考和编程。</p>
<p>因此，很多黑客都愿意接受“书呆子”这个外号，更有甚者使用更尖刻的“geek（怪人）”一词并引以为豪—— 这是一种宣布他们独立于主流社会的声明方式。访问 The Geek Page 参加更多的讨论。</p>
<p>如果你能集中足够的精力做好黑客工作同时还能有正常的生活，这很好。现在作到这一点比我在1970年代是新手的时候要容易的多；如今主流文化对技术怪人要友善的多。甚至有越来越多的人意识到黑客通常是很好的恋人和配偶的材料。</p>
<p>如果你因为生活上不如意而迷上做黑客，那也没什么——至少你不会分神了。或许以后你会找到自己的另一半。</p>
<p>风格的意义</p>
<p>重申一下，作为一名黑客，你必须进入黑客精神之中。当你不在计算机边上时，你仍然有很多对黑客工作有帮助的事情可做。它们并不能替代真正的编程（没有什么能），但很多黑客都那么做，并感到它们与黑客的本质存在某些基本的连系。</p>
<p>    * 学会流畅地用母语写作。尽管程序员不能写好文章的错误看法相当普遍，但是有令人惊讶数目的黑客（包括所有我知道的最棒的）都是不错的作家。<br />
    * 阅读科幻小说。参加科幻小说讨论会。（一个碰到黑客和未来会成为黑客的人的好方法）<br />
    * 学禅，并且/或者练功习武。（精神修炼看来是惊人相似。）<br />
    * 练就能分析音乐的听觉，学会鉴赏特别的音乐。学会玩某种乐器，或唱歌。<br />
    * 提高对双关语、文字游戏的鉴赏能力。</p>
<p>这些事情，你已经做的越多，你就越是天生做黑客的材料。至于为什么偏偏是这些事情，原因并不完全清楚，但它们都涉及用到左－右脑能力的综合，这似乎是关键所在（黑客们既需要清晰的逻辑思维，有时又需要偏离逻辑跳出问题的表象）。</p>
<p>最后，还有一些不要去做的事情。</p>
<p>    * 不要使用愚蠢的，哗众取宠的ID或昵称。<br />
    * 不要卷入Usenet（或其他地方的论坛）的骂战。<br />
    * 不要自称为“cyberpunk（网络叛客）”，也不要浪费时间和那些人打交道。<br />
    * 不要让你寄出的Email或张贴的帖子充满错误的拼写和乱七八糟的语法。</p>
<p>做以上的事情，只会招来嘲笑。黑客们个个记忆超群—— 你将需要数年的时间让他们忘记你犯下的错误。</p>
<p>网名的问题值得深思。将身份隐藏在虚假的名字后是骇客、解密者、d00dz 及其他低等生物幼稚愚蠢的行为特点。黑客不会做这些事；他们对他们所作的感到骄傲，而且乐于人们将作品与他们的 真名相联系。因此, 若你现在用假名，放弃它。在黑客文化里它会令你你失败的。</p>
<p>其它资源</p>
<p>Peter Seebach 维护着一个非常好的 Hacker FAQ，专给那些不懂如何与黑客打交道的经理看的。如果Peter的站点不能访问，下面这个 Excite搜索应该有一份拷贝。</p>
<p>我也著有 黑客文化简史。</p>
<p>我写了一份 大教堂与市集，对于Linux及开放源代码文化现象有详细的解释。我也在这个话题上进一步阐述导致的结局—— 开拓智域。</p>
<p>Rick Moen写了一份很好的关于 如何运转一个Linux用户组的文档。</p>
<p>我和Rick Moen合作完成了另一份关于 提问的智慧的文章，可以让你事半功倍的获得帮助。</p>
<p>如果你想知道PC、UNIX及Internet基本概念和工作原理，参考 The Unix and Internet Fundamentals HOWTO。</p>
<p>当你释放出一个软件或为其打补丁，试着按 软件发行惯例 HOWTO去做。（以上的提到的文章的中文版大多都可以在www.aka.org.cn和www.linuxforum.net找到。）</p>
<p>FAQ（常问问题解答）</p>
<p>问：你能教我做黑客吗？<br />
问：那么，我要如何开始？<br />
问：我得什么时候开始学？现在会不会太迟了？<br />
问：要学多久才能学会黑客道？<br />
问：Visual Basic及Delphi是好的入门语言吗？<br />
问：你能帮我“黑”掉一个站点吗？或者教我怎么黑它？<br />
问：我怎么样才能得到别人帐号的密码？<br />
问：我如何入侵/查看/监视别人的Email？<br />
问：我如何才能在IRC聊天室里偷到频道op的特权？<br />
问：我被黑了。你能帮我避免以后再被攻击吗？<br />
问：我的Windows软件出现问题了。你能帮我吗？<br />
问：我在哪里能找到可以与之交流的真正的黑客？<br />
问：你能推荐一些有关黑客的好书吗？<br />
问：成为一名黑客我需要擅长数学吗？<br />
问：我该从那种语言学起？<br />
问：我需要什么样的机器配置？<br />
问：我得因此憎恨和反对Microsoft吗？<br />
问：但开放源代码软件不会使程序员丢饭碗吗？<br />
问：我要如何开始？哪里有免费的Unix？</p>
<p>问：你能教我做黑客吗？</p>
<p>答：自从第一次发布这份文档，我每周都会收到一些请求，（频繁的话一天几封）要我“教会他们做黑客”。遗憾的是，我没有时间和精力来做这个；我自己的黑客项目，及我作为一个开放源代码倡导者的四处奔波已经占用了我110%的时间。</p>
<p>即便我想教你，黑客也依然基本上是一项自行修炼的的态度和技术。当真正的黑客想帮助你的时候，如果你乞求他们一汤匙一汤匙“喂”你的话，你会发现他们不会尊重你。</p>
<p>先去学一些东西。显示你在尝试，你能靠自己去学习。然后再去向你遇到的黑客请教特殊的问题。</p>
<p>如果你发E-mail给一位黑客寻求他的帮助，这是两件首要记住的事情。第一，写出来的文字显得懒且粗心的人通常非常懒于思考且非常马大哈，不能成为好黑客—— 因此注意拼写正确，使用正确的语法及发音，否则你可能会无人理睬。第二，不要试图要求回复到一个ISP帐号，而那个帐号与你的发信地址不同。这样做的人一般是使用盗用帐号，不会有人有兴趣为虎作伥帮助窃贼的。</p>
<p>问：那么，我要如何开始？</p>
<p>答：对你而言最佳的入门方式也许是去参加LUG（Linux用户组）的聚会。你可以找到在 LDP的综合Linux信息页面上找到类似的组织；也许有一个在你家附近的，而且非常有可能与一所大学或学校挂钩。如果你提出要求，LUG成员兴许会给你一套Linux，当然此后会帮你安装并带你入门。</p>
<p>问：我得什么时候开始学？现在会不会太迟了？</p>
<p>答：你有动力学习的时候就是好时候。大多数人看来都是在15－20岁之间开始感兴趣的，但据我所知，在此年龄段之外的例外也是有的。</p>
<p>问：要学多久才能学会黑客道？</p>
<p>答：这取决于你的聪明程度和努力程度。大多数人只要他们专注，就能在18个月到2年之间学会一套令人尊敬的技能。但是，不要以为就此结束了；如果你是一个真正的黑客，你要用你的余生来学习和完善你的技术。</p>
<p>问：Visual Basic及Delphi是好的入门语言吗？</p>
<p>答：不，因为他们不是可移植的。他们不是那些语言的开放源代码实现，所以你被限制在厂商选择支持的那些平台里。接受这样一种垄断局面不是黑客的态度。</p>
<p>Visual Basic特别糟糕。它是Microsoft的私有语言这个事实就足够让它脸面全无，不像其他的Basic，它是一种设计糟糕的语言会教给你坏的编程习惯。</p>
<p>其中一个坏习惯是会依赖于单一厂商的函数库、控件及开发工具。一般而言，任何不能够支持至少Linux或者一种BSD，或其他第三方操作系统的语言，都是一种不适合应付黑客工作的语言。</p>
<p>问：你能帮我“黑”掉一个站点吗？或者教我怎么黑它？</p>
<p>答：No。任何读完这份FAQ后还问这个问题的人，都是无可救药的蠢材，即使有时间指教我也不会理睬。任何发给我的此类E-mail都会被忽略或被痛骂一顿。</p>
<p>问：我怎么样才能得到别人帐号的密码？</p>
<p>答：这是骇客行为。滚得远远的，白痴。</p>
<p>问：我如何入侵/查看/监视别人的Email？</p>
<p>答：这是骇客行为。在我面前消失，混蛋。</p>
<p>问：我如何才能在IRC聊天室里偷到频道op的特权？</p>
<p>答：这是骇客行为。去S吧，冥顽不灵的家伙。</p>
<p>问：我被黑了。你能帮我避免以后再被攻击吗？</p>
<p>答：不行。目前为止，每次问我这个问题的，都是一些运行Microsoft Windows的菜鸟。不可能有效的保护Windows系统免受骇客攻击；太多缺陷的代码和架构使保护Windows的努力有如隔靴搔痒。唯一可靠的预防来自转移到Linux或其他设计得至少足够安全的系统。</p>
<p>问：我的Windows软件出现问题了。你能帮我吗？</p>
<p>答：当然。进入DOS方式，然后键入“format c:”。你遇到的任何问题将会在几分钟之内消失。</p>
<p>问：我在哪里能找到可以与之交流的真正的黑客？</p>
<p>答：最佳办法是在你附近找一个Unix或Linux的用户组，参加他们的聚会。（你可以在Metalab的LDP站点找到一些指向用户组的链接。）</p>
<p>我过去曾说过不能在IRC上找到真正的黑客，但我发觉现在情况有所改变。显然一些真正的黑客的社区像GIMP及Perl，也有IRC频道了。）</p>
<p>问：你能推荐一些有关黑客的好书吗？</p>
<p>答：我维护着一份Linux Reading List HOWTO，也许你会觉得有用。 Loginataka也很有意思。</p>
<p>关于Python的介绍，请访问在Python站点上的 入门资料。</p>
<p>问：成为一名黑客我需要擅长数学吗？</p>
<p>答：不用。黑客道很少使用常规的数学或算术，不过你绝对需要能逻辑性地思考和进行精密的推理。</p>
<p>尤其是你不会用到微积分或电路分析（我们把这些留给电子工程师们 <img src='http://www.tairan.net/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> ）。 一些有限数学（包括布尔代数，集合论，组合数学，图论）的背景知识会有帮助。</p>
<p>问：我该从那种语言学起？</p>
<p>答：HTML——如果你还不懂的话。市面上有一大堆的封面精美，宣传得天花乱坠的 糟糕的 HTML书籍，不幸的是很少有好的。我最喜欢的是 HTML: The Definitive Guide。</p>
<p>但 HTML 不完全是一种编程语言。当你准备开始编程时，我推荐从 Python起步。你会听到一大群人推荐 Perl，并且 Perl 依然比 Python 流行得多，但是难学得多且（以我之见）设计得不是很好。</p>
<p>C 确实重要，但它要比 Python 或 Perl 难多了。不要尝试先学 C。</p>
<p>Windows用户不要满足于 Visual Basic。它会教给你坏习惯，而且它不可以移植，只能在Windows下运行。避免它。</p>
<p>问：我需要什么样的机器配置？</p>
<p>答：过去个人电脑能力相当不够并且内存小，结果给黑客的学习过程设置了人为的障碍。不过一段时间以前开始就不是这样了；任何配置比一台 Intel 486DX50 好的机器都有足够的能力进行开发工作，X，及 Internet 通讯，同时你现在买的最小的磁盘都大得富足了。（依Barret之见，现在要至少Pentium 166MMX才够。）</p>
<p>选择用来学习的机器时重要的一点是注意配件是否是Linux兼容的（或BSD兼容，如果你选择学 BSD）。同刚才提到的一样，大多数现在的机器都是符合的；唯一的值得注意的区域在于 modem和打印机；有些具备为Windows设计的配件的机器不会在Linux下工作。</p>
<p>关于硬件兼容性有一个FAQ；最新版本在 这里。</p>
<p>问：我得因此憎恨和反对Microsoft吗？</p>
<p>答：不，你不必如此。不是因为Microsoft不令人讨厌，而是因为黑客文化早在 Microsoft出现之前就存在了，且将在Microsoft成为历史后依然存在。你耗费在憎恨Microsoft的任何力气不如花在爱你的技术上。写好的代码—— 那会相当有效地打击Microsoft又不会让你得到恶报应。</p>
<p>问：但开放源代码软件不会使程序员丢饭碗吗？</p>
<p>答：看起来不太可能——目前为止，开放源代码软件产业似乎创造了更多的就业机会而不是减少就业机会。如果写一个程序比起不写来是纯经济收益的话，那么在写完后，程序员应该得到报酬不管程序是否是开放源代码。并且，无论写出多么“免费自由”的软件，都存在更多对新的，定制的软件的需求。我有这方面更多的论述，放在开放源代码 网站资料中。</p>
<p>问：我要如何开始？哪里有免费的Unix？</p>
<p>答：在本份文档的某个地方我已经提到过何处可以得到最常用的免费Unix。要做一名黑客，你需要自立自强，以及自学能力。现在开始吧……</p>
<hr />
<p><small>© Daniel Wang for <a href="http://www.tairan.net">Tairan&#039;s Story</a>, 2009. |
<a href="http://www.tairan.net/index.php/2009/09/18/how-to-become-a-hacker/">Permalink</a> |
<a href="http://www.tairan.net/index.php/2009/09/18/how-to-become-a-hacker/#comments">No comment</a> |
Add to
<a href="http://del.icio.us/post?url=http://www.tairan.net/index.php/2009/09/18/how-to-become-a-hacker/&title=如何成为一名黑客">del.icio.us</a>
<br/>
Post tags: <a href="http://www.tairan.net/index.php/tag/hacker/" rel="tag">Hacker</a><br/>
</small></p>
<p><small>Feed enhanced by <a href='http://planetozh.com/blog/my-projects/wordpress-plugin-better-feed-rss/'>Better Feed</a> from  <a href='http://planetozh.com/blog/'>Ozh</a></small></p>
]]></content:encoded>
			<wfw:commentRss>http://www.tairan.net/index.php/2009/09/18/how-to-become-a-hacker/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>中国民众为什么不以偷税为耻？</title>
		<link>http://www.tairan.net/index.php/2009/03/19/revenue-in-china/</link>
		<comments>http://www.tairan.net/index.php/2009/03/19/revenue-in-china/#comments</comments>
		<pubDate>Thu, 19 Mar 2009 08:09:32 +0000</pubDate>
		<dc:creator>Daniel Wang</dc:creator>
				<category><![CDATA[参考消息]]></category>
		<category><![CDATA[精彩文章]]></category>
		<category><![CDATA[民生]]></category>
		<category><![CDATA[税收]]></category>

		<guid isPermaLink="false">http://www.tairan.net/?p=284</guid>
		<description><![CDATA[原来除了每个月上缴的个税外，我们还通过各种渠道来纳税。不知道其他人如何，我倒是觉得缴税像被旧时恶吏抢劫一样！ 以下内容为【转载】，请读者保持自己的主观判断力！ 自1995年以来，我国税收连续12年平均增长20%，而GDP平均每年增长却不到10%。全国城乡居民的收入增长，更低于GDP的增长率。 2008年，全球性的金融危机使许多民营企业经营不善，有的甚至陷入困境而亏损倒闭。不少城乡居民下岗，失去了收入来源。而截止到2008年7月，全国财政收入依然比2007年增长了26%。 我们为什么要向政府交税？政府为何要收税？中国的税负重不重？对如此快速增长的税收的使用，中国公民能不能监督，如何监督？ 去年底以来，北京的NGO——传知行社会经济研究所编写了《2008公民税权手册》一书，从税收的本质和来源入手，向公民进行“税”的普及，并探讨目前中国税收体制存在的问题。 《人物周刊》就此采访了该书主编岑科。 受访人 岑科（研究员） 采访人 实习记者 陈小瑾 1 我们习惯说“中国政府养活了13亿人口”，而你这本书则希望所有人有一个意识：是我们交的税养活了政府。为什么？ 岑科：税的本质，是民众购买政府（人员）服务的费用，体现的是政府和民众的一种交易关系。当然，在历史上——包括今天的世界，某些国家的政府和民众之间确实不是交易关系，而是某种程度的掠夺与被掠夺关系。但那不是正常的税收关系。 在现代文明社会，政府的角色是向民众征收税款，同时负责提供一系列公共物品和公共服务——如公路、街道、路灯、治安、消防、环保等等。本质上，这是一种交易。 2 一般中国人理解个人所得税是交税，其实这笔税收只占中国税收总额的10%不到，我们还交了哪些税？ 岑科：在中国，所有商品标价实行的是含税价，价格中包括了国家征收的税金——可能是增值税、消费税、营业税，也可能是城建税和教育费附加等。所以无论是谁，每买一件商品就在向政府交一次税。例如如果花100元买瓶化妆品，其中除14.53元的增值税外，还包含25.64元的消费税和4.02元的城建税。 此外，人们在生活中的其他场合也可能交税。例如，当你的工资收入超出一定标准，要交个人所得税；如果你买车，要交车辆购置税、车船税；如果你买房、卖房，要交相关的契税、印花税，也可能交营业税、个人所得税和土地增值税；如果你办企业，从事生产经营活动，涉及的税就更多，包括增值税、消费税、营业税、资源税、城建税、房产税、城镇土地使用税等。可以说，在生活中的每一天、每一个角落，税收无处不在。人人都是纳税人。 3 “税负的痛苦取决于政府如何使用税收，而不是税率”，这句话如何理解？ 岑科：发达国家中有高税国家，比如瑞典，税收占GDP的51%；也有低税国家，比如美国，税收占GDP的27%。但无论是高税还是低税，他们税收的主要用途都是社会保障、教育、医疗保健和公共服务。这些功能一般占税收总额的70%-80%。而政府成本相对较少。 中国正相反，这些支出的比例只占税收总额的25%，大量税收被政府自身消耗了。 在全国政协大会上，九三学社中央副主席、浙江大学教授冯培恩委员列举了公务用车消费、公款吃喝消费、公费出国消费、政府会议消费、“政绩工程”和办公楼建设消费、能源和资源消费等六种政府消费行为，例如公务用车方面，他调查认为我国目前大约有400万辆公车，每年消耗超过2000多亿元，其中真正用于公务的约占1/3；公费出国、公款吃喝每年各不少于2000个亿，至少吃掉一个三峡工程。 4 和这些高税率发达国家相比，中国的税收只占GDP的20%，为什么人们却怨声载道？ 岑科：发达国家名义税率高，实际税率低，因为公民纳税后享受的教育、医疗、社会保险水平很高，相当于交的税得到了返还。中国正好相反，老百姓纳税之后，政府提供的福利很少，很多人看不起病、上不起学，缺乏生活保障，所以，名义税负低，但是实际税负很高。 瑞典、丹麦和法国等国家的财政支出中，社会保障、教育、医疗保健和一般公共服务是花钱最多的4项，共占去全部支出的近80%。尤其是社会保障，在这 3个国家的财政支出中都占到42%以上的比例；而教育、医疗支出，合计起来也都占到总支出的25%以上。这意味着民众的社会福利保障非常高。把社保、教育、医疗、环保等公共事务支出加起来，占到了瑞典等国财政支出的绝大部分。 中国的9亿农民，基本没有医疗保障。医院的条件越来越好，但收费也越来越高，许多农民因此看不起病。教育方面，年年有考上大学却因缴不起学费而无缘读书的报道。中国有上千万的失业者，得到失业救济的微乎其微……与发达国家相比，中国民众享受的公共福利很少。 5 书中阐释了一些概念比如“明税”（就是法律规定由税务部门征收的税款）、“暗税”（就是政府在税务部门之外，通过其他渠道向老百姓取得的收入，例如各种罚款、收费）等，在中国，除了税收以外，政府还有哪些其他收入？ 岑科：主要还有行政收费、土地出让收益、垄断行业收入等。 根据2005年经济普查，中国的行政收费中，工商、质监、城管、消防、交通5个部门，加上法院，共收取费用9724亿。全体政府部门大约收取行政费用12500亿。 除了行政收费以外，中国的地方政府还有一个重大的预算外收入，就是土地。根据国土资源部统计，2006年全国的土地出让金约为7700亿，与土地出让价格相比，农民的土地补偿金额大约只有10%。政府净收益7000亿。 在正常税收之外，政府还掌握了一些垄断企业，包括电信、石油、金融等。这些垄断企业通过政府保护的垄断地位而获得巨额利润。我们估计其数额在2000亿元以上。 各种暗税加起来，足以让中国的名义税负增加10个百分点。 6 2009年全国公务员考试报名者多达百万，供需比年年提高，你怎么看待这种公务员报考的火热现象？ 岑科：公务员成为社会就业的热点不是好事。道理很简单：政府不直接创造财富，而企业却是实实在在地创造价值；官员致力于讨好上级，企业家却要讨好消费者。当更多的就业者希望从市场转向政府时，表明这个社会的创业环境正在恶化，生产财富的动力正在衰减。 7 你的书中写到，“如果纳税人对税收使用无法监管，那么纳税并不光荣”。如何理解？我知道其实现实生活里人们的交税意识很弱，常有偷税漏税发生。 岑科：不能监管的税收，严格地说不是“税收”，而是掠夺。被掠夺当然谈不上光荣。 这是由现行税收体制的弊端决定的。现代国家都有一整套的公民授权、监督、运作税收的方案，而中国的税收往往是行政部门主导，制定和征税成为行政部门不可控制的权力。 单方面制定的税收，不可能具有权威性和正当性。只有政府首先依照合法的程序，在纳税人同意的情况下，确定税收的种类和额度，然后才谈得上公民的纳税义务。对于未经合法程序确立的税收，公民本不应有任何纳税的义务，更谈不上什么纳税意识。 对此，人们往往采取消极抵抗的方式，就是尽可能偷税漏税，或者是为了少缴税向有关官员行贿。既然纳税人被强制征税，他们也就普遍不以偷税为耻，也不以行贿为耻。 8　中国公民对税收的审核和监督如何体现？ 岑科：从名义上看，全国人民代表大会是中国的最高国家权力机关，是代表中国人民的民意实体，帮助纳税人监督政府的收支活动，促使政府高效廉洁地为纳税人服务，是它的职责。 到目前为止，我国的各级人民代表大会也对政府财政预算进行审议，但从具体议程看，离“监督政府如何花钱”这一目标相差很远。例如每年开人代会时，代表们审议政府预算的时间最多一天，甚至不到一天；会议公布的预算报告只有几页纸，内容大而化之；具体的预算文本不发给代表，由代表团长掌握；有些地方虽把详细文本发给代表，但会后都要收回；等等。这样的审议，不可能达到了解政府支出状况、提出改进意见的效果。 人民代表大会尚且如此，其他方式能起到多大监督作用呢？ 9　和国外相比，中国的财政支出情况如何？ 岑科：有研究指出，在过去几年中，与美国、法国、瑞典、丹麦等发达国家用于公共福利的财政支出（占总支出的80%到90%）相比，中国财政的公共福利支出非常欠缺（约占总支出的50%）。2003年，美国公共医疗投入占GDP的比重是13.9％，而中国只有4.5%；2005年，我国的公共教育投入占GDP的2.8%，排在世界各国的末尾——比非洲穷国乌干达还低。 在行政开支方面，以2006年为例，中国政府的预算内行政支出占财政总支出的比重为18.73%，远远高于日本的2.38%、英国的4.19%、韩国的5.06%、法国的6.5%、加拿大的7.1%以及美国的9.9%。如果加上预算外支出，有学者估计，中国政府的实际公务支出至少占政府全部支出的 30%以上。 [...]]]></description>
			<content:encoded><![CDATA[<p>原来除了每个月上缴的个税外，我们还通过各种渠道来纳税。不知道其他人如何，我倒是觉得缴税像被旧时恶吏抢劫一样！<br />
以下内容为【转载】，请读者保持自己的主观判断力！</p>
<blockquote><p>自1995年以来，我国税收连续12年平均增长20%，而GDP平均每年增长却不到10%。全国城乡居民的收入增长，更低于GDP的增长率。</p>
<p>2008年，全球性的金融危机使许多民营企业经营不善，有的甚至陷入困境而亏损倒闭。不少城乡居民下岗，失去了收入来源。而截止到2008年7月，全国财政收入依然比2007年增长了26%。</p>
<p>我们为什么要向政府交税？政府为何要收税？中国的税负重不重？对如此快速增长的税收的使用，中国公民能不能监督，如何监督？</p>
<p>去年底以来，北京的NGO——传知行社会经济研究所编写了《2008公民税权手册》一书，从税收的本质和来源入手，向公民进行“税”的普及，并探讨目前中国税收体制存在的问题。</p>
<p>《人物周刊》就此采访了该书主编岑科。</p>
<p>受访人 岑科（研究员） 采访人 实习记者 陈小瑾</p>
<p>1 我们习惯说“中国政府养活了13亿人口”，而你这本书则希望所有人有一个意识：是我们交的税养活了政府。为什么？</p>
<p>岑科：税的本质，是民众购买政府（人员）服务的费用，体现的是政府和民众的一种交易关系。当然，在历史上——包括今天的世界，某些国家的政府和民众之间确实不是交易关系，而是某种程度的掠夺与被掠夺关系。但那不是正常的税收关系。</p>
<p>在现代文明社会，政府的角色是向民众征收税款，同时负责提供一系列公共物品和公共服务——如公路、街道、路灯、治安、消防、环保等等。本质上，这是一种交易。</p>
<p>2 一般中国人理解个人所得税是交税，其实这笔税收只占中国税收总额的10%不到，我们还交了哪些税？</p>
<p>岑科：在中国，所有商品标价实行的是含税价，价格中包括了国家征收的税金——可能是增值税、消费税、营业税，也可能是城建税和教育费附加等。所以无论是谁，每买一件商品就在向政府交一次税。例如如果花100元买瓶化妆品，其中除14.53元的增值税外，还包含25.64元的消费税和4.02元的城建税。</p>
<p>此外，人们在生活中的其他场合也可能交税。例如，当你的工资收入超出一定标准，要交个人所得税；如果你买车，要交车辆购置税、车船税；如果你买房、卖房，要交相关的契税、印花税，也可能交营业税、个人所得税和土地增值税；如果你办企业，从事生产经营活动，涉及的税就更多，包括增值税、消费税、营业税、资源税、城建税、房产税、城镇土地使用税等。可以说，在生活中的每一天、每一个角落，税收无处不在。人人都是纳税人。</p>
<p>3 “税负的痛苦取决于政府如何使用税收，而不是税率”，这句话如何理解？</p>
<p>岑科：发达国家中有高税国家，比如瑞典，税收占GDP的51%；也有低税国家，比如美国，税收占GDP的27%。但无论是高税还是低税，他们税收的主要用途都是社会保障、教育、医疗保健和公共服务。这些功能一般占税收总额的70%-80%。而政府成本相对较少。</p>
<p>中国正相反，这些支出的比例只占税收总额的25%，大量税收被政府自身消耗了。</p>
<p>在全国政协大会上，九三学社中央副主席、浙江大学教授冯培恩委员列举了公务用车消费、公款吃喝消费、公费出国消费、政府会议消费、“政绩工程”和办公楼建设消费、能源和资源消费等六种政府消费行为，例如公务用车方面，他调查认为我国目前大约有400万辆公车，每年消耗超过2000多亿元，其中真正用于公务的约占1/3；公费出国、公款吃喝每年各不少于2000个亿，至少吃掉一个三峡工程。</p>
<p>4 和这些高税率发达国家相比，中国的税收只占GDP的20%，为什么人们却怨声载道？</p>
<p>岑科：发达国家名义税率高，实际税率低，因为公民纳税后享受的教育、医疗、社会保险水平很高，相当于交的税得到了返还。中国正好相反，老百姓纳税之后，政府提供的福利很少，很多人看不起病、上不起学，缺乏生活保障，所以，名义税负低，但是实际税负很高。</p>
<p>瑞典、丹麦和法国等国家的财政支出中，社会保障、教育、医疗保健和一般公共服务是花钱最多的4项，共占去全部支出的近80%。尤其是社会保障，在这 3个国家的财政支出中都占到42%以上的比例；而教育、医疗支出，合计起来也都占到总支出的25%以上。这意味着民众的社会福利保障非常高。把社保、教育、医疗、环保等公共事务支出加起来，占到了瑞典等国财政支出的绝大部分。</p>
<p>中国的9亿农民，基本没有医疗保障。医院的条件越来越好，但收费也越来越高，许多农民因此看不起病。教育方面，年年有考上大学却因缴不起学费而无缘读书的报道。中国有上千万的失业者，得到失业救济的微乎其微……与发达国家相比，中国民众享受的公共福利很少。</p>
<p>5 书中阐释了一些概念比如“明税”（就是法律规定由税务部门征收的税款）、“暗税”（就是政府在税务部门之外，通过其他渠道向老百姓取得的收入，例如各种罚款、收费）等，在中国，除了税收以外，政府还有哪些其他收入？</p>
<p>岑科：主要还有行政收费、土地出让收益、垄断行业收入等。</p>
<p>根据2005年经济普查，中国的行政收费中，工商、质监、城管、消防、交通5个部门，加上法院，共收取费用9724亿。全体政府部门大约收取行政费用12500亿。</p>
<p>除了行政收费以外，中国的地方政府还有一个重大的预算外收入，就是土地。根据国土资源部统计，2006年全国的土地出让金约为7700亿，与土地出让价格相比，农民的土地补偿金额大约只有10%。政府净收益7000亿。</p>
<p>在正常税收之外，政府还掌握了一些垄断企业，包括电信、石油、金融等。这些垄断企业通过政府保护的垄断地位而获得巨额利润。我们估计其数额在2000亿元以上。</p>
<p>各种暗税加起来，足以让中国的名义税负增加10个百分点。</p>
<p>6 2009年全国公务员考试报名者多达百万，供需比年年提高，你怎么看待这种公务员报考的火热现象？</p>
<p>岑科：公务员成为社会就业的热点不是好事。道理很简单：政府不直接创造财富，而企业却是实实在在地创造价值；官员致力于讨好上级，企业家却要讨好消费者。当更多的就业者希望从市场转向政府时，表明这个社会的创业环境正在恶化，生产财富的动力正在衰减。</p>
<p>7 你的书中写到，“如果纳税人对税收使用无法监管，那么纳税并不光荣”。如何理解？我知道其实现实生活里人们的交税意识很弱，常有偷税漏税发生。</p>
<p>岑科：不能监管的税收，严格地说不是“税收”，而是掠夺。被掠夺当然谈不上光荣。</p>
<p>这是由现行税收体制的弊端决定的。现代国家都有一整套的公民授权、监督、运作税收的方案，而中国的税收往往是行政部门主导，制定和征税成为行政部门不可控制的权力。</p>
<p>单方面制定的税收，不可能具有权威性和正当性。只有政府首先依照合法的程序，在纳税人同意的情况下，确定税收的种类和额度，然后才谈得上公民的纳税义务。对于未经合法程序确立的税收，公民本不应有任何纳税的义务，更谈不上什么纳税意识。</p>
<p>对此，人们往往采取消极抵抗的方式，就是尽可能偷税漏税，或者是为了少缴税向有关官员行贿。既然纳税人被强制征税，他们也就普遍不以偷税为耻，也不以行贿为耻。</p>
<p>8　中国公民对税收的审核和监督如何体现？</p>
<p>岑科：从名义上看，全国人民代表大会是中国的最高国家权力机关，是代表中国人民的民意实体，帮助纳税人监督政府的收支活动，促使政府高效廉洁地为纳税人服务，是它的职责。</p>
<p>到目前为止，我国的各级人民代表大会也对政府财政预算进行审议，但从具体议程看，离“监督政府如何花钱”这一目标相差很远。例如每年开人代会时，代表们审议政府预算的时间最多一天，甚至不到一天；会议公布的预算报告只有几页纸，内容大而化之；具体的预算文本不发给代表，由代表团长掌握；有些地方虽把详细文本发给代表，但会后都要收回；等等。这样的审议，不可能达到了解政府支出状况、提出改进意见的效果。</p>
<p>人民代表大会尚且如此，其他方式能起到多大监督作用呢？</p>
<p>9　和国外相比，中国的财政支出情况如何？</p>
<p>岑科：有研究指出，在过去几年中，与美国、法国、瑞典、丹麦等发达国家用于公共福利的财政支出（占总支出的80%到90%）相比，中国财政的公共福利支出非常欠缺（约占总支出的50%）。2003年，美国公共医疗投入占GDP的比重是13.9％，而中国只有4.5%；2005年，我国的公共教育投入占GDP的2.8%，排在世界各国的末尾——比非洲穷国乌干达还低。</p>
<p>在行政开支方面，以2006年为例，中国政府的预算内行政支出占财政总支出的比重为18.73%，远远高于日本的2.38%、英国的4.19%、韩国的5.06%、法国的6.5%、加拿大的7.1%以及美国的9.9%。如果加上预算外支出，有学者估计，中国政府的实际公务支出至少占政府全部支出的 30%以上。</p>
<p>10　中国现行税制体系的弊端有哪些？</p>
<p>岑科：不经纳税人同意，政府单方面制定税收种类和税收标准，并强制征收，而且不向公众提供对于税收的申诉和抗辩渠道，是目前中国税制最核心的问题，也是所有其他税收问题产生的根源。</p>
<p>在税收立法上，存在着行政法规多、国家立法少，以行政立法取代国家立法的状况，结果是，征税的行政本位突出，没有国家宪法和法律作为依据，使得税收的合法性不足。在实际运作中，有大量“暗税”，其运作过程非常混乱和随意。</p>
<p>这些弊端，导致了严重的后果：第一，政府的征收成本特别高，达到了西方国家平均水平的10倍左右；第二，税收的额外负担很高，对企业、纳税人造成了极大困扰。在税收征管大军的征稽下，大多数企业穷于应付，不得不采取消极抵制的方式与政府周旋；第三，一些暴力执法式征管和变相征管等政府不良行为，恶化了官民关系和社会秩序，对政府形象造成了巨大损害。</p>
<p>（来源：南方人物周刊）</p></blockquote>
<hr />
<p><small>© Daniel Wang for <a href="http://www.tairan.net">Tairan&#039;s Story</a>, 2009. |
<a href="http://www.tairan.net/index.php/2009/03/19/revenue-in-china/">Permalink</a> |
<a href="http://www.tairan.net/index.php/2009/03/19/revenue-in-china/#comments">No comment</a> |
Add to
<a href="http://del.icio.us/post?url=http://www.tairan.net/index.php/2009/03/19/revenue-in-china/&title=中国民众为什么不以偷税为耻？">del.icio.us</a>
<br/>
Post tags: <a href="http://www.tairan.net/index.php/tag/the-peoples-livelihood/" rel="tag">民生</a>, <a href="http://www.tairan.net/index.php/tag/revenue/" rel="tag">税收</a><br/>
</small></p>
<p><small>Feed enhanced by <a href='http://planetozh.com/blog/my-projects/wordpress-plugin-better-feed-rss/'>Better Feed</a> from  <a href='http://planetozh.com/blog/'>Ozh</a></small></p>
]]></content:encoded>
			<wfw:commentRss>http://www.tairan.net/index.php/2009/03/19/revenue-in-china/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Fire And Motion</title>
		<link>http://www.tairan.net/index.php/2009/02/27/fire-and-motion/</link>
		<comments>http://www.tairan.net/index.php/2009/02/27/fire-and-motion/#comments</comments>
		<pubDate>Fri, 27 Feb 2009 01:47:47 +0000</pubDate>
		<dc:creator>Daniel Wang</dc:creator>
				<category><![CDATA[Technology 转载]]></category>
		<category><![CDATA[参考消息]]></category>
		<category><![CDATA[精彩文章]]></category>
		<category><![CDATA[Thinking]]></category>

		<guid isPermaLink="false">http://blog.tairan.org/?p=235</guid>
		<description><![CDATA[这是一篇从Joel on Software转载的文章，也许大家在这里能得到一些启示: 中文 英文 行进中开火 作者： 周思博 (Joel Spolsky) 译： Siyan Li 李思延 编辑： Paul May 梅普華 2002年1月6日 时不时，总有一阵儿，我什么事也干不了。 我也去办公厅，东瞄瞄，西看看，每十秒钟查一次电子邮件，网上逛一圈。也许干点儿象付运通卡账单之类不需要大脑的事。不过要回去哗啦哗啦写程序，可没门儿。 这种不出活的状态，一般通常会持续一两天。在我的软件开发生涯中也有过几个星期干不了活的时候。就像他们说的，我不在状态，我进入不了情况，我找不到组织。 人人都有情绪波动，有的人温和一些，有的响动大点儿，也有的可以整个乱套。但不管怎么着，那段不出活期似乎总是跟忧郁有点儿关系。 我不由得联想到那些专家说，人们基本上控制不了自己吃什么。任何节食计划都长不了。大家总是悠回各自的正常体重。也许作为一个软件工程师，我也不能控制什么时候最能出活。我唯一希望的就是发呆那段能被哗哗干活那段扯平，最终还能混碗饭吃。 自从我干上软件开发这一行起，我平均每天只有两三个的高效时间。这真让我头大。我在微软实习的时候，另外一个实习生告诉我，他每天12点上班，5点下班。5个钟头还包括午餐时间，但他的同事还对他特别满意。因为他干的活比一般人都多。其实我也一样。我每天只有两三个小时的高效时间。看着别人那么卖力的干，还有点不好意思。不过呢，我总是组里出活最多的。由此可见，“人件理论”和极限编程都坚持不加班，每周只干40小时，还是有点道理的。他们都清楚这么做不会降低一个小组的生产能力。 每天只能干两小时还没让我太担心，真让我担心的是完全干不了活的那些天。 我老想这是怎么回事儿。我努力回忆我出活最多的时候。估计是微软把我搬到一间漂亮的新办公室的时候。舒适豪华的办公室，窗外风景如画，窗对面樱桃花开满了石头堆砌的庭院。所有的一切都那么恰到好处。我马不停蹄地干好好几个月，一口气把Excel Basic的详细设计搞定。用象纪念碑那么高的一叠纸，详细描素了一个超大型目标模型和编程环境，工作之细致，令人难以置信。我自始至终就没停过手。去波士顿参加MacWorld I的时候，我都带着一台手提电脑，坐在哈佛商学院的大阳台上把Windows类别的所有文件都写完了。 按步就班并不难。通常我一天是这样度过的：1，去上班。2，查电子邮件和上网等等。 3，考虑是否应该吃完中饭在开始干活。4，吃完中饭回来。5，查电子邮件逛网。6，终于决定应该开始工作了。7，查电子邮件逛网，东瞄瞄，西看看。8，再次决定确实应该开始开始干活了。9，打开该死的编辑器。10，一直会些程序学到晚上7：30，写到忘记时间。 在以上第8步和第9步之间似乎有点缺陷，因为我不是每次都能顺利地执行下去。 对我来说，启动是唯一的难题。静止物体在不受外力作用的情况下会保持静止。大脑里有些物质的质量大得不可思议，让它加速太难了。但是只要速度上去了，在全速行使的情况下，倒不用使什么劲就能继续走下去。就象骑着自行车去作一次自费横穿美国的旅行，一开始，你根本想象不出要花那么多时间让车轮动起来，可是一旦动起来了，让它们继续转就不是一件很难的事了。 也许高效率的关键就：启动起来。配对编程法之所以成功，说不定就靠两个人在一起，互相强迫对方启动起来。 我在以色烈当伞兵时，一次，有个将军来给我们讲实战战术。他告诉我们，步兵战术其实只有一种：行进中开火。你一边开火一边朝着敌人冲过去，火力让敌人抬不起头来，不能朝你开火 (当一个军人喊：“掩护我”的时候，他的意思就是“在我冲过街时候，你朝敌人猛烈开火，迫使他猫起来，没法朝我开火)。前进了，你就可以占领阵地，接近敌人，这样你的胜算要大的多。你要是不往前冲，敌人就有时间来搞清楚形势，这可不妙。你要是不开火，敌人就要朝你开火，撂倒你。 我很长一段时间都在想着这个教导。我想通了不论是战斗机空中格斗还是大规模舰队攻击，大部份军事战略战术都是以行进中开火作为基础的。我又化了十五年时间才想通了行进中开火也是一个人在现实生活中成功的基本原则。你每天都得往前进点儿，不用想你写的程序怎么差劲，怎么卖不出去，只要你不停地写，不停地改，滴水也能穿石。同时， 要注意你的竞争对手朝你开火。他们是不是想让你全心全意应付他们的扫射，好让你往前走不了呢？ 想想这些年来，微软开发出来的资料存取方法，从OBDC，RDO，DAO，ADO，OLEDB直到现在的 ADO，.NET，不停翻新，技术上有必要吗？还是因为那个设计组实在蹩脚，每过他妈一年就得重新发明一遍资料存取技术？(实际上可能真是)。它最终的效果其实是一道掩护火力，让竞争者别无选择，只能把本来该用来开发新功能的宝贵时间都用来移植和升级了。仔细看看软件行业，干得好的公司对那些对大公司都依赖最少，不用把所有精力都用来为赶潮流而把程序重写一遍，还得修改那些只有在Windows XP上才会出现的缺陷。那些花太多时间去猜测微软未来发展方向的公司，日子都好过不了。有些人见了.NET就发怵，忍不住要按.NET来完全重建自己的体系结构，以为自己别无选择。哥门儿，看清楚了，微软是在朝你开火呢，而且这只是掩护火力。这游戏就是这么玩儿的。这样一来，他们就可以大步朝前走，而你却不能。你要支持Hailstorm 吗？SOAP呢？还有RDF？是因为你的顾客需要，所以你支持它们？还是因为有人朝你开火而你觉得应该还击？大公司的营销部都懂火力掩护。他们到客人那儿就说，“你们不一定非买我们的。谁的产品最好您就应该买谁的。不过，我们想提醒您，在下单之前最好先确认他们支持(XML/ SOAP/CDE/J2EE)。否则你们就会被他们的技术套牢。”。等到小公司去向这个客户推销的时候，那个听话的CTO就会问他们：“你们有J2EE吗？”。他们回去就只好不管卖不卖得掉，都埋头打造他们的J2EE。他们也就再没有机会来展示自己的特色了。其实，这只不过是个打勾功能。因为有个打勾拦在那儿空着，你就必须有这个功能。其实谁都不需要它。这就是火力掩护。 对于我这样的小公司来说，行进中开火意味着两件事。别跟时间过不去，同时你还得每天都进步。天不负苦心人，你终有出头的一天。我昨天花了一天时间只不过让FogBUGZ的颜色稍微好看点。这不要紧，只要不停步。最重要的是，我们的软件越来越好，客人越来越多。在我们达到Oracle 的规模之前，我们并不需要通盘战略。我们只需要每天早晨到办公室来，别多想，打开编程器。 本文最先用英文出版，题为 Fire and Motion © Daniel Wang for Tairan&#039;s Story, [...]]]></description>
			<content:encoded><![CDATA[<p>这是一篇从<a href="http://www.joelonsoftware.com/" target="_blank">Joel on Software</a>转载的文章，也许大家在这里能得到一些启示: <a href="http://chinese.joelonsoftware.com/Articles/FireAndMotion.html" target="_blank">中文</a> <a href="http://www.joelonsoftware.com/articles/fog0000000339.html" target="_blank">英文</a></p>
<blockquote><p>行进中开火<br />
作者： 周思博 (Joel Spolsky)<br />
译： Siyan Li 李思延<br />
编辑： Paul May 梅普華<br />
2002年1月6日</p>
<p>时不时，总有一阵儿，我什么事也干不了。</p>
<p>我也去办公厅，东瞄瞄，西看看，每十秒钟查一次电子邮件，网上逛一圈。也许干点儿象付运通卡账单之类不需要大脑的事。不过要回去哗啦哗啦写程序，可没门儿。</p>
<p>这种不出活的状态，一般通常会持续一两天。在我的软件开发生涯中也有过几个星期干不了活的时候。就像他们说的，我不在状态，我进入不了情况，我找不到组织。</p>
<p>人人都有情绪波动，有的人温和一些，有的响动大点儿，也有的可以整个乱套。但不管怎么着，那段不出活期似乎总是跟忧郁有点儿关系。</p>
<p>我不由得联想到那些专家说，人们基本上控制不了自己吃什么。任何节食计划都长不了。大家总是悠回各自的正常体重。也许作为一个软件工程师，我也不能控制什么时候最能出活。我唯一希望的就是发呆那段能被哗哗干活那段扯平，最终还能混碗饭吃。</p>
<p>自从我干上软件开发这一行起，我平均每天只有两三个的高效时间。这真让我头大。我在微软实习的时候，另外一个实习生告诉我，他每天12点上班，5点下班。5个钟头还包括午餐时间，但他的同事还对他特别满意。因为他干的活比一般人都多。其实我也一样。我每天只有两三个小时的高效时间。看着别人那么卖力的干，还有点不好意思。不过呢，我总是组里出活最多的。由此可见，“人件理论”和极限编程都坚持不加班，每周只干40小时，还是有点道理的。他们都清楚这么做不会降低一个小组的生产能力。</p>
<p>每天只能干两小时还没让我太担心，真让我担心的是完全干不了活的那些天。</p>
<p>我老想这是怎么回事儿。我努力回忆我出活最多的时候。估计是微软把我搬到一间漂亮的新办公室的时候。舒适豪华的办公室，窗外风景如画，窗对面樱桃花开满了石头堆砌的庭院。所有的一切都那么恰到好处。我马不停蹄地干好好几个月，一口气把Excel Basic的详细设计搞定。用象纪念碑那么高的一叠纸，详细描素了一个超大型目标模型和编程环境，工作之细致，令人难以置信。我自始至终就没停过手。去波士顿参加MacWorld I的时候，我都带着一台手提电脑，坐在哈佛商学院的大阳台上把Windows类别的所有文件都写完了。</p>
<p>按步就班并不难。通常我一天是这样度过的：1，去上班。2，查电子邮件和上网等等。 3，考虑是否应该吃完中饭在开始干活。4，吃完中饭回来。5，查电子邮件逛网。6，终于决定应该开始工作了。7，查电子邮件逛网，东瞄瞄，西看看。8，再次决定确实应该开始开始干活了。9，打开该死的编辑器。10，一直会些程序学到晚上7：30，写到忘记时间。</p>
<p>在以上第8步和第9步之间似乎有点缺陷，因为我不是每次都能顺利地执行下去。</p>
<p>对我来说，启动是唯一的难题。静止物体在不受外力作用的情况下会保持静止。大脑里有些物质的质量大得不可思议，让它加速太难了。但是只要速度上去了，在全速行使的情况下，倒不用使什么劲就能继续走下去。就象骑着自行车去作一次自费横穿美国的旅行，一开始，你根本想象不出要花那么多时间让车轮动起来，可是一旦动起来了，让它们继续转就不是一件很难的事了。</p>
<p>也许高效率的关键就：启动起来。配对编程法之所以成功，说不定就靠两个人在一起，互相强迫对方启动起来。</p>
<p>我在以色烈当伞兵时，一次，有个将军来给我们讲实战战术。他告诉我们，步兵战术其实只有一种：行进中开火。你一边开火一边朝着敌人冲过去，火力让敌人抬不起头来，不能朝你开火 (当一个军人喊：“掩护我”的时候，他的意思就是“在我冲过街时候，你朝敌人猛烈开火，迫使他猫起来，没法朝我开火)。前进了，你就可以占领阵地，接近敌人，这样你的胜算要大的多。你要是不往前冲，敌人就有时间来搞清楚形势，这可不妙。你要是不开火，敌人就要朝你开火，撂倒你。</p>
<p>我很长一段时间都在想着这个教导。我想通了不论是战斗机空中格斗还是大规模舰队攻击，大部份军事战略战术都是以行进中开火作为基础的。我又化了十五年时间才想通了行进中开火也是一个人在现实生活中成功的基本原则。你每天都得往前进点儿，不用想你写的程序怎么差劲，怎么卖不出去，只要你不停地写，不停地改，滴水也能穿石。同时， 要注意你的竞争对手朝你开火。他们是不是想让你全心全意应付他们的扫射，好让你往前走不了呢？</p>
<p>想想这些年来，微软开发出来的资料存取方法，从OBDC，RDO，DAO，ADO，OLEDB直到现在的 ADO，.NET，不停翻新，技术上有必要吗？还是因为那个设计组实在蹩脚，每过他妈一年就得重新发明一遍资料存取技术？(实际上可能真是)。它最终的效果其实是一道掩护火力，让竞争者别无选择，只能把本来该用来开发新功能的宝贵时间都用来移植和升级了。仔细看看软件行业，干得好的公司对那些对大公司都依赖最少，不用把所有精力都用来为赶潮流而把程序重写一遍，还得修改那些只有在Windows XP上才会出现的缺陷。那些花太多时间去猜测微软未来发展方向的公司，日子都好过不了。有些人见了.NET就发怵，忍不住要按.NET来完全重建自己的体系结构，以为自己别无选择。哥门儿，看清楚了，微软是在朝你开火呢，而且这只是掩护火力。这游戏就是这么玩儿的。这样一来，他们就可以大步朝前走，而你却不能。你要支持Hailstorm 吗？SOAP呢？还有RDF？是因为你的顾客需要，所以你支持它们？还是因为有人朝你开火而你觉得应该还击？大公司的营销部都懂火力掩护。他们到客人那儿就说，“你们不一定非买我们的。谁的产品最好您就应该买谁的。不过，我们想提醒您，在下单之前最好先确认他们支持(XML/ SOAP/CDE/J2EE)。否则你们就会被他们的技术套牢。”。等到小公司去向这个客户推销的时候，那个听话的CTO就会问他们：“你们有J2EE吗？”。他们回去就只好不管卖不卖得掉，都埋头打造他们的J2EE。他们也就再没有机会来展示自己的特色了。其实，这只不过是个打勾功能。因为有个打勾拦在那儿空着，你就必须有这个功能。其实谁都不需要它。这就是火力掩护。</p>
<p>对于我这样的小公司来说，行进中开火意味着两件事。别跟时间过不去，同时你还得每天都进步。天不负苦心人，你终有出头的一天。我昨天花了一天时间只不过让FogBUGZ的颜色稍微好看点。这不要紧，只要不停步。最重要的是，我们的软件越来越好，客人越来越多。在我们达到Oracle 的规模之前，我们并不需要通盘战略。我们只需要每天早晨到办公室来，别多想，打开编程器。</p>
<p>本文最先用英文出版，题为 Fire and Motion  </p></blockquote>
<hr />
<p><small>© Daniel Wang for <a href="http://www.tairan.net">Tairan&#039;s Story</a>, 2009. |
<a href="http://www.tairan.net/index.php/2009/02/27/fire-and-motion/">Permalink</a> |
<a href="http://www.tairan.net/index.php/2009/02/27/fire-and-motion/#comments">No comment</a> |
Add to
<a href="http://del.icio.us/post?url=http://www.tairan.net/index.php/2009/02/27/fire-and-motion/&title=Fire And Motion">del.icio.us</a>
<br/>
Post tags: <a href="http://www.tairan.net/index.php/tag/thinking/" rel="tag">Thinking</a><br/>
</small></p>
<p><small>Feed enhanced by <a href='http://planetozh.com/blog/my-projects/wordpress-plugin-better-feed-rss/'>Better Feed</a> from  <a href='http://planetozh.com/blog/'>Ozh</a></small></p>
]]></content:encoded>
			<wfw:commentRss>http://www.tairan.net/index.php/2009/02/27/fire-and-motion/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>编程不是构建软件，而是设计软件。&#8211; 源码就是设计</title>
		<link>http://www.tairan.net/index.php/2008/11/21/code-as-design/</link>
		<comments>http://www.tairan.net/index.php/2008/11/21/code-as-design/#comments</comments>
		<pubDate>Fri, 21 Nov 2008 15:04:00 +0000</pubDate>
		<dc:creator>Daniel Wang</dc:creator>
				<category><![CDATA[Technology 转载]]></category>
		<category><![CDATA[参考消息]]></category>
		<category><![CDATA[精彩文章]]></category>
		<category><![CDATA[Thinking]]></category>
		<category><![CDATA[软件开发]]></category>

		<guid isPermaLink="false">http://blog.tairan.org/?p=112</guid>
		<description><![CDATA[什么是软件工程中最重要的产出？毫无疑问是代码。代码是给人读的，偶尔让机器运行一下。为了给读代码的人提供便利，我们就需要给代码一些自描述信息（Meta）。这些Meta信息就是相关的文档，注释等。关于是否需要文档在javaeye还有很激烈的讨论。 下面让我们看看大师是怎么说的：英文原版 至今，我仍能记起当我顿悟并最终产生下面文章时所在的地方。那是1986年的夏天，我在加利福尼亚中国湖海军武器中心担任临时顾问。在这期间，我有幸参加了一个关于Ada的研讨会。讨论当中，有一位听众提出了一个具有代表性的问题，“软件开发者是工程师吗？”我不记得当时的回答，但是我却记得当时并没有真正解答这个问题。于是，我就退出讨论，开始思考我会怎样回答这样一个问题。现在，我无法肯定当时我为什么会记起几乎10年前曾经在Datamation杂志上阅读过的一篇论文，不过促使我记起的应该是后续讨论中的某些东西。这篇论文阐述了工程师为什么必须是好的作家（我记得该论文谈论就是这个问题——好久没有看了），但是我从该论文中得到的关键一点是：作者认为工程过程的最终结果是文档。换句话说，工程师生产的是文档，不是实物。其他人根据这些文档去制造实物。于是，我就在困惑中提出了一个问题，“除了软件项目正常产生的所有文档以外，还有可以被认为是真正的工程文档的东西吗？”我给出的回答是，“是的，有这样的文档存在，并且只有一份——源代码。” 把源代码看作是一份工程文档——设计——完全颠覆了我对自己所选择的职业的看法。它改变了我看待一切事情的方式。此外，我对它思考的越多，我就越觉得它阐明了软件项目常常遇到的众多问题。更确切地说，我觉得大多数人不理解这个不同的看法，或者有意拒绝它这样一个事实，就足以说明很多问题。几年后，我终于有机会把我的观点公开发表。C++ Journal中的一篇有关软件设计的论文促使我给编辑写了一封关于这个主题的信。经过几封书信交换后，编辑Livleen Singh同意把我关于这个主题的想法发表为一篇论文。下面就是这篇文章。 ——Jack Reecves, December,22,2001 什么是软件设计？ Jack W.Reeves, 1992 面向对象技术，特别是C++，似乎给软件界带来了不小的震动。出现了大量的论文和书籍去描述如何应用这项新技术。总的来说，那些关于面向对象技术是否只是一个骗局的问题已经被那些关于如何付出最小的努力即可获得收益的问题所替代。面向对象技术出现已经有一段时间了，但是这种爆炸式的流行却似乎有点不寻常。人们为何会突然关注它呢？对于这个问题，人们给出了各种各样的解释。事实上，很可能就没有单一的原因。也许，把多种因素的结合起来才能最终取得突破，并且这项工作正在进展之中。尽管如此，在软件革命的这个最新阶段中，C++本身看起来似乎成为了一个主要因素。同样，对于这个问题，很可能也存在很多种理由，不过我想从一个稍微不同的视角给出一个答案：C++之所以变得流行，是因为它使软件设计变得更容易的同时，也使编程变得更容易。 虽然这个解释好像有点奇特，但是它却是深思熟虑的结果。在这篇论文中，我就是想要关注一下编程和程序设计之间的关系。近10年来，我一直觉得整个软件行业都没有觉察到做出一个软件设计和什么是真正的软件设计之间的一个微妙的不同点。只要看到了这一点，我认为我们就可以从C++增长的流行趋势中，学到关于如何才能成为更好的软件工程师的意义深远的知识。这个知识就是，编程不是构建软件，而是设计软件。 几年前，我参见了一个讨论会，其中讨论到软件开发是否是一门工程学科的问题。虽然我不记得了讨论结果，但是我却记得它是如何促使我认识到：软件业已经做出了一些错误的和硬件工程的比较，而忽视了一些绝对正确的对比。其实，我认为我们不是软件工程师，因为我们没有认识到什么才是真正的软件设计。现在，我对这一点更是确信无疑。 任何工程活动的最终目标都是某些类型的文档。当设计工作完成时，设计文档就被转交给制造团队。该团队是一个和设计团队完全不同的群体，并且其技能也和设计团队完全不同。如果设计文档正确地描绘了一个完整的设计，那么制造团队就可以着手构建产品。事实上，他们可以着手构建该产品的许多实物，完全无需设计者的任何进一步的介入。在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的惟一软件文档，就是源代码清单。 对于这个观点，人们进行了很多的争论，无论是赞成的还是反对的都足以写成无数的论文。本文假定最终的源代码就是真正的软件设计，然后仔细研究了该假定带来的一些结果。我可能无法证明这个观点是正确的，但是我希望证明：它确实解释了软件行业中一些已经观察到的事实，包括C++的流行。 在把代码看作是软件设计所带来的结果中，有一个结果完全盖过了所有其他的结果。它非常重要并且非常明显，也正因为如此，对于大多数软件机构来说，它完全是一个盲点。这个结果就是：软件的构建是廉价的。它根本就不具有昂贵的资格；它非常的廉价，几乎就是免费的。如果源代码是软件设计，那么实际的软件构建就是由编译器和连接器完成的。我们常常把编译和连接一个完整的软件系统的过程称为“进行一次构建”。在软件构建设备上所进行的主要投资是很少的——实际需要的只有一台计算机、一个编辑器、一个编译器以及一个连接器。一旦具有了一个构建环境，那么实际的软件构建只需花费少许的时间。编译50 000行的C++程序也许会花费很长的时间，但是构建一个具有和50 000行C++程序同样设计复杂性的硬件系统要花费多长的时间呢？ 把源代码看作是软件设计的另外一个结果是，软件设计相对易于创作，至少在机械意义上如此。通常，编写（也就是设计）一个具有代表性的软件模块（50至100行代码）只需花费几天的时间（对它进行完全的调试是另外一个议题，稍后会对它进行更多的讨论）。我很想问一下，是否还有任何其他的学科可以在如此短的时间内，产生出和软件具有同样复杂性的设计来，不过，首先我们必须要弄清出如何来度量和比较复杂性。然而，有一点是明显的，那就是软件设计可以 极为迅速地变得非常庞大。 假设软件设计相对易于创作，并且在本质上构建起来也没有什么代价，一个不令人吃惊的发现是，软件设计往往是难以置信的庞大和复杂。这看起来似乎很明显，但是问题的重要性却常常被忽视。学校中的项目通常具有数千行的代码。具有10 000行代码（设计）的软件产品被它们的设计者丢弃的情况也是有的。我们早就不再关注于简单的软件。典型的商业软件的设计都是由数十万行代码组成的。许多软件设计达到了上百万行代码。另外，软件设计几乎总是在不断地演化。虽然当前的设计可能只有几千行代码，但是在产品的生命期中，实际上可能要编写许多倍的代码。 尽管确实存在一些硬件设计，它们看起来似乎和软件设计一样复杂，但是请注意两个有关现代硬件的事实。第一，复杂的硬件工程成果未必总是没有错误的，在这一点上，它不存在像软件那样让我们相信的评判标准。多数的微处理器在发售时都具有一些逻辑错误：桥梁坍塌，大坝破裂，飞机失事以及数以千计的汽车和其他消费品被召回——所有的这些我们都记忆犹新，所有的这些都是设计错误的结果。第二，复杂的硬件设计具有与之对应的复杂、昂贵的构建阶段。结果，制造这种系统所需的能力限制了真正能够生产复杂硬件设计公司的数目。对于软件来说，没有这种限制。目前，已经有数以百计的软件机构和数以千计的非常复杂的软件系统存在，并且数量以及复杂性每天都在增长。这意味着软件行业不可能通过仿效硬件开发者找到针对自身问题的解决办法。倘若一定要说出有什么相同之处的话，那就是，当CAD和CAM可以做到帮助硬件设计者创建越来越复杂的设计时，硬件工程才会变得和软件开发越来越像。 设计软件是一种管理复杂性的活动。复杂性存在于软件设计本身之中，存在于公司的软件机构之中，也存在于整个软件行业之中。软件设计和系统设计非常相似。它可以跨越多种技术并且常常涉及多个学科分支。软件的规格说明往往不固定、经常快速变化，这种变化常常在正进行软件设计时发生。同样，软件开发团队也往往不固定，常常在设计过程的中间发生变化。在许多方面，软件都要比硬件更像复杂的社会或者有机系统。所有这些都使得软件设计成为了一个困难的并且易出错的过程。虽然所有这些都不是创造性的想法，但是在软件工程革命开始将近30年后的今天，和其他工程行业相比，软件开发看起来仍然像是一种未受过训练（undisciplined）的技艺。 一般的看法认为，当真正的工程师完成了一个设计，不管该设计有多么复杂，他们都非常确信该设计是可以工作的。他们也非常确信该设计可以使用公认的技术建造出来。为了做到这一点，硬件工程师花费了大量的时间去验证和改进他们的设计。例如，请考虑一个桥梁设计。在这样一个设计实际建造之前，工程师会进行结构分析——他们建立计算机模型并进行仿真，他们建立比例模型并在风洞中或者用其他一些方法进行测试。简而言之，在建造前，设计者会使用他们能够想到的一切方法来证实设计是正确的。对于一架新型客机的设计来说，情况甚至更加严重；必须要构建出和原物同尺寸的原型，并且必须要进行飞行测试来验证设计中的种种预计。 对于大多数人来说，软件中明显不存在和硬件设计同样严格的工程。然而，如果我们把源代码看做是设计，那么就会发现软件工程师实际上对他们的设计做了大量的验证和改进。软件工程师不把这称为工程，而称它为测试和调试。大多数人不把测试和调试看作是真正的“工程”——在软件行业中肯定没有被看作是。造成这种看法的原因，更多的是因为软件行业拒绝把代码看作设计，而不是任何实际的工程差别。事实上，试验模型、原型以及电路试验板已经成为其他工程学科公认的组成部分。软件设计者之所以不具有或者没有使用更多的正规方法来验证他们的设计，是因为软件构建周期的简单经济规律。 第一个启示：仅仅构建设计并测试它比做任何其他事情要廉价一些，也简单一些。我们不关心做了多少次构建——这些构建在时间方面的代价几乎为零，并且如果我们丢弃了构建，那么它所使用的资源完全可以重新利用。请注意，测试并非仅仅是让当前的设计正确，它也是改进设计的过程的一部分。复杂系统的硬件工程师常常建立模型（或者，至少他们把设计用计算机图形直观地表现出来）。这就使得他们获得了对于设计的一种“感觉”，而仅仅去检查设计是不可能获得这种感觉的。对于软件来说，构建这样一个模型既不可能也无必要。我们仅仅构建产品本身。即使正规的软件验证可以和编译器一样自动进行，我们还是会去进行构建/测试循环。因此，正规的验证对于软件行业来说从来没有太多的实际意义。 这就是现今软件开发过程的现实。数量不断增长的人和机构正在创建着更加复杂的软件设计。这些设计会被先用某些编程语言编写出来，然后通过构建/测试循环进行验证和改进。过程易于出错，并且不是特别的严格。相当多的软件开发人员并不想相信这就是过程的运作方式，也正因为这一点，使问题变得更加复杂。 当前大多数的软件过程都试图把软件设计的不同阶段分离到不同的类别中。必须要在顶层的设计完成并且冻结后，才能开始编码。测试和调试只对清除建造错误是必要的。程序员处在中间位置，他们是软件行业的建造工人。许多人认为，如果我们可以让程序员不再进行“随意的编码（hacking）”并且按照交给他们的设计去进行构建（还要在过程中，犯更少的错误），那么软件开发就可以变得成熟，从而成为一门真正的工程学科。但是，只要过程忽视了工程和经济学事实，这就不可能发生。 例如，任何一个现代行业都无法忍受在其制造过程中出现超过100%的返工率。如果一个建造工人常常不能在第一次就构建正确，那么不久他就会失业。但是在软件业中，即使最小的一块代码，在测试和调试期间，也很可能会被修正或者完全重写。在一个创造性的过程中（比如：设计），我们认可这种改进不是制造过程的一部分。没有人会期望工程师第一次就创建出完美的设计。即使她做到了，仍然必须让它经受改进过程，目的就是为了证明它是完美的。 即使我们从日本的管理方法中没有学到任何东西，我们也应该知道由于在过程中犯错误而去责备工人是无益于提高生产率的。我们不应该不断地强迫软件开发去符合不正确的过程模型，相反，我们需要去改进过程，使之有助于而不是阻碍产生更好的软件。这就是“软件工程”的石蕊测试。工程是关于你如何实施过程的，而不是关于是否需要一个CAD系统来产生最终的设计文档。 关于软件开发有一个压倒性的问题，那就是一切都是设计过程的一部分。编码是设计，测试和调试是设计的一部分，并且我们通常认为的设计仍然是设计的一部分。虽然软件构建起来很廉价，但是设计起来却是难以置信的昂贵。软件非常的复杂，具有众多不同方面的设计内容以及它们所导致的设计考虑。问题在于，所有不同方面的内容是相互关连的（就像硬件工程中的一样）。我们希望顶层设计者可以忽视模块算法设计的细节。同样，我们希望程序员在设计模块内部算法时不必考虑顶层设计问题。糟糕的是，一个设计层面中的问题侵入到了其他层面之中。对于整个软件系统的成功来说，为一个特定模块选择算法可能和任何一个更高层次的设计问题同样重要。在软件设计的不同方面内容中，不存在重要性的等级。最低层模块中的一个不正确设计可能和最高层中的错误一样致命。软件设计必须在所有的方面都是完整和正确的，否则，构建于该设计基础之上的所有软件都会是错误的。 为了管理复杂性，软件被分层设计。当程序员在考虑一个模块的详细设计时，可能还有数以百计的其他模块以及数以千计的细节，他不可能同时顾及。例如，在软件设计中，有一些重要方面的内容不是完全属于数据结构和算法的范畴。在理想情况下，程序员不应该在设计代码时还得去考虑设计的这些其他方面的内容。 但是，设计并不是以这种方式工作的，并且原因也开始变得明朗。软件设计只有在其被编写和测试后才算完成。测试是设计验证和改进过程的基础部分。高层结构的设计不是完整的软件设计；它只是细节设计的一个结构框架。在严格地验证高层设计方面，我们的能力是非常有限的。详细设计最终会对高层设计造成的影响至少和其他的因素一样多（或者应该允许这种影响）。对设计的各个方面进行改进，是一个应该贯穿整个设计周期的过程。如果设计的任何一个方面内容被冻结在改进过程之外，那么对于最终设计将会是糟糕的或者甚至无法工作这一点，就不会觉得奇怪了。 如果高层的软件设计可以成为一个更加严格的工程过程，那该有多好呀，但是软件系统的真实情况不是严格的。软件非常的复杂，它依赖于太多的其他东西。或许，某些硬件没有按照设计者认为的那样工作，或者一个库例程具有一个文档中没有说明的限制。每一个软件项目迟早都会遇到这些种类的问题。这些种类的问题会在测试期间被发现（如果我们的测试工作做得好的话），之所以如此是因为没有办法在早期就发现它们。当它们被发现时，就迫使对设计进行更改。如果我们幸运，那么对设计的更改是局部的。时常，更改会波及到整个软件设计中的一些重要部分（莫非定律）。当受到影响的设计的一部分由于某种原因不能更改时，那么为了能够适应影响，设计的其他部分就必须得遭到破坏。这通常导致的结果就是管理者所认为的“随意编码”，但是这就是软件开发的现实。 例如，在我最近工作的一个项目中，发现了模块A的内部结构和另一个模块B之间的一个时序依赖关系。糟糕的是，模块A的内部结构隐藏在一个抽象体的后面，而该抽象体不允许以任何方法把对模块B的调用合入到它的正确调用序列中。当问题被发现时，当然已经错过了更改A的抽象体的时机。正如所料，所发生的就是把一个日益增长的复杂的“修正”集应用到A的内部设计上。在我们还没有安装完版本1时，就普遍感觉到设计正在衰退。每一个新的修正很可能都会破坏一些老的修正。这是一个正规的软件开发项目。最后，我和我的同事决定对设计进行更改，但是为了得到管理层的同意，我们不得不自愿无偿加班。 在任何一般规模的软件项目中，肯定会出现像这样的问题，尽管人们使用了各种方法来防止它的出现，但是仍然会忽视一些重要的细节。这就是工艺和工程之间的区别。如果经验可以把我们引向正确的方向，这就是工艺。如果经验只会把我们带入未知的领域，然后我们必须使用一开始所使用的方法并通过一个受控的改进过程把它变得更好，这就是工程。 我们来看一下只是作为其中很小一点的内容，所有的程序员都知道，在编码之后而不是之前编写软件设计文档会产生更加准确的文档。现在，原因是显而易见的。用代码来表现的最终设计是惟一一个在构建/测试循环期间被改进的东西。在这个循环期间，初始设计保持不变的可能性和模块的数量以及项目中程序员的数量成反比。它很快就会变得毫无价值。 在软件工程中，我们非常需要在各个层次都优秀的设计。我们特别需要优秀的顶层设计。初期的设计越好，详细设计就会越容易。设计者应该使用任何可以提供帮助的东西。结构图表、Booch 图、状态表、PDL等等——如果它能够提供帮助，就去使用它。但是，我们必须记住，这些工具和符号都不是软件设计。最后，我们必须创建真正的软件设计，并且是使用某种编程语言完成的。因此，当我们得出设计时，我们不应该害怕对它们进行编码。在必要时，我们必须应该乐于去改进它们。 至今，还没有任何设计符号可以同时适用于顶层设计和详细设计。设计最终会表现为以某种编程语言编写的代码。这意味着在详细设计可以开始前，顶层设计符号必须被转换成目标编程语言。这个转换步骤耗费时间并且会引入错误。程序员常常是对需求进行回顾并且重新进行顶层设计，然后根据它们的实际去进行编码，而不是从一个可能没有和所选择的编程语言完全映射的符号进行转换。这同样也是软件开发的部分现实情况。 也许，如果让设计者本人来编写初始代码，而不是后来让其他人去转换语言无关的设计，就会更好一些。我们所需要的是一个适用于各个层次设计的统一符号。换句话说，我们需要一种编程语言，它同样也适用于捕获高层的设计概念。C＋＋正好可以满足这个要求。C++是一门适用于真实项目的编程语言，同时它也是一个非常具有表达力的软件设计语言。C++允许我们直接表达关于设计组件的高层信息。这样，就可以更容易地进行设计，并且以后可以更容易地改进设计。由于它具有更强大的类型检查机制，所以也有助于检测到设计中的错误。这就产生了一个更加健壮的设计，实际上也是一个更好的工程化设计。 最后，软件设计必须要用某种编程语言表现出来，然后通过一个构建/测试循环对其进行验证和改进。除此之外的任何其他主张都完全没有用。请考虑一下都有哪些软件开发工具和技术得以流行。结构化编程在它的时代被认为是创造性的技术。 Pascal使之变得流行，从而自己也变得流行。面向对象设计是新的流行技术，而C++是它的核心。现在，请考虑一下那些没有成效的东西。CASE工具，流行吗？是的；通用吗？不是。结构图表怎么样？情况也一样。同样地，还有Warner-Orr图、Booch图、对象图以及你能想起的一切。每一个都有自己的强项，以及惟一的一个根本弱点——它不是真正的软件设计。事实上，惟一一个可以被普遍认可的软件设计符号是PDL，而它看起来像什么呢？ 这表明，在软件业的共同潜意识中本能地知道，编程技术，特别是实际开发所使用的编程语言的改进和软件行业中任何其他东西相比，具有压倒性的重要性。这还表明，程序员关心的是设计。当出现更加具有表达力的编程语言时，软件开发者就会使用它们。 同样，请考虑一下软件开发过程是如何变化的。从前，我们使用瀑布式过程。现在，我们谈论的是螺旋式开发和快速原型。虽然这种技术常常被认为可以“消除风险” 以及“缩短产品的交付时间”，但是它们事实上也只是为了在软件的生命周期中更早地开始编码。这是好事。这使得构建/测试循环可以更早地开始对设计进行验证和改进。这同样也意味着，顶层软件设计者很有可能也会去进行详细设计。 正如上面所表明的，工程更多的是关于如何去实施过程的，而不是关于最终产品看起来的像什么。处在软件行业中的我们，已经接近工程师的标准，但是我们需要一些认知上的改变。编程和构建/测试循环是工程软件过程的中心。我们需要以像这样的方式去管理它们。构建/测试循环的经济规律，再加上软件系统几乎可以表现任何东西的事实，就使得我们完全不可能找出一种通用的方法来验证软件设计。我们可以改善这个过程，但是我们不能脱离它。 最后一点：任何工程设计项目的目标是一些文档产品。显然，实际设计的文档是最重要的，但是它们并非惟一要产生的文档。最终，会期望某些人来使用软件。同样，系统很可能也需要后续的修改和增强。这意味着，和硬件项目一样，辅助文档对于软件项目具有同样的重要性。虽然暂时忽略了用户手册、安装指南以及其他一些和设计过程没有直接联系的文档，但是仍然有两个重要的需求需要使用辅助设计文档来解决。 辅助文档的第一个用途是从问题空间中捕获重要的信息，这些信息是不能直接在设计中使用的。软件设计需要创造一些软件概念来对问题空间中的概念进行建模。这个过程需要我们得出一个对问题空间中概念的理解。通常，这个理解中会包含一些最后不会被直接建模到软件空间中的信息，但是这些信息却仍然有助于设计者确定什么是本质概念以及如何最好地对它们建模。这些信息应该被记录在某处，以防以后要去更改模型。 对辅助文档的第二个重要需要是对设计的某些方面的内容进行记录，而这些方面的内容是难以直接从设计本身中提取的。它们既可以是高层方面的内容，也可以是低层方面内容。对于这些方面内容中的许多来说，图形是最好的描述方式。这就使得它们难以作为注释包含在代码中。这并不是说要用图形化的软件设计符号代替编程语言。这和用一些文本描述来对硬件科目的图形化设计文档进行补充没有什么区别。 决不要忘记，是源代码决定了实际设计的真实样子，而不是辅助文档。在理想情况下，可以使用软件工具对源代码进行后期处理并产生出辅助文档。对于这一点，我们可能期望过高了。次一点的情况是，程序员（或者技术方面的编写者）可以使用一些工具从源代码中提取出一些特定的信息，然后可以把这些信息以其他一些方式文档化。毫无疑问，手工对这种文档保持更新是困难的。这是另外一个支持需要更具表达力的编程语言的理由。同样，这也是一个支持使这种辅助文档保持最小并且尽可能在项目晚期才使之变成正式的理由。同样，我们可以使用一些好的工具；不然的话，我们就得求助于铅笔、纸以及黑板。 [...]]]></description>
			<content:encoded><![CDATA[<p>什么是软件工程中最重要的产出？毫无疑问是代码。代码是给人读的，偶尔让机器运行一下。为了给读代码的人提供便利，我们就需要给代码一些自描述信息（Meta）。这些Meta信息就是相关的文档，注释等。关于是否需要文档在<a href="http://www.javaeye.com/topic/2813" target="_blank">javaeye</a>还有很激烈的讨论。</p>
<p>下面让我们看看大师是怎么说的：<a href="http://www.developerdotstar.com/mag/articles/PDF/DevDotStar_Reeves_CodeAsDesign.pdf" target="_blank">英文原版</a></p>
<blockquote><p>至今，我仍能记起当我顿悟并最终产生下面文章时所在的地方。那是1986年的夏天，我在加利福尼亚中国湖海军武器中心担任临时顾问。在这期间，我有幸参加了一个关于Ada的研讨会。讨论当中，有一位听众提出了一个具有代表性的问题，“软件开发者是工程师吗？”我不记得当时的回答，但是我却记得当时并没有真正解答这个问题。于是，我就退出讨论，开始思考我会怎样回答这样一个问题。现在，我无法肯定当时我为什么会记起几乎10年前曾经在Datamation杂志上阅读过的一篇论文，不过促使我记起的应该是后续讨论中的某些东西。这篇论文阐述了工程师为什么必须是好的作家（我记得该论文谈论就是这个问题——好久没有看了），但是我从该论文中得到的关键一点是：作者认为工程过程的最终结果是文档。换句话说，工程师生产的是文档，不是实物。其他人根据这些文档去制造实物。于是，我就在困惑中提出了一个问题，“除了软件项目正常产生的所有文档以外，还有可以被认为是真正的工程文档的东西吗？”我给出的回答是，“是的，有这样的文档存在，并且只有一份——源代码。”</p>
<p>把源代码看作是一份工程文档——设计——完全颠覆了我对自己所选择的职业的看法。它改变了我看待一切事情的方式。此外，我对它思考的越多，我就越觉得它阐明了软件项目常常遇到的众多问题。更确切地说，我觉得大多数人不理解这个不同的看法，或者有意拒绝它这样一个事实，就足以说明很多问题。几年后，我终于有机会把我的观点公开发表。C++ Journal中的一篇有关软件设计的论文促使我给编辑写了一封关于这个主题的信。经过几封书信交换后，编辑Livleen Singh同意把我关于这个主题的想法发表为一篇论文。下面就是这篇文章。</p>
<p>——Jack Reecves, December,22,2001</p></blockquote>
<blockquote><p><strong>什么是软件设计？</strong><br />
Jack W.Reeves, 1992</p>
<p>面向对象技术，特别是C++，似乎给软件界带来了不小的震动。出现了大量的论文和书籍去描述如何应用这项新技术。总的来说，那些关于面向对象技术是否只是一个骗局的问题已经被那些关于如何付出最小的努力即可获得收益的问题所替代。面向对象技术出现已经有一段时间了，但是这种爆炸式的流行却似乎有点不寻常。人们为何会突然关注它呢？对于这个问题，人们给出了各种各样的解释。事实上，很可能就没有单一的原因。也许，把多种因素的结合起来才能最终取得突破，并且这项工作正在进展之中。尽管如此，在软件革命的这个最新阶段中，C++本身看起来似乎成为了一个主要因素。同样，对于这个问题，很可能也存在很多种理由，不过我想从一个稍微不同的视角给出一个答案：C++之所以变得流行，是因为它使软件设计变得更容易的同时，也使编程变得更容易。</p>
<p>虽然这个解释好像有点奇特，但是它却是深思熟虑的结果。在这篇论文中，我就是想要关注一下编程和程序设计之间的关系。近10年来，我一直觉得整个软件行业都没有觉察到做出一个软件设计和什么是真正的软件设计之间的一个微妙的不同点。只要看到了这一点，我认为我们就可以从C++增长的流行趋势中，学到关于如何才能成为更好的软件工程师的意义深远的知识。这个知识就是，编程不是构建软件，而是设计软件。</p>
<p>几年前，我参见了一个讨论会，其中讨论到软件开发是否是一门工程学科的问题。虽然我不记得了讨论结果，但是我却记得它是如何促使我认识到：软件业已经做出了一些错误的和硬件工程的比较，而忽视了一些绝对正确的对比。其实，我认为我们不是软件工程师，因为我们没有认识到什么才是真正的软件设计。现在，我对这一点更是确信无疑。</p>
<p>任何工程活动的最终目标都是某些类型的文档。当设计工作完成时，设计文档就被转交给制造团队。该团队是一个和设计团队完全不同的群体，并且其技能也和设计团队完全不同。如果设计文档正确地描绘了一个完整的设计，那么制造团队就可以着手构建产品。事实上，他们可以着手构建该产品的许多实物，完全无需设计者的任何进一步的介入。在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的惟一软件文档，就是源代码清单。</p>
<p>对于这个观点，人们进行了很多的争论，无论是赞成的还是反对的都足以写成无数的论文。本文假定最终的源代码就是真正的软件设计，然后仔细研究了该假定带来的一些结果。我可能无法证明这个观点是正确的，但是我希望证明：它确实解释了软件行业中一些已经观察到的事实，包括C++的流行。</p>
<p>在把代码看作是软件设计所带来的结果中，有一个结果完全盖过了所有其他的结果。它非常重要并且非常明显，也正因为如此，对于大多数软件机构来说，它完全是一个盲点。这个结果就是：软件的构建是廉价的。它根本就不具有昂贵的资格；它非常的廉价，几乎就是免费的。如果源代码是软件设计，那么实际的软件构建就是由编译器和连接器完成的。我们常常把编译和连接一个完整的软件系统的过程称为“进行一次构建”。在软件构建设备上所进行的主要投资是很少的——实际需要的只有一台计算机、一个编辑器、一个编译器以及一个连接器。一旦具有了一个构建环境，那么实际的软件构建只需花费少许的时间。编译50 000行的C++程序也许会花费很长的时间，但是构建一个具有和50 000行C++程序同样设计复杂性的硬件系统要花费多长的时间呢？</p>
<p>把源代码看作是软件设计的另外一个结果是，软件设计相对易于创作，至少在机械意义上如此。通常，编写（也就是设计）一个具有代表性的软件模块（50至100行代码）只需花费几天的时间（对它进行完全的调试是另外一个议题，稍后会对它进行更多的讨论）。我很想问一下，是否还有任何其他的学科可以在如此短的时间内，产生出和软件具有同样复杂性的设计来，不过，首先我们必须要弄清出如何来度量和比较复杂性。然而，有一点是明显的，那就是软件设计可以 极为迅速地变得非常庞大。</p>
<p>假设软件设计相对易于创作，并且在本质上构建起来也没有什么代价，一个不令人吃惊的发现是，软件设计往往是难以置信的庞大和复杂。这看起来似乎很明显，但是问题的重要性却常常被忽视。学校中的项目通常具有数千行的代码。具有10 000行代码（设计）的软件产品被它们的设计者丢弃的情况也是有的。我们早就不再关注于简单的软件。典型的商业软件的设计都是由数十万行代码组成的。许多软件设计达到了上百万行代码。另外，软件设计几乎总是在不断地演化。虽然当前的设计可能只有几千行代码，但是在产品的生命期中，实际上可能要编写许多倍的代码。</p>
<p>尽管确实存在一些硬件设计，它们看起来似乎和软件设计一样复杂，但是请注意两个有关现代硬件的事实。第一，复杂的硬件工程成果未必总是没有错误的，在这一点上，它不存在像软件那样让我们相信的评判标准。多数的微处理器在发售时都具有一些逻辑错误：桥梁坍塌，大坝破裂，飞机失事以及数以千计的汽车和其他消费品被召回——所有的这些我们都记忆犹新，所有的这些都是设计错误的结果。第二，复杂的硬件设计具有与之对应的复杂、昂贵的构建阶段。结果，制造这种系统所需的能力限制了真正能够生产复杂硬件设计公司的数目。对于软件来说，没有这种限制。目前，已经有数以百计的软件机构和数以千计的非常复杂的软件系统存在，并且数量以及复杂性每天都在增长。这意味着软件行业不可能通过仿效硬件开发者找到针对自身问题的解决办法。倘若一定要说出有什么相同之处的话，那就是，当CAD和CAM可以做到帮助硬件设计者创建越来越复杂的设计时，硬件工程才会变得和软件开发越来越像。</p>
<p>设计软件是一种管理复杂性的活动。复杂性存在于软件设计本身之中，存在于公司的软件机构之中，也存在于整个软件行业之中。软件设计和系统设计非常相似。它可以跨越多种技术并且常常涉及多个学科分支。软件的规格说明往往不固定、经常快速变化，这种变化常常在正进行软件设计时发生。同样，软件开发团队也往往不固定，常常在设计过程的中间发生变化。在许多方面，软件都要比硬件更像复杂的社会或者有机系统。所有这些都使得软件设计成为了一个困难的并且易出错的过程。虽然所有这些都不是创造性的想法，但是在软件工程革命开始将近30年后的今天，和其他工程行业相比，软件开发看起来仍然像是一种未受过训练（undisciplined）的技艺。</p>
<p>一般的看法认为，当真正的工程师完成了一个设计，不管该设计有多么复杂，他们都非常确信该设计是可以工作的。他们也非常确信该设计可以使用公认的技术建造出来。为了做到这一点，硬件工程师花费了大量的时间去验证和改进他们的设计。例如，请考虑一个桥梁设计。在这样一个设计实际建造之前，工程师会进行结构分析——他们建立计算机模型并进行仿真，他们建立比例模型并在风洞中或者用其他一些方法进行测试。简而言之，在建造前，设计者会使用他们能够想到的一切方法来证实设计是正确的。对于一架新型客机的设计来说，情况甚至更加严重；必须要构建出和原物同尺寸的原型，并且必须要进行飞行测试来验证设计中的种种预计。</p>
<p>对于大多数人来说，软件中明显不存在和硬件设计同样严格的工程。然而，如果我们把源代码看做是设计，那么就会发现软件工程师实际上对他们的设计做了大量的验证和改进。软件工程师不把这称为工程，而称它为测试和调试。大多数人不把测试和调试看作是真正的“工程”——在软件行业中肯定没有被看作是。造成这种看法的原因，更多的是因为软件行业拒绝把代码看作设计，而不是任何实际的工程差别。事实上，试验模型、原型以及电路试验板已经成为其他工程学科公认的组成部分。软件设计者之所以不具有或者没有使用更多的正规方法来验证他们的设计，是因为软件构建周期的简单经济规律。</p>
<p>第一个启示：仅仅构建设计并测试它比做任何其他事情要廉价一些，也简单一些。我们不关心做了多少次构建——这些构建在时间方面的代价几乎为零，并且如果我们丢弃了构建，那么它所使用的资源完全可以重新利用。请注意，测试并非仅仅是让当前的设计正确，它也是改进设计的过程的一部分。复杂系统的硬件工程师常常建立模型（或者，至少他们把设计用计算机图形直观地表现出来）。这就使得他们获得了对于设计的一种“感觉”，而仅仅去检查设计是不可能获得这种感觉的。对于软件来说，构建这样一个模型既不可能也无必要。我们仅仅构建产品本身。即使正规的软件验证可以和编译器一样自动进行，我们还是会去进行构建/测试循环。因此，正规的验证对于软件行业来说从来没有太多的实际意义。</p>
<p>这就是现今软件开发过程的现实。数量不断增长的人和机构正在创建着更加复杂的软件设计。这些设计会被先用某些编程语言编写出来，然后通过构建/测试循环进行验证和改进。过程易于出错，并且不是特别的严格。相当多的软件开发人员并不想相信这就是过程的运作方式，也正因为这一点，使问题变得更加复杂。</p>
<p>当前大多数的软件过程都试图把软件设计的不同阶段分离到不同的类别中。必须要在顶层的设计完成并且冻结后，才能开始编码。测试和调试只对清除建造错误是必要的。程序员处在中间位置，他们是软件行业的建造工人。许多人认为，如果我们可以让程序员不再进行“随意的编码（hacking）”并且按照交给他们的设计去进行构建（还要在过程中，犯更少的错误），那么软件开发就可以变得成熟，从而成为一门真正的工程学科。但是，只要过程忽视了工程和经济学事实，这就不可能发生。</p>
<p>例如，任何一个现代行业都无法忍受在其制造过程中出现超过100%的返工率。如果一个建造工人常常不能在第一次就构建正确，那么不久他就会失业。但是在软件业中，即使最小的一块代码，在测试和调试期间，也很可能会被修正或者完全重写。在一个创造性的过程中（比如：设计），我们认可这种改进不是制造过程的一部分。没有人会期望工程师第一次就创建出完美的设计。即使她做到了，仍然必须让它经受改进过程，目的就是为了证明它是完美的。</p>
<p>即使我们从日本的管理方法中没有学到任何东西，我们也应该知道由于在过程中犯错误而去责备工人是无益于提高生产率的。我们不应该不断地强迫软件开发去符合不正确的过程模型，相反，我们需要去改进过程，使之有助于而不是阻碍产生更好的软件。这就是“软件工程”的石蕊测试。工程是关于你如何实施过程的，而不是关于是否需要一个CAD系统来产生最终的设计文档。</p>
<p>关于软件开发有一个压倒性的问题，那就是一切都是设计过程的一部分。编码是设计，测试和调试是设计的一部分，并且我们通常认为的设计仍然是设计的一部分。虽然软件构建起来很廉价，但是设计起来却是难以置信的昂贵。软件非常的复杂，具有众多不同方面的设计内容以及它们所导致的设计考虑。问题在于，所有不同方面的内容是相互关连的（就像硬件工程中的一样）。我们希望顶层设计者可以忽视模块算法设计的细节。同样，我们希望程序员在设计模块内部算法时不必考虑顶层设计问题。糟糕的是，一个设计层面中的问题侵入到了其他层面之中。对于整个软件系统的成功来说，为一个特定模块选择算法可能和任何一个更高层次的设计问题同样重要。在软件设计的不同方面内容中，不存在重要性的等级。最低层模块中的一个不正确设计可能和最高层中的错误一样致命。软件设计必须在所有的方面都是完整和正确的，否则，构建于该设计基础之上的所有软件都会是错误的。</p>
<p>为了管理复杂性，软件被分层设计。当程序员在考虑一个模块的详细设计时，可能还有数以百计的其他模块以及数以千计的细节，他不可能同时顾及。例如，在软件设计中，有一些重要方面的内容不是完全属于数据结构和算法的范畴。在理想情况下，程序员不应该在设计代码时还得去考虑设计的这些其他方面的内容。</p>
<p>但是，设计并不是以这种方式工作的，并且原因也开始变得明朗。软件设计只有在其被编写和测试后才算完成。测试是设计验证和改进过程的基础部分。高层结构的设计不是完整的软件设计；它只是细节设计的一个结构框架。在严格地验证高层设计方面，我们的能力是非常有限的。详细设计最终会对高层设计造成的影响至少和其他的因素一样多（或者应该允许这种影响）。对设计的各个方面进行改进，是一个应该贯穿整个设计周期的过程。如果设计的任何一个方面内容被冻结在改进过程之外，那么对于最终设计将会是糟糕的或者甚至无法工作这一点，就不会觉得奇怪了。</p>
<p>如果高层的软件设计可以成为一个更加严格的工程过程，那该有多好呀，但是软件系统的真实情况不是严格的。软件非常的复杂，它依赖于太多的其他东西。或许，某些硬件没有按照设计者认为的那样工作，或者一个库例程具有一个文档中没有说明的限制。每一个软件项目迟早都会遇到这些种类的问题。这些种类的问题会在测试期间被发现（如果我们的测试工作做得好的话），之所以如此是因为没有办法在早期就发现它们。当它们被发现时，就迫使对设计进行更改。如果我们幸运，那么对设计的更改是局部的。时常，更改会波及到整个软件设计中的一些重要部分（莫非定律）。当受到影响的设计的一部分由于某种原因不能更改时，那么为了能够适应影响，设计的其他部分就必须得遭到破坏。这通常导致的结果就是管理者所认为的“随意编码”，但是这就是软件开发的现实。</p>
<p>例如，在我最近工作的一个项目中，发现了模块A的内部结构和另一个模块B之间的一个时序依赖关系。糟糕的是，模块A的内部结构隐藏在一个抽象体的后面，而该抽象体不允许以任何方法把对模块B的调用合入到它的正确调用序列中。当问题被发现时，当然已经错过了更改A的抽象体的时机。正如所料，所发生的就是把一个日益增长的复杂的“修正”集应用到A的内部设计上。在我们还没有安装完版本1时，就普遍感觉到设计正在衰退。每一个新的修正很可能都会破坏一些老的修正。这是一个正规的软件开发项目。最后，我和我的同事决定对设计进行更改，但是为了得到管理层的同意，我们不得不自愿无偿加班。</p>
<p>在任何一般规模的软件项目中，肯定会出现像这样的问题，尽管人们使用了各种方法来防止它的出现，但是仍然会忽视一些重要的细节。这就是工艺和工程之间的区别。如果经验可以把我们引向正确的方向，这就是工艺。如果经验只会把我们带入未知的领域，然后我们必须使用一开始所使用的方法并通过一个受控的改进过程把它变得更好，这就是工程。</p>
<p>我们来看一下只是作为其中很小一点的内容，所有的程序员都知道，在编码之后而不是之前编写软件设计文档会产生更加准确的文档。现在，原因是显而易见的。用代码来表现的最终设计是惟一一个在构建/测试循环期间被改进的东西。在这个循环期间，初始设计保持不变的可能性和模块的数量以及项目中程序员的数量成反比。它很快就会变得毫无价值。</p>
<p>在软件工程中，我们非常需要在各个层次都优秀的设计。我们特别需要优秀的顶层设计。初期的设计越好，详细设计就会越容易。设计者应该使用任何可以提供帮助的东西。结构图表、Booch 图、状态表、PDL等等——如果它能够提供帮助，就去使用它。但是，我们必须记住，这些工具和符号都不是软件设计。最后，我们必须创建真正的软件设计，并且是使用某种编程语言完成的。因此，当我们得出设计时，我们不应该害怕对它们进行编码。在必要时，我们必须应该乐于去改进它们。</p>
<p>至今，还没有任何设计符号可以同时适用于顶层设计和详细设计。设计最终会表现为以某种编程语言编写的代码。这意味着在详细设计可以开始前，顶层设计符号必须被转换成目标编程语言。这个转换步骤耗费时间并且会引入错误。程序员常常是对需求进行回顾并且重新进行顶层设计，然后根据它们的实际去进行编码，而不是从一个可能没有和所选择的编程语言完全映射的符号进行转换。这同样也是软件开发的部分现实情况。</p>
<p>也许，如果让设计者本人来编写初始代码，而不是后来让其他人去转换语言无关的设计，就会更好一些。我们所需要的是一个适用于各个层次设计的统一符号。换句话说，我们需要一种编程语言，它同样也适用于捕获高层的设计概念。C＋＋正好可以满足这个要求。C++是一门适用于真实项目的编程语言，同时它也是一个非常具有表达力的软件设计语言。C++允许我们直接表达关于设计组件的高层信息。这样，就可以更容易地进行设计，并且以后可以更容易地改进设计。由于它具有更强大的类型检查机制，所以也有助于检测到设计中的错误。这就产生了一个更加健壮的设计，实际上也是一个更好的工程化设计。</p>
<p>最后，软件设计必须要用某种编程语言表现出来，然后通过一个构建/测试循环对其进行验证和改进。除此之外的任何其他主张都完全没有用。请考虑一下都有哪些软件开发工具和技术得以流行。结构化编程在它的时代被认为是创造性的技术。 Pascal使之变得流行，从而自己也变得流行。面向对象设计是新的流行技术，而C++是它的核心。现在，请考虑一下那些没有成效的东西。CASE工具，流行吗？是的；通用吗？不是。结构图表怎么样？情况也一样。同样地，还有Warner-Orr图、Booch图、对象图以及你能想起的一切。每一个都有自己的强项，以及惟一的一个根本弱点——它不是真正的软件设计。事实上，惟一一个可以被普遍认可的软件设计符号是PDL，而它看起来像什么呢？</p>
<p>这表明，在软件业的共同潜意识中本能地知道，编程技术，特别是实际开发所使用的编程语言的改进和软件行业中任何其他东西相比，具有压倒性的重要性。这还表明，程序员关心的是设计。当出现更加具有表达力的编程语言时，软件开发者就会使用它们。</p>
<p>同样，请考虑一下软件开发过程是如何变化的。从前，我们使用瀑布式过程。现在，我们谈论的是螺旋式开发和快速原型。虽然这种技术常常被认为可以“消除风险” 以及“缩短产品的交付时间”，但是它们事实上也只是为了在软件的生命周期中更早地开始编码。这是好事。这使得构建/测试循环可以更早地开始对设计进行验证和改进。这同样也意味着，顶层软件设计者很有可能也会去进行详细设计。</p>
<p>正如上面所表明的，工程更多的是关于如何去实施过程的，而不是关于最终产品看起来的像什么。处在软件行业中的我们，已经接近工程师的标准，但是我们需要一些认知上的改变。编程和构建/测试循环是工程软件过程的中心。我们需要以像这样的方式去管理它们。构建/测试循环的经济规律，再加上软件系统几乎可以表现任何东西的事实，就使得我们完全不可能找出一种通用的方法来验证软件设计。我们可以改善这个过程，但是我们不能脱离它。</p>
<p>最后一点：任何工程设计项目的目标是一些文档产品。显然，实际设计的文档是最重要的，但是它们并非惟一要产生的文档。最终，会期望某些人来使用软件。同样，系统很可能也需要后续的修改和增强。这意味着，和硬件项目一样，辅助文档对于软件项目具有同样的重要性。虽然暂时忽略了用户手册、安装指南以及其他一些和设计过程没有直接联系的文档，但是仍然有两个重要的需求需要使用辅助设计文档来解决。</p>
<p>辅助文档的第一个用途是从问题空间中捕获重要的信息，这些信息是不能直接在设计中使用的。软件设计需要创造一些软件概念来对问题空间中的概念进行建模。这个过程需要我们得出一个对问题空间中概念的理解。通常，这个理解中会包含一些最后不会被直接建模到软件空间中的信息，但是这些信息却仍然有助于设计者确定什么是本质概念以及如何最好地对它们建模。这些信息应该被记录在某处，以防以后要去更改模型。</p>
<p>对辅助文档的第二个重要需要是对设计的某些方面的内容进行记录，而这些方面的内容是难以直接从设计本身中提取的。它们既可以是高层方面的内容，也可以是低层方面内容。对于这些方面内容中的许多来说，图形是最好的描述方式。这就使得它们难以作为注释包含在代码中。这并不是说要用图形化的软件设计符号代替编程语言。这和用一些文本描述来对硬件科目的图形化设计文档进行补充没有什么区别。</p>
<p>决不要忘记，是源代码决定了实际设计的真实样子，而不是辅助文档。在理想情况下，可以使用软件工具对源代码进行后期处理并产生出辅助文档。对于这一点，我们可能期望过高了。次一点的情况是，程序员（或者技术方面的编写者）可以使用一些工具从源代码中提取出一些特定的信息，然后可以把这些信息以其他一些方式文档化。毫无疑问，手工对这种文档保持更新是困难的。这是另外一个支持需要更具表达力的编程语言的理由。同样，这也是一个支持使这种辅助文档保持最小并且尽可能在项目晚期才使之变成正式的理由。同样，我们可以使用一些好的工具；不然的话，我们就得求助于铅笔、纸以及黑板。</p>
<p>总结如下：<br />
实际的软件运行于计算机之中。它是存储在某种磁介质中的0和1的序列。它不是使用C++语言（或者其他任何编程语言）编写的程序。<br />
程序清单是代表软件设计的文档。实际上把软件设计构建出来的是编译器和连接器。<br />
构建实际软件设计的廉价程度是令人难以置信的，并且它始终随着计算机速度的加快而变得更加廉价。<br />
设计实际软件的昂贵程度是令人难以置信的，之所以如此，是因为软件的复杂性是令人难以置信的，并且软件项目的几乎所有步骤都是设计过程的一部分。<br />
编程是一种设计活动——好的软件设计过程认可这一点，并且在编码显得有意义时，就会毫不犹豫的去编码。<br />
编码要比我们所认为的更频繁地显现出它的意义。通常，在代码中表现设计的过程会揭示出一些疏漏以及额外的设计需要。这发生的越早，设计就会越好。<br />
因为软件构建起来非常廉价，所以正规的工程验证方法在实际的软件开发中没有多大用处。仅仅建造设计并测试它要比试图去证明它更简单、更廉价。<br />
测试和调试是设计活动——对于软件来说，它们就相当于其他工程学科中的设计验证和改进过程。好的软件设计过程认可这一点，并且不会试图去减少这些步骤。<br />
还有一些其他的设计活动——称它们为高层设计、模块设计、结构设计、构架设计或者诸如此类的东西。好的软件设计过程认可这一点，并且慎重地包含这些步骤。<br />
所有的设计活动都是相互影响的。好的软件设计过程认可这一点，并且当不同的设计步骤显示出有必要时，它会允许设计改变，有时甚至是根本上的改变，<br />
许多不同的软件设计符号可能是有用的——它们可以作为辅助文档以及工具来帮助简化设计过程。它们不是软件设计。<br />
软件开发仍然还是一门工艺，而不是一个工程学科。主要是因为缺乏验证和改善设计的关键过程中所需的严格性。<br />
最后，软件开发的真正进步依赖于编程技术的进步，而这又意味着编程语言的进步。C++就是这样的一个进步。它已经取得了爆炸式的流行，因为它是一门直接支持更好的软件设计的主流编程语言。<br />
C++在正确的方向上迈出了一步，但是还需要更大的进步。</p></blockquote>
<blockquote><p><strong>后 记</strong></p>
<p>当我回顾几乎10年前所写的东西时，有几点让我印象深刻。第一点（也是和本书最有关的）是，现今，我甚至比那时更加确信我试图去阐述的要点在本质上的正确性。随后的一些年中，许多流行的软件开发方法增强了其中的许多观点，这支持了我的信念。最明显的（或许也是最不重要的）是面向对象编程语言的流行。现在，除了C++外，出现了许多其他的面向对象编程语言。另外，还有一些面向对象设计符号，比如：UML。我关于面向对象语言之所以得到流行是因为它们允许在代码中直接表现出更具表达力的设计的论点，现在看来有点过时了。</p>
<p>重构的概念——重新组织代码基础，使之更加健壮和可重用——同样也和我的关于设计的所有方面的内容都应该是灵活的并且在验证设计时允许改变的论点相似。重构只是提供了一个过程以及一组如何去改善已经被证实具有缺陷的设计的准则。</p>
<p>最后，文中有一个敏捷开发的总的概念。虽然极限编程是这些新方法中最知名的一个，但是它们都具有一个共同点：它们都承认源代码是软件开发工作中的最重要的产品。</p>
<p>另一方面，有一些观点——其中的一些我在论文中略微谈到过——在随后的一些年中，对我来说变得更加重要。第一个是构架，或者顶层设计的重要性。在论文中，我认为构架只是设计的一部分内容，并且在构建/测试循环对设计进行验证的过程中，构架需要保持可变。这在本质上是正确的，但是回想起来，我认为我的想法有点不成熟。虽然构建/测试循环可能揭示出构架中的问题，但是更多的问题是常常由于改变需求而表现出来的。 一般来说，设计软件是困难的，并且新的编程语言，比如：Java或者C++，以及图形化的符号，比如：UML，对于不知道如何有效地使用它的人来说，都没有多大的帮助。此外，一旦一个项目基于一个构架构建了大量的代码，那么对该构架进行基础性的更改，常常相当于丢弃掉该项目并重新开始一个，这就意味着该项目没有出现过。即使项目和机构在根本上接受了重构的概念，但是他们通常仍然不愿意去做一些看起来就像是完全重写的事情。这意味着第一次就把它作对（或者至少是接近对）是重要的，并且项目变得越大，就越要如此。幸运的是，软件设计模式有助于解决这方面问题。</p>
<p>还有其他一些方面的内容，我认为需要更多地强调一下，其中之一就是辅助文档，尤其是构架方面的文档。虽然源代码就是设计，但是试图从源代码中得出构架，可能是一个令人畏惧的体验。在论文中，我希望能够出现一些软件工具来帮助软件开发者自动地维护来自源代码的辅助文档。我几乎已经放弃了这个希望。一个好的面向对象构架通常可以使用几幅图以及少许的十几页文本描述出来。不过，这些图（和文本）必须集中于设计中的关键类和关系。糟糕的是，对于软件设计工具可能会变得足够聪明，以至于可以从源代码的大量细节中提取出这些重要方面的内容这一点，我没有看到任何真正的希望。这意味着还得必须由人来编写和维护这种文档。我仍然认为，在源代码完成后，或者至少是在编写源代码的同时去编文档，要比在编写源代码之前去编写文档更好一些。</p>
<p>最后，我在论文的最后谈到了C++是编程——并且因此是软件设计——艺术的一个进步，但是还需要更大的进步。就算我完全没有看到语言中出现任何真正的编程进步来挑战C++的流行，那么在今天，我会认为这一点甚至要比我首次编写它时更加正确。</p>
<p>——Jack Reeves, 2002年1月1日</p></blockquote>
<hr />
<p><small>© Daniel Wang for <a href="http://www.tairan.net">Tairan&#039;s Story</a>, 2008. |
<a href="http://www.tairan.net/index.php/2008/11/21/code-as-design/">Permalink</a> |
<a href="http://www.tairan.net/index.php/2008/11/21/code-as-design/#comments">No comment</a> |
Add to
<a href="http://del.icio.us/post?url=http://www.tairan.net/index.php/2008/11/21/code-as-design/&title=编程不是构建软件，而是设计软件。&#8211; 源码就是设计">del.icio.us</a>
<br/>
Post tags: <a href="http://www.tairan.net/index.php/tag/thinking/" rel="tag">Thinking</a>, <a href="http://www.tairan.net/index.php/tag/software-development/" rel="tag">软件开发</a><br/>
</small></p>
<p><small>Feed enhanced by <a href='http://planetozh.com/blog/my-projects/wordpress-plugin-better-feed-rss/'>Better Feed</a> from  <a href='http://planetozh.com/blog/'>Ozh</a></small></p>
]]></content:encoded>
			<wfw:commentRss>http://www.tairan.net/index.php/2008/11/21/code-as-design/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Decade of Programming Institute</title>
		<link>http://www.tairan.net/index.php/2008/08/12/decade-of-programming-institute/</link>
		<comments>http://www.tairan.net/index.php/2008/08/12/decade-of-programming-institute/#comments</comments>
		<pubDate>Mon, 11 Aug 2008 18:12:00 +0000</pubDate>
		<dc:creator>Daniel Wang</dc:creator>
				<category><![CDATA[Technology 转载]]></category>
		<category><![CDATA[参考消息]]></category>
		<category><![CDATA[精彩文章]]></category>
		<category><![CDATA[十年学会编程]]></category>

		<guid isPermaLink="false">http://tairan.wordpress.com/2008/08/12/30/</guid>
		<description><![CDATA[十年学会编程 著者： Peter Norvig翻译： Dai Yuwen 为何人人都这么着急？ 信步走进任何一家书店，你会看到名为《如何在7天内学会Java》的书，还有各种各样类似的书：在几天内或几小时内学会Visual Basic, Windows, Internet等等，一眼望不到尽头。我在Amazon 上做了如下的 强力检索 ： pubdate: after 1992 and title: days and (title: learn or title: teach yourself) 得到了248个结果。前78个都是计算机类书籍（第79个是 Learn Bengali in 30 days）。我用&#8221;hours&#8221;替换&#8221;days&#8221;，得到了类似的结果：更多的253书。前77本是计算机类书籍，第78本是 Teach Yourself Grammar and Style in 24 Hours。在前200本书中，有96% 是计算机类书籍。 结论是：要么人们都在忙忙地学习计算机，要么计算机比其它任何东西都容易学。没有书籍教你在几天内学会古典音乐、量子物理，或者是养狗。 让我们分析一下，象一本名为《三天内学会Pascal》的书意味着什么： * 学习： 在三天里，你没有时间写一些重大的程序，并从成功或失败中得益。你没有时间与有经验的程序员合作，并理解在那样的环境下工作是怎么回事。一句话，你不会有时间学到太多东西。因此他们只能谈论一些肤浅的东西，而不是深入的理解。正如亚力山大教皇所说，浅尝辄止是危险的事情。 * Pascal： 在三天时间里，你可能学会Pascal的语法（如果你已经学过类似的语言），但你学不到更多的如何使用这些语法的知识。也就是说，假如你曾是个BASIC 程序员，你可以学着用Pascal语法写出BASIC风格的程序，但你不可能了解Pascal真正的好处（和坏处）。那么关键是什么？ Alan Perlis 说过：“一种不改变你编程的思维方式的语言，不值得去学。” 一种可能的情况是：你必须学一点儿Pascal（或可能性更大的象Visual [...]]]></description>
			<content:encoded><![CDATA[<h1>十年学会编程</h1>
<p>著者： Peter Norvig<br />翻译： Dai Yuwen <br />
<h2>为何人人都这么着急？<br /></h2>
<p>信步走进任何一家书店，你会看到名为《如何在7天内学会Java》的书，还有各种各样类似的书：在几天内或几小时内学会Visual Basic, Windows, Internet等等，一眼望不到尽头。我在Amazon 上做了如下的 强力检索 ：<br />     pubdate: after 1992 and title: days and<br />      (title: learn or title: teach yourself)</p>
<p>得到了248个结果。前78个都是计算机类书籍（第79个是 Learn Bengali in 30 days）。我用&#8221;hours&#8221;替换&#8221;days&#8221;，得到了类似的结果：更多的253书。前77本是计算机类书籍，第78本是 Teach Yourself Grammar and Style in 24 Hours。在前200本书中，有96% 是计算机类书籍。</p>
<p>结论是：要么人们都在忙忙地学习计算机，要么计算机比其它任何东西都容易学。没有书籍教你在几天内学会古典音乐、量子物理，或者是养狗。</p>
<p>让我们分析一下，象一本名为《三天内学会Pascal》的书意味着什么：</p>
<p>    * 学习： 在三天里，你没有时间写一些重大的程序，并从成功或失败中得益。你没有时间与有经验的程序员合作，并理解在那样的环境下工作是怎么回事。一句话，你不会有时间学到太多东西。因此他们只能谈论一些肤浅的东西，而不是深入的理解。正如亚力山大教皇所说，浅尝辄止是危险的事情。</p>
<p>    * Pascal： 在三天时间里，你可能学会Pascal的语法（如果你已经学过类似的语言），但你学不到更多的如何使用这些语法的知识。也就是说，假如你曾是个BASIC 程序员，你可以学着用Pascal语法写出BASIC风格的程序，但你不可能了解Pascal真正的好处（和坏处）。那么关键是什么？ Alan Perlis 说过：“一种不改变你编程的思维方式的语言，不值得去学。” 一种可能的情况是：你必须学一点儿Pascal（或可能性更大的象Visual Basic 或 JavaScript之类），因为你为了完成某种特定的任务，需要与一个现存的工具建立接口。不过那不是学习如何编程，而是在学习如何完成那个任务。</p>
<p>    * 三天内： 很不幸，这不够，原因由下一节告诉我们。</p>
<h2>在十年里学会编程<br /></h2>
<p>研究表明 (Hayes，Bloom) 在任何一种领域内，象下棋、作曲、绘画、钢琴演奏、游泳、网球、以及原子物理学和拓扑学，等等，要达到专家水平大约都要化十年时间。没有真正的捷径：即使是莫扎特，4岁时就是音乐神童，13年后才开始写出世界级的作品。在另一方面，披头士似乎在1964年的Ed Sullivan表演上一炮走红。但他们从1957年就开始表演，在获得大众青睐后，他们的第一个重大成功，Sgt. Peppers，是1967年发行的。Samuel Johnson （塞缪尔·约翰逊，英国辞典编纂家及作家）认为要花比十年更长的时间：“在任何领域中出类拔萃都要用毕生的劳作来取得；它不可能用较低的代价获得。” 而Chaucer（乔叟，英国诗人）感叹到：“人生短暂，学海无涯。”</p>
<p>这是我为编程成功开出的方子：</p>
<p>    * 设法对编程感兴趣，并且因为它有趣而编一些程序。确保编程一直充满足够乐趣，这样你才愿意投入十年宝贵时间。</p>
<p>    * 与其他程序员交流； 阅读其它程序。这比任何书本或训练课程都重要。</p>
<p>    * 写程序。 最好的学习方式是 从实践中学习。 用更技术性的话说，“在一个给定的领域内，个人的最大能力不是自动地由扩展了的经验取得的，但即使是高度有经验的人也可以通过有意识的努力来提高自己的能力” (p. 366) 和 “最有效的学习需要因人而异的适当难度，目标明确的任务，丰富的信息反馈，以及重复的机会和错误修正。” (p. 20-21) 此书 Cognition in Practice: Mind，Mathematics，and Culture in Everyday Life 是阐明此观点的令人感兴趣的参考文献。</p>
<p>    * 如果愿意，在大学里呆上4年或更长（在研究生院里）。你会接触到一些需要学历证明的工作，你会对此领域有更深的理解。如果你不喜欢学校，你可以（通过一些贡献）在工作中获得相似的经验。在任何情况下，光啃书本是不够的。Eric Raymond，The New Hacker&#8217;s Dictionary一书的作者，说过，“计算机科学不能把任何人变成编程专家，就象光研究刷子和颜料不会使人变成画家一样。” 我雇佣过的最好的程序员之一仅有高中程度；他做出了许多优秀的 软件，有他自己的新闻组，而且通过股票期权，他无疑比我富有的多。</p>
<p>    * 和其他程序员一起做项目。在其中的一些项目中作为最好的程序员； 而在另一些项目中是最差的。当你是最好的，你能测试领导项目的能力，用你的观点激发别人。当你是最差的，你学习杰出者是怎么做的，了解他们不喜欢做什么（因为他们吩咐你做事）。</p>
<p>    * 在其他程序员 之后接手项目。使自己理解别人写的程序。当程序的原作者不在的时候，研究什么需要理解并且修改它。思考如何设计你的程序以便后来者的维护。</p>
<p>    * 学习至少半打的编程语言。包括一种支持类抽象的语言（象Java 或C++），一种支持函数化抽象的语言（象Lisp或ML），一种支持语法抽象的语言（象 Lisp），一种支持声明规格说明的语言（象Prolog或C++ 的模板），一种支持共行程序（coroutine）的语言（象Icon或Scheme），一种支持并行的语言（象Sisal）。</p>
<p>    * 请记住“计算机科学”中有“计算机”一词。了解你的计算机要花多长时间执行一条指令，从内存中取一个字（有cache），从磁盘中读取连续的字，和在磁盘中找到新的位置。（答案）</p>
<p>    * 参与一种语言标准化的工作。它可以是ANSI C++委员会，也可以是决定你周围小范围内的编程风格是应该两个还是四个空格缩进。通过任何一种方式，你了解到其他人在某种语言中的想法，他们的理解深度，甚至一些他们这样想的原因。</p>
<p>    * 找到适当的理由尽快地从语言标准化的努力中脱身。</p>
<p>明白了这些，仅从书本中你能得到多少就成了一个问题。在我第一个孩子出生前，我读了所有的（关于育儿的）How to 书籍，仍然感觉是个手足无措的新手。30个月以后，我的第二个孩子快要出生了，我回头温习这些书了吗？ 没有。相反，我依靠我的个人经验，它比专家写的数千页书更有用和可靠。</p>
<p>Fred Brooks在他的随笔 《没有银弹》 中定出了一个寻找优秀软件设计者的三步计划：</p>
<p>   1. 尽可能早地，有系统地识别顶级的设计人员。</p>
<p>   2. 为设计人员指派一位职业导师，负责他们技术方面的成长，仔细地为他们规划职业生涯。</p>
<p>   3. 为成长中的设计人员提供相互交流和学习的机会。</p>
<p>此计划假设某些人已经具备了杰出设计者的必要才能； 要做的只是如何恰当地诱导他们。 Alan Perlis 说得更简明扼要：“每个人都能被教会雕刻：对米开朗其罗而言，反倒是告诉他哪些事不要做。同样的道理也适用于优秀的程序员。”</p>
<p>所以尽管买那本Java的书吧。你可能会从中学到点儿东西。但作为一个程序员，你不会在几天内或24小时内，哪怕是几个月内改变你的人生，或你实际的水平。</p>
<p>参考文献<br />Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine<br />
, 1985.<br />Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.<br />Hayes, John R., Complete<br />
 Problem Solver Lawrence Erlbaum, 1989.<br />Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988. 2001年夏天典型的1GHz PC的各种操作要花的时间</p>
<p>答案 <br />各种操作的计时，2001年夏天在一台典型的1GHz PC上完成： <br />　　　　执行单条指令　　　　　　　　　　　　1 纳秒 = (1/1,000,000,000) 秒 <br />　　　　从L1缓存中取一个word　　　　　　　　2 纳秒 <br />　　　　从主内存中取一个word　　　　　　　　10 纳秒 <br />　　　　从连续的磁盘位置中取一个word　　　　200 纳秒 <br />　　　　从新的磁盘位置中取一个word（寻址）　8,000,000纳秒 = 8毫秒 </p>
<p>不少人问我，他们首先该学哪种编程语言。没有绝对的答案，不过请考虑以下几点： </p>
<p>    * 用你的朋友的。当被问起“我该用哪种操作系统，Windows，Unix，还是Mac？”，我总是回答：“你朋友用什么，你就用什么。” 你从朋友那能学到知识，这种优势可以抵销不同操作系统或语言之间本质的差异。也考虑你将来的朋友：程序员社区 — 你将成为它的一部分如果你继续往前走的话。你选择的语言是否有一个成长中的社区，还是人数不多、即将消亡？ 有没有书籍、网站、在线论坛回答你的问题？你喜欢论坛里的那些人吗？</p>
<p>    * Keep it simple, stupid. 象C++和Java这样的语言是为经验丰富的程序员组成的团队进行专业开发而设计的，他们专注于代码运行时的效率。因此，这些语言有些部分非常复杂。 而你关注的是如何编程，不需要那些复杂性。你需要的是这样的语言： 对单个的编程新手来说，它易学易记。</p>
<p>    * 练习。你偏爱哪种学弹钢琴的方式：通常的交互式的方式，你一按下琴键就能听到音符；还是“批量”模式，你只有弹完整首曲子才能听到音符？显然，用交互模式学习弹钢琴更容易些，编程也一样。坚持用交互模式学习并使用一种语言。</p>
<p>有了上面的准则，我推荐的第一个编程语言是Python或Scheme。因人而异，还有其它好的选择。如果你的年纪是10岁以下，你可能更喜欢Alice。关键是你要选择并开始实践。<br />附录：书籍和其它资源</p>
<p>不少人问我，他们该从什么书籍或网页开始学起。我重申“仅从书本里学习是不够的。” 但我还是推荐： </p>
<p>    * Scheme: Structure and Interpretation of Computer Programs (Abelson &amp; Sussman)可能是最好的计算机科学的入门书，而且它的确把讲授编程作为理解计算机科学的一种方法。但它具有挑战性，会让许多通过其它方式可能成功的人望而却步。</p>
<p>    * Scheme: How to Design Programs (Felleisen et al.)是关于如何用一种优美的、函数化的方式设计程序的最好的书之一。</p>
<p>    * Python: Python Programming: An Intro to CS (Zelle)是优秀的Python入门指导。</p>
<p>    * Python: Python.org上有许多在线指导。</p>
<p>    * Oz: Concepts, Techniques, and Models of Computer Programming (Van Roy &amp; Haridi) 被视为Abelson &amp; Sussman的当代继承者。它是对编程的高层次概念的巡视。涉及的范围比Abelson &amp; Sussman更广，同时可能更容易学习和跟进。 它用了叫做Oz的语言，不太知名，却可以作为学习其它语言的基础。 </p>
<p>脚注<br />This page also available in Japanese translation thanks to Yasushi Murakawa, in Spanish translation thanks to Carlos Rueda and in German translation thanks to Stefan Ram.<br />T. Capey points out that the Complete Problem Solver page on Amazon now has the &#8220;Teach Yourself Bengali in 21 days&#8221; and &#8220;Teach Yourself Grammar and Style&#8221; books under the &#8220;Customers who shopped for this item also shopped for these items&#8221; section. I guess that a large portion of the people who look at that book are coming from this page.  </p>
<hr />
<p><small>© Daniel Wang for <a href="http://www.tairan.net">Tairan&#039;s Story</a>, 2008. |
<a href="http://www.tairan.net/index.php/2008/08/12/decade-of-programming-institute/">Permalink</a> |
<a href="http://www.tairan.net/index.php/2008/08/12/decade-of-programming-institute/#comments">No comment</a> |
Add to
<a href="http://del.icio.us/post?url=http://www.tairan.net/index.php/2008/08/12/decade-of-programming-institute/&title=Decade of Programming Institute">del.icio.us</a>
<br/>
Post tags: <a href="http://www.tairan.net/index.php/tag/learning-program-in-ten-years/" rel="tag">十年学会编程</a><br/>
</small></p>
<p><small>Feed enhanced by <a href='http://planetozh.com/blog/my-projects/wordpress-plugin-better-feed-rss/'>Better Feed</a> from  <a href='http://planetozh.com/blog/'>Ozh</a></small></p>
]]></content:encoded>
			<wfw:commentRss>http://www.tairan.net/index.php/2008/08/12/decade-of-programming-institute/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

