主题：【原创】编程随想 -- 代码ABC
编程是什么？
编程实际上是一种翻译工作。一种把用户需求翻译成机器代码的工作。
当然翻译本身是一种再创作过程，所以编程也是一种创作性的工作。
翻译要求“信、达、雅”，编程也有相应的要求。
“信”要求程序结果准确无误地满足需求，“达”要求设计在满足需求的条件下结构清晰、操作简便、容易上手，“雅”则是要求程序内涵，一个方便管理，再次开发的程序可以算是“雅”了。
正如一部好的翻译著作不常见一样，一个好的程序也不是很多。大部分情况下“信”就已经是一个难以逾越的鸿沟——“需求不清”是我们的开发过程经常听到的一句话（也许是最多的一句了）。
一点都不奇怪，翻译的时侯我们总有一件现成的目标——需求。我们可以担保这个目标不会改变，所谓的需求分析在语言翻译的时侯关键在于我们对原文的把握。然而软件的需求则不是这样，用户不一定了解自己的需求，或者了解但是不会表达。雪上加霜的是软件的需求总是从普通的语言表达开始的，我们使用的语言有大量的冗余。而计算机的语言则不存在任何冗余。一句不完整的话，我们可以通过上下文，甚至说话人的语气、神态了解其内涵。而一句语法有问题的代码则连编译都不能通过。所以需求的偏差将被代码放大！
为了解决这个问题，我们的前辈在无数次教训中总结了一系列的方法，这方面有大量的书籍文献。大致上是两个方面的内容：一套标准的描述语言或工具和一套管理方法。前者将大大减少了普通语言的歧义，比如我们使用时序图描述各对象的作用关系，用流程图描述一个过程的动作等等，这些就是所谓的分析方法。通过需求分析人员人工地将用户需求描述中的冗余通过分析方法和特殊的表达方式缩减，形成一种不懂计算机的用户和只懂计算机的设计人员都能明白的，歧义较少的语言。这种方式减少了语言歧义带来的问题，而由于不确定的需求造成的问题则由一套管理的方法来解决。希望通过管理的方法来控制过程中的不确定因素。人类用这种方法解决了几乎所有的问题（比如，战争这种极多不确定干扰的过程），。期望这种方法也能同样奏效。这就是软件工程范畴的内容了。
对于编码工作的程序员，我们可以不太关心这些。有需求就行了，哪怕再清晰最后还是要代码实现。当然更多的时候是：需求再不清晰，我们也要用代码实现，呵呵。
本帖一共被 2 帖 引用 (帖内工具实现)
关于“信”，没什么争议。一段好的代码首先得是正确的代码，也就是老兄所说“准确无误地满足需求”。
对“达”和“雅”的类比，我认为可以再商榷一下（其实我这里更象在吹毛求疵了）：
如果“达”在翻译里指的是追求行文通畅、流利，百分百地传递原文的含义，对于编程来说，应该是在性能上精益求精。
那么“雅”呢，是指要选择优美传神的表达方式，对于编程来说，可以看作是增加代码的可读性（或者说可维护性），倒更接近老兄所说的“结构清晰，容易上手”。
其实从一般经验来说，看上去“赏心悦目”的代码往往也是潜在错误比较少、运行比较快捷的代码。所以在软件开发界也有类似的总结。一段代码的好坏，可以用下面的这个“标准”，并且按照这个次序来衡量：
一、正确与否（functional test）；
二、性能如何（performance test）；
三、好不好读（design patterns, idioms, coding styles, etc.）。
但是象老兄这样以“信、达、雅”来类比，倒还未曾见到。
用信达雅来描述编程，怎么从来就没有想到过呢？请继续展开，非常有兴趣听。
正确性一直是困扰程序员的大难题．“达、雅”就更不好说了。
我现在的观点：“达“应该是在信的基础上做到表达通顺、易懂。即代码的可读性。我承认有不少看起来风格很好的代码可能存在不少错误。但是，一方面，我指的是在“信”的基础上的“达”。二、通常愿意花时间考虑表达的程序员写出正确代码的可能性比较高，即使有错也容易发现（甚至不需要借助调试工具）。
而“雅”我想说的是艺术性，如果你同意好的程序也是一种艺术的话。不过原文我没表达出这个意思。这是我几年前写的了，那时候恐怕还没体会，或者有体会但是说不出来。正如写作，同一个意思可以用很多方法表达一样，有些文字看起来会赏心悦目，回味无穷。代码也是一样的。
其他的，如性能、效率、可读性等等，都是建立在正确的基础上的。
其实，这个“信达雅”，也是强调以“信”为首，其次为“达”，最后再提高到“雅”，而“达”和“雅”都必须是以“信”为前提的。
看来，老兄比较强调的是代码的可读性和可维护性。站在这个角度，你在主帖原文里把程序的“结构清晰，容易上手”归结为“达”，倒也贴切。
我非常同意“好的程序也是一种艺术”。
所有的人工作品，发挥到极致，肯定会在elegance上表现出高下之分，人写出来的软件代码自然也不例外。我的理解，具有艺术性的程序应该看起来：逻辑完整、流畅，各个部分配合紧密、恰到好处，甚至还有点惜墨如金的意思。
这些年来，软件行业也算见识过了什么是“好代码”，什么是“坏代码”，对各种编程风格也都尝试了不少，总结出了象design patterns, idiom, coding styles等等不少的best practices，甚至还有anti-patterns。在我看来，这些其实是对程序代码艺术性的评价标准。
看高手的代码片段，看那些对design patterns和idioms的介绍文章，常常会有那种先百思不得其解，然后峰回路转、豁然开朗的感觉，真的不亚于欣读小说或者看电影。好多patterns, idioms构思之巧妙、建造之精密，绝对称得上是艺术品。
送花
惊喜：所有在本帖先送花者得【通宝】一枚
恭喜：你意外获得【西西河通宝】一枚
谢谢：作者意外获得【西西河通宝】一枚
鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望】
[返回] [关闭]
所谓的“需求”是人们为了用程序模拟现实世界，抽象出来的人类可以理解的东西，它是通过对现实世界的“歪曲”得到的，并不是现实中固有的东西。就像一千个人眼中有一千个哈姆雷特一样，不同知识背景、认识水平的人会总结出不同的“需求”，它们都只有局部的正确性。要想知道现实世界的“需求”是怎么样，要去问上帝--上帝才是构建现实世界的程序员。
对一件具体事情来说，就算一千个人有一千种需求，软件也起码可以做到满足其中一个人，两个人，或者三个人的需求。要搞清楚这区区三个人的需求，还是比较容易的。
另外一种办法，问问一百或两百人，把他们的需求写下来，找出共同点。这里面会出现偏差，但至少有信心说可以满足五十、六十、甚至七十人的部分需求吧。
没有哪种人类造出来的工具可以做到满足所有人的所有需求。事实上，所有的工具，包括软件，都是针对部分人的部分需求的。不同的人有不同的需求，用不同的工具好了。
现在大家觉得软件距离人们的现实需求有较大的偏差，一方面是软件工程仍然有不足之处，另一方面，也和大家对软件的期望过高有关。其他行业里，没有人会指望十元钱买把榔头还能当锯子用。
对软件的过高期望，部分来自于部分用户对计算机和软件的神秘感，更多的是由于软件业的自吹自擂。
问题在于，艺术跟技术是可以转换的。
举例来说，我最佩服的软件史上的发明就是关系数据库的理论，在此之前，数据的存取，五花八门，各施各法，绝对算得上是艺术。关系数据库的绝妙之处，就在于把这种艺术，变成了技术，通过简单的训练，Three Normalization，SQL etc. 个个都会用。
当然了，能否用得好，能否准确捕捉用户的需求，还是一门艺术，不知道有没有人正在想办法把这种艺术变成技术。
以前河里有位风北客，他的见解也很有意思的，可惜近来看不到他了。
而关系数据库理论和SQL本身，更象是从各种手艺里升华出来的艺术。
当然，手艺也分高下。
关系数据库的理论的创建过程，当然是一门艺术。
这种理论是为数据存取服务的，我的原意是关系数据库的理论帮助我们把数据存取这门艺术/手艺，变成了一种技术。
艺术/手艺跟技术有什么区别呢？关键在于前者的做法是五花八门，后者是统一的。
当然目前来看，也还不是百分百统一，还是受限于许多因素，例如用户需求。
我强调的是SQL之前的数据存取手段相比关系数据库理论和SQL的差距。关系理论和SQL的产生过程象一个艺术创作过程，从原来那些不太完美，只能称得上是“手艺”的各种数据存取方法里，抽象、升华出来得到如艺术品一般的关系理论和SQL。
而你强调的是关系理论和SQL这一如艺术品一般精致的工具普及后，使得数据存取从五花八门的“手艺”成为了一门标准化的工程技术。
而且在大部分项目里面都必须考虑到的需求。人的想象力是有限的，没有任何一个客户可以在一开始就告诉你他要的每个细节。而随着项目的进展，越来越多的细节呈现在客户面前，他的要求就会变化了，或者是更加细化了。但是，矛盾的是，随着项目的进展，项目本身会越来越难改变。这个时候，项目的成员的管理能力和设计能力就体现出来了。好的项目管理人员可以和客户沟通积极寻求双方都可以接收的折中方案，好的设计人员可以保持项目的灵活性直至最后的交付以应付各种预期到的和没预期到的变化。
所以一个好的项目组和一个坏的项目组的区别在于他们应付变化的能力到底有多强。
前几年要搞一个大型的文字信息库，讨论组里当然少不了文字学家和计算机专家，开了几次会以后，基本上双方脑袋都大了三圈——互相听不懂！！
对华内容简介如下：
你们需求不够清晰
我们已经说了10遍了…………
不过这两年情况好多了，因为两边粗通的人越来越多了。