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