我的程序观
　

---

请先看下面的图示:

机器代码 --〉高级语言实现 --〉结构图 -〉自然语言

我们很早就认识到,高级语言是机器语言的抽象,结构图是对高级语言的抽象,
而自然语言是对结构图的抽象.这是很好理解的,也符合我们的思维习惯.可是
倒过来看,逆向思维一下,会有更惊人的发现.它们不正是我们"做"一个软件标
准的流程吗?

可以说,它们表达的都是同一个东西,只是抽象的层次不同而已.抽象层次越高,
所需要处理的基本抽象思考要素也就越多(它们通常被包含在丰富的语义中).
但是,涉及到的具体实现细节反而越少.一句话,我们的软件活动大都是从高度
抽象到底层抽象,这个演化过程是客观规律,随着软件工程水平的提高,从此岸
到彼岸的直接跨越就变得非常不合理(以前确实存在过,不过想想当时的软工
水平吧).

有了从高到低的抽象层次,就需要逐步地象下楼梯一样一层层往下.然而下的
过程是危险的,也是值得研究的.什么是这个过程中最重要的,我觉得是保持一
致性,起码是概念的一致性.为什么呢?举个简单的例子:

客户说我要一个信息系统,这是一个听起来很简单的自然语言表达,可是因为
过于抽象而让开发者无从下手.于是开发者要和客户进行不断地沟通,是客户
的概念能毫无遗漏地传达给开发者(如果客户很幸运有明确的概念的话).遗
憾的是,这个过程是没有保障的.当客户的概念大部分(或全部)都已传达给开
发者时,他开始设计,目的只有一个,实现那个概念.设计的输出将作为编码的
输入,我们仍然无法保障这个过程的一致性.可以看到,到此为止,系统中没有
保障的因素已经很多,如果中间存在任何稍大的不一致,就必须重复进行大量
的工作,就好像已从20楼走到2楼,突然发现忘了穿鞋,还得回到20楼一样令人
同情.假设我们已经顺利地到了2楼(值得庆祝),剩下的工作将容易许多,高级
语言到机器代码的一致性目前已经得到很好的保障,这个成就让软件业的生产
率提高了很多.可是这对我们现今的软件开发并没有实质性的帮助,因为:

在当前整个软件开发周期中,这个过程只占了少量的精力和时间(我认为接近
于零),没有一个高级语言程序员会关注自己代码的反汇编结果.类似的还有
开发工具等相当次要的因素.所以,问题仍然很严重.

危机不可避免地存在着,关注它们不代表我是悲观主义者.和所有不能由人类
完全控制却可以供人类充分研究并利用的自然科学一样,软件工程学必然有
客观的规律.矛盾总是存在的,因为那些一致性不可能100%的满足(人与人的
交流不可能是无缝的,除非被Clone),但我们可以不断校正,运用合理的方法
学使之接近理想状态,即不断地进步.在这方面,中国人又一次落后了,大学里
教条似的软件工程学,企业界对于新技术的偏执和对设计,管理的忽视,怎么
可能从根本上提高我们极低的软件水平.而从事理论研究,以科学的态度对待
软件业的研究人员,又在哪里呢?

Clone就能保证一致性吗？

 回复: 我的程序观
　

---

机器码和高级语言（结构图也是一种语言）都是形式语言 它们都有明确的规则 表达的含义都确定无二 我们的自然语言不是形式化的语言 充满了不确定性 实际上我们开发软件的过程 就是把自然语言这种非形式化语言翻译为形式化语言的过程 很多时候设计是对自然语言的抽象 而有的时候又刚好相反 设计和编码的关系依然如此 他们所表达的东西不相同——概念和概念的一个实现是不同的 对同样一个事务我们可能会有多种抽象 所产生的程序也有多种可能 但是有一件事情是肯定的 需求必须是不抽象的 也就是需求必须是具体的——虽然不可能开始就是那么具体 但我们必须有办法让它实现具体 由于是抽象行为 所以它们不可能是一致的 不然还怎么叫抽象
人类可以抽象 但是这个能力还不是很强 多数情况下我们的要求首先都是具体的 由于语言和环境等问题 使我们具体的要求不能很好的得到表述 所以客户说我需要一个信息系统 这一定不是一个什么抽象的概念 它一定代表着客户现实的一些想法 而我们的工作就是把他们的各种想法汇总发现分析 把各种需求做到统一 从而抽象出一个比较适合他们的结构 但是客户的需求不可能一下子全部或者大部分传达给我们 这就要有一个过程 在这个过程中客户的需求依然会产生变化 于是这就是产生增量开发的原因
而机器语言是那么复杂（没有银弹有充分的分析) 我们很难保证我们所作的设计 在没有转换为机器码之前就能得到验证 于是设计的重要性在某种程度上很难在没有实现前体现 软件开发的过程如果说我们有些把握的 只能是从编码 而即使是这个我们做得依然不是很好
软件工程是工程师的领域 从事软件工程研究的学院派在国内和国外都没有什么市场 他们只能抱着一些似是而非的理论乱叫 可惜声音总是那么小 从来都不是软件工程的主流 可以说软件工程——悲观者的疆土

 回复: 我的程序观
　

---

大师一言，令小弟惭愧不已，本人便是学软件工程的出生，感觉难做的不是技术，而是人与人之间的交流，客户的要求有时很有点过分，可是为了讨好他们不得不做出一点让步，或许还有保住自己饭碗的味道，经常我们发现由于需求做的不够到位时，后期客户推翻了一些东东，可我们却花了大量精力，难，难。

 回复: 我的程序观
　

---

同意 ozzzzzz 的！

 回复: 我的程序观
　

---

我的意见——给客户他们需要的，而不是给他们想要的！！！！！！

 回复: 我的程序观
　

---

COOLXIAOYI，你的讨论真是独到一面，我非常佩服，同时，也给你一点意见。

依我所见，人类的一切所为，都是带着非常强烈的目的性，要达到目的，我们人类将不择手段。

“为达目的，不择手段！”，这是一句绝妙的老话！大家不防试想一下，无论你是利用自然语言也好，利用高级语言也好，利用机器代码也好，都表白一个目的：你利用这个东西是为了实现客户的需求！技术本身是为了更好地实现目的而研究出来的。当人们所使用的技术出现不同时，为了可以相互融合，就需要有一个东西出来调解，这时便出现了各种中间技术，这些中间技术并不是用来直接服务于目的，而是为了缝合两个原本用来实现目的的技术而做的。因此，这就使得“技术”或是“工具”这个东西变得多样化、难以捉摸！

大家有没想过，为什么人总是从不断的成长过程中学习呢？总是要到老了才知道当初为什么不这样做而走了很多的弯路呢？这是因为你当初正处在学习技术或工具的过程中，你并不知道你在学习的这个东西的背后目的是什么，而到你老了，你已经学会了那个技术，你明确了这个技术的背后目的，你就会说：“早知今天，何必当初呢？！”

学而不思则惘，思而不学则怠。
oz在所学范围内进行了较深思考，已经没什麽发展了，需要继续学习了。
学懂了哪些“似是而非”的理论后，再好好想想看。

 回复: ozzzzzz是工作了，但水平欠提高
　

---

哈哈 我在不断学习 不过您觉得我首先应该学习一些什么东西呢 有些什么理论是我该学习的呢 我早就认为我提高的很慢 所以希望您对我有帮助 至少我们可以讨论 很高兴你关注我的言论

我不是说你的观点有问题，实事上，我很同意，只是我不知你的“学院派”理论指的是什麽？（我往往很崇拜他们）
在我看来一些理论之所以还不能运用，很可能是他太超前了。
一个优秀工程师可以每次将一个项目做成功，但一个科学家不会满足于此。
试想，为什麽在从二义性的非形式化描述向正确性可证明的形式化描述的过程中，非要通过“软件工程师”这个中介（同时也是错误产生的主要来源）？
现在很多的研究工作都是在不同角度去分解、削弱这一中介的功能。
我们不去讨论能不能最终消除这一中介（这是个具有广泛争议的问题），但是在这一方向上的任何努力都是严肃的、令人赞叹的。
具体说，你可能有能力利用“计算机知识”帮助用户建立“成功系统”了，但不应该满足于此，你是否还有能力利用“领域知识”来帮助其他工程师建立于你一样的“成功的知识结构”呢？
有很多要学不是吗？

功夫在诗外，不如去学一学哲学，任何问题归到底都是哲学问题。

 回复: 建议你学习一下《C++编程思想》，rose的使用和UML语言，ASP.net,J2EE&html
　

---

我没有读过你说的这些东西，真的很遗憾。不过为什么要学rose？我没有很多钱去用它，而且我习惯有铅笔和白纸，这样作也有些时间了。至于uml我觉得做为我来说不用学习，我已经有些认识。真正要想学习的人都是不懂OO思想的人，但是由于他们根本就没有OO的思维习惯，所以总是觉得UML学习很困难。你说的asp.NET和J2EE对我来说是技术的细节问题，我现在已经很久没有在第一线工作了，我现在所掌握的他们的一些知识已经够我工作的了。你说的这些东西根本就不是什么理论，只是一些技术上的东西。我说的理论是指那些学院里的人研究出来的东西，比如B、Z之类的东西。当然我觉得B、Z还是有用的，但是有些东西我实在是觉得没有研究的必要。现在我们需要的是软件工程学家，而不是软件工程学学家。你说的软件工程师是工程师，而不是什么理论的研究者。我现在就在做ALIGE思想的推广工作，我就是象你说的那样想把自己10多年来工作的经验传授给别的同行，让他们分享我的经验教训。我一直没有放弃过学习，但是你指出的这些东西我确实没有什么兴趣，关键是对我帮助不大。而且我强烈的建议你使用有受权的软件，比如ROSE。我们都是做软件的，尊重别人的劳动，才可能被别人尊重自己的劳动。

 然后所有人都进化成了哲学家
　

---

基础研究的科学家，设计的工程师，具体完成的熟练技工都是必需的。这三种是独立平行的关系。会有人全能不意味着所有人都必须以科学家为发展目标。
具体到项目上，是应用。工程师和技工可能不懂微积分原理，只会拉计算尺。但能完成工程项目，对他们来说，某个言必称牛顿，对微积分历史原理等了如指掌，就是不懂得如何应用到项目上的所谓科学家是不需要的。而另一个对微积分只懂个皮毛，却能够用于提高工程质量的科学家则是极受欢迎的。这样的科学家可能需要工程师背景，但不意味工程师必须成长为科学家。
至于说超前，几千年前我们就有“过犹不及”的说法，放到今天也不会有错，请问千年来有没有可能为这么光辉的理论提出一个可以具体执行的数值标准？
至于软件工程，从数理逻辑，从哲学有没有达到这样的高度也是大家都明白的。有人要研究软件工程，欢迎。但在没有证明可靠有效之前我不想当小白鼠总可以吧。虽然我不会晋升到科学家的层次，但至少也不会鹦鹉学舌，人云亦云。我就呆在金字塔的下面当基石就够了，我不认为倒三角形是理想的金字塔形状。也算我不求上进吧。

 回复: 然后所有人都进化成了哲学家
　

---

任何研究活动都是要建立在数据的基础上，也就是研究也必须建立在先有工人，然后是工程师，然后才能有科学家。现在地情况是我们缺少研究的素材，也就是我们现在还缺乏大量的实践做研究的基础。现在还不是三剑齐发的时候。

我一直就说你说的对。只是对你们瞧不起“学院派”有些异议，可水平不高，又说不出什麽有力论点，所以一出口，必定漏洞百出。
但是，你怎知我用盗版rose?
我的标题是开玩笑的，意思是“你不用再学这些了”
开发UML的那群人中，肯定有精通Z之类的。
ALIGE我不懂，是不是“敏捷编程”？
我认为现在的方法学太多太乱。
　

整个行业，也许需要100个技工10个工程师1个科学家的比例。
对我个人，就是简单的该干什么干什么。工程师要去钻研科学，至少要到完成本职工作以后。现在倒好，一批觉得当工人太苦的人去搞科学也没有问题，却偏偏要吵着回来指导实践工作。
现在我们的软件工业就是和工业一样，有100个教授，10个合格的工程师，10000个民工，1个高级技工。有再多的理论科学家论证我们的软件工业如何有前途，我是不会相信的。当工人太苦，打打禅机就容易多了。
别人的软件工程建立在数据上，我们建立在名人名言上。

哈哈！你们暂且认为我是笔误吧。ALIGE是我写错了，应该是AGILE!（因为那是我才给自己的方法起的名字，或许ALIGE不是很合适，以后会改）
我们瞧不起学院派，是的！这是一种传染病，从美国传入，在日本也有落脚，中国也是高发区。没有办法，我们都是一些俗人，俗人就是喜欢追风。也许那一天风向变了也不一定。不过我觉得，现在还不到变得时候，研究还没有基础。这些人势力太大，搞得CMM在美国都很少有人知道，ISO被我们搞垮了。好在我们国内人还淳朴，学院派的东西还有市场。
我看了UML的社区人员，似乎都是我们这些工程学派的人，而且没有什么研究需求的，也没有见过他们做过Z的研究，当然也许私下研究也说不定。
如果你是在用正版最好，我为此表示抱歉。

 回复: 不是三剑齐发
　

---

更严重的问题是现在100个技工都没有，工程师更是少见，那些科学家研究些什么呢？所以你说不建立在名人名言上，又建立在哪里？

 回复: 我的程序观
　

---

To ozzzzzz:
你的发言我看过好几天了,对于你的观点,似乎是认同大与反对.
从技术角度,我所给出的模型确实很单薄,所以我表达的意思还
需要补充.我认为在软件开发过程中,"自然语言","结构","程序"
等都应该共享同样的概念,我承认这样的概念"应该"是具体的,
但是这并不妨碍我用抽象层次不同的方式来表达,也不会妨碍
各种表达方式用各种特殊的语义来保存这个概念.
关于人在整个软件工程中扮演的角色,我无力作出任何有效的
判断.所以在我的观点中也并未诉及.一方面是因为我的经验不
足,另一方面是有所忽略.我关注的,之是那种阶梯壮逐层抽象的
过程,并很希望能让它们无封地连接.从高级语言到机器代码,我
感觉已经完成了很好的连接,那其它的几级阶梯呢?从您的视角看,
它们有别于高级语言和机器代码作为一种实现扮演的角色,而是
一种概念.诚然,那么对于概念,我们能用什么手段来规范它的一
致性呢?是UML吗,是以次为目的的各种方法论吗?如果我的观点
在您看来是根本性的错误,您可以回避上述问题.
"学院派"这个词我始终不知其真正含义,但是若国内真有一个真
正的学院派,倒乐于师从其下.软件工程学说到底还是工程学,最
基本的理论,最客观的规律都是具备的.从理论到应用,需要很多
感大胆实践的工程师,我希望自己正是这样的人.

 回复: 我的猜测：coolxiaoyi-在校生，ozzzzzz-工作了。
　

---

您的猜测很准,我现在大三.可以告诉我您的秘诀吗:)
但是我也有一年的软件公司兼职经验(JAVA),是不是
Too Simple,Too Naive.

 回复: 我的程序观
　

---

你认为软件工程学是工程学吗？工程学最基本的是实践，大量的实践。规律是到处存在的，问题是规律需要大量的事实做基础，任何理论都应该来自于实践。我们现在实践还太少，不可能有那么多素材。软件工程学涉及的学科过于广泛，还有象组织学、管理学、心理学这些非科学的学科，由于他们现在也在发展，很难给我们提供可以使用的定量的数据。而软件本身的度量问题也还远远没有结果，所以只这一点真正的学院派是不可能存在的。
实际上我认为软件开发过程中各个过程都不是一个单纯抽象的过程，都是由具体到具体的过程，而抽象的过程是我们对于这个过程本身进行的，也就是我们对我们采取步骤地抽象－－于是产生了方法。UML只是承载思想的语言。虽然它可以很好的承载OO的思想，并且也反映了OO的内涵，但是它还是一种语言。我们更需要的是语言所要表达的思想。而产生这些思想的方法，我们已经有了一些，但是这些都是经验的总结，而还不是研究的结果。我所用的概念这个词，是只我们在对需求抽象（注意这个不是哲学意义上的抽象）过程中的发现的那些东西，也不是哲学意义上的，你暂且可以用类这个词来代替。

另外，这个程序自动生成的理想别人至少已经奋斗了二三十年了。那些都是真正的精英，可惜，理想还是只是理想。
你看到了从不完备的用户的需求到一个完整的代码实现是阶梯状逐层抽象，不错。你希望找出一种方法能够以一套给定的规则自动完成这一过程，要规范它们的一致性，愿为此奋斗，也很好。问题是，有再多的代表来武装，永动机还是早不出来，虽然这个构思也绝对优秀。
我不懂数学，从一个开放集是否一定能映射到一个封闭集范围内的数理论证是不行的，就给你提供一些小农经验吧。
第一，你看到一个过程是阶梯状逐层抽象，最后一个需求得到了一个解决。问题是并不是一个需求定义就只有一个解决方案，在每次转换，在每次转换中的细化时，都有很多种选择，你看到了其中一条路径，但是你事实上放弃了很多别的通路，还有很多你根本就没有看到。
第二，这个选择是基于很多因素的，有人员能力，有迫不得已，也有目标不同。其实是很主观的，很难用一套固定的规则固定。比如说同样一套企业内部管理系统，在企业内开发时，目标是完全符合企业的实际。在打野食的集成商那里，尽快完成最小定义的功能集是第一位的。在针对行业的专业集成商而言，项目间的通用性是第一位的。对于用来培训员工的公司，接触范围的广度和深度是最关键的。有了目标，然后还牵涉到有否合格人员完成，不得已退而求其次，采用适合开发人员能力的非最优设计也是常见的。你无法用规则模拟人的主观决定。人的能力也不是用什么8.9之类的打分就能了解的。
第三，对人在整个软件工程中扮演的角色，你忽略了。这点很对，人总是会犯错误的，理想的系统就是能不依赖会犯错误的人，会自动根据反馈平衡。可惜，第二点已经说了，至少在相当时间内，软件的质量其实完全依赖于会犯错误的人。人的能力可能还能要求，能培养。但公司的商业目标就完全脱出了软件工程能控制的范围，可是它对最后结果影响最大。
最后，让小农我提醒你一件事，你的“最基本的理论,最客观的规律都是具备”并不能说明什么，商业世界的基本理论和规律更为简单，就是低进高出，获取利润。军事上就是知己知彼，创造自己的优势环境。可惜就算如此简单的理论，也没有人能建立成功的必然之道。
混沌，打破了拉普拉斯决定论，在软件开发的世界，比蝴蝶扇动翅膀严重得多的事也多如牛毛。

这个问题并不等同于“智能机器”
实际上，我理想的软件工程近期目标还是个人机结合系统。只不过是要解决当前阶段软件工程的焦点问题。当前最大的问题是需求获取中由于信息传递而产生的信息曲解。这是由于当前的语言层次太低导致专业性太强（所以我们才有饭碗），而其实软件工程师并不是必要的，他并不比各行业专家“聪明”，只是他们具备把领域知识和计算机系统结合的专业知识而已。而这种专业知识完全可以被包装起来。
就目前研究水平来说（可能还只是在研究室里），通过受限自然语言文本，自动生成个别领域的系统是完全可行的。
这里的逻辑是：领域专家+计算机系统的智能并不小于领域专家+计算机专家+计算机系统的智能。
我对“智能机器”的看法并不乐观，我不知道有生之年可不可以见到，但对我们现在意义上的软件工程师的失业是可预知的。
所以，我说研究'agile‘什麽的是好的，开卷有益嘛，但是研究之前最好先搞清楚是研究“人际关系学”、“管理学”还是“计算机科学”或是几种科学的交叉运用的实践经验。总之目的明确就好。
研究归研究，至于学习使用嘛，我看大可不必了，您学会了打算用几年？

　

我想任何类似结构的问题，是不是都可以看作为金字塔形。倒金字塔的情形不多见，我一时想不起来。如社会的人员结构，公司的薪资结构和软件产业人力资源结构都是一个正的金字塔，只是比例不调。而且这个金字塔是动态的，底层的不断向上涌，另外还有从外部进入底层。

 回复: 每那麽复杂
　

---

shshsh_0510
“当前最大的问题是需求获取中由于信息传递而产生的信息曲解。”是这样的吗？其实问题已经有解决的办法。增量开发结合快速原型已经大大提高了我们的能力。但是这个问题其实隐藏着更深的一些东西让我们思考，为什么会在别的行业中也存在这些误解，而在那里不会产生我们这里的困难情况呢？根本的原因在于别的行业有大量的试验方法作基础，可以很快的对所传递的信息作验证，从而是信息在验证过程中得到真正的领会。而我们以前一直在做什么呢？我们做的无非是增加更多的评审，更多的流程，更多的签字。这样子似乎是在学习传统行业，但是我们只学习了形式而没有学会思想。我们学习建筑行业的操作方法，于是我们说应该重视设计。然后我们就对设计反复推敲，反复修改，可惜就是不首先做一个实际的试验。我们显目建筑行业的设计图纸的详细，于是我们就来搞了一个详细设计，还要求详细到coder看了就可以直接编码的地步，但是他们就忘记了建筑行业的设计再详细，也没有详细到要为每一块砖去做设计。还有所谓的流水线生产，也常常挂在一些人的嘴边，可是他们忘记了流水线的生产主体是设备，而不是人。实际上把流水线的思想映射到软件开发过程中，勉强可以认为程序员是设备，那些管理人员是生产工人，也就是随着技术的进步那些管理者应该被淘汰，而且他现在在软件工程的地位也是陪衬性的，他们是可有可无的。凡此种种，都是我们人类傲慢和愚蠢结合的产物（例如日本的软件工厂，第五代计算机等等）。
专家系统、智能机等都是人工智能领域研究的热点问题，我对此了解不多。但是凭着我有限的知识至少知道，现在使用实验室技术本身就很不能说成功，来实现商业化应用相差更远，近期还不能预言软件工程师失业。要让计算机领会领域专家的意图，首先要把领域内部的东西做一个规范，也就是领域内部要有一个形式化表述的过程。但是任何形式化的要求都要建立在广泛被接受的基础上的，而且还要考虑的成本的问题。也就是要考虑到领域专家掌握形式表述的成本，还要考虑到把他们的形式语言转换到计算机语言的成本。这是就是软件过程学是工程而不是学术的一个重要标志。工程学不是光考虑是不是能做，还要考虑是不是值得做。所以不是功能最强的就是最合乎软件工程要求的。
你知道敏捷方法的一些什么内容呢？那些东西不是拿来研究的，是那里使用的。可以说敏捷系统是最近几年来，软件工程领域最热点的话题，贡献有目共睹，在国外已经得到广泛的使用。你至少应该拿出点时间，去关注一下。但是你仅仅是为了，研究那就大可不必了。
killcamel
我认为你说的多种解决方案，可以这样更好的表达：从分析模型出发，可以用一种以上的方法，每种方法又可以产生一种以上的软件结构模型。俗话说条条大路通罗马，况且还有小路，还有自己开路。

 C，JAVA同样可以称为受限语言。就看你的受限自然语言文本的限制强弱了
　

---

千万不要告诉我过几年就到处是受限自然语言翻译员，受限自然语言设计师了。你认为学习一个受限自然语言文本比学写程序容易？和自然语言的语法比起来，现有的编程语言的规则可以说简单得不能再简单了，而且没有任何例外。
你说在研究室里，通过受限自然语言文本，自动生成个别领域的系统是完全可行的。这我相信。就看是怎么回事了，如果我限定用户只能说“1+1”，不用任何计算机系统我就能自动给出“2”的答案。我说if...then...也很自然，C++就也可以成为受限自然语言。
你说领域专家+计算机系统的智能并不小于领域专家+计算机专家+计算机系统的智能。 没错，教会一个雷达专家编程比教会一个程序员雷达知识容易得多是大家都公认的，可惜，这里隐含了一个前提，就是领域专家成为计算机专家，身兼二职了。
至于你担心学会了计算机知识能用几年，大可不必。按照你的说法，外语翻译也不过是把一个意思用另一群人的表达方式表达出来，而且人脑有很大的容错性，你不会因为一个外国人和你说的是“路，哪里”就不明白他的意思，而受限自然语言是要转化成不能有歧义的计算机语言，学习难度不会低于学习外语。你就看看现在的平均外语水平有多高吧。
至于你说的由于信息传递而产生的信息曲解，听上去很深奥，但是也不是什么新鲜事，有人群开始这个问题就出现了。有了组织机构，比如王朝，军队，公司等后，也有无数的领导人企图解决这个问题。直到现在，我好像也没有见到哪里摆脱了这个问题，就算是比较规则化的法律语言，也养活了无数律师。我不认为软件开发这个行当能重要到了迫使人们去解决人类几千年历史解决不了的问题。
你说软件工程师并不是必要的，他并不比各行业专家聪明，这我很同意，不过一个简单的工作罢了，没有什么神奇的。一般只有行外人才觉得软件神奇。问题是在这么多行业里有几个需要特殊的聪明才智？混沌一书里谈到物理学家称任何受过训练的人通过计算，推理可以得出的工作称为“显然的”，“并非显然的”用来形容那些获得炸药奖的工作。无疑我们的工作只能称为平淡的，另一方面，12亿中国人中从事不平淡工作的不会超过100万吧。
当然，在我认为给定一个需求，通过智能机器自动得到最终结果代码已经算奇迹的情况下，你连需求都要通过受限自然语言自动得到，可以说是伟大了。不过建议你看看世界语的历史，你就知道推行一个人工自然语言的难度了。这还是不受限的。另外，总有一天（当然我不认为是我有可能看到的时候），你的梦想会被实现的，也不用为后人担心。不用象砸机器的工人一样，机器夺取了工人的工作岗位，还会创造了机器使用，维护，研究等新岗位。
至于你的人机结合系统，我就不评论了，就和“知己知彼”，“过犹不及”，“阴阳平衡”等一样，道理都对，就是没有任何可操作性，最后完全看个人能力，也就只有写写哲学论文骗职称的价值。可惜挺不错的哲学到了中国也变质了。

从一大堆需求中找出理念和规律，然后实现为一个功能性产品。任何的工程过程不外乎如此，您要是有建筑工程施工的经历，您大概就会知道什么才叫工程化的制造。一个建筑公司出现300个设计施工工种，不会让人奇怪，如果软件工程项目您要提出30个工种的配置，相信有人会说你疯了。
单从工种数量这一项指标就会发现现今软件工程理论是如此的幼稚，简直就是小孩过家家的游戏规则。
软件正向多层化，多专业化方向发展，如何加快软件产业的社会分工，才是软件工程应该研究的课题。
您现在看到一家专业的建筑装修公司，您会毫不奇怪，哪天您要是看到一家“软件界面设计公司”的招牌，您也不以为奇，软件工程的水平就差不多了。
做软件做成哲学家才是正道，学成哲学家或者不做成哲学家都有遗憾。

100个项目组可以对同一个需求有100个不同的实现。

我不要时髦，只要实用。只要这三个月能用，我不去考虑所谓半年后会隆重登场的超新技术。

按照页数收钱, 完全没有风险, 又受人尊敬, 属于软件开发里的白领, 和那些战略咨询公司一样风光.

 回复: 分析模型由于不同的侧重点也会存在多个。只是我们只使用一个。
　

---

哈哈 你还没有我彻底 我只要现在够用就好了 3个月我都不考虑
你发现了我有意越过了需求都分析模型的这个部分

 回复: 我的程序观
　

---

软件工程是bottom-up的,不象其他一些工程领域是top-down,
所以我很同意关于实践的意义.

绝对完美的东西并不存在,就向世界上没有绝对真理一样,
有的只是,进步!