二匪夜谭(0分)

G匪 说：
在不在?
K匪 说：
干吗？
G匪 说：
我在想个问题，把软件开发与建筑的类比，在多大程度上，会误导思维？
做这样类比的人，基本上都没干过建筑。
K匪 说：
软件的特殊性在于客户在拿到产品之前，没有办法体验产品。所以软件开发是一锤子的买卖。
建筑，服装与软件的区别就在这里.
G匪 说：
带来的一个和其他的重大区别在于
软件的设计属于一种进化似的设计
而不可期望，在初期就有所谓的完善设计
K匪 说：
做个类比，抄花生你要知道一锅花生是熟还是生，对于软件来说没有办法知道除非你一颗一颗吃过去
而其他的一些传统产业，你吃一颗就大体知道熟还是不熟
G匪 说：
所以基于 重装 步进 似的开发流程，维护成本都过高
K匪 说：
我觉得无论是进化式的还是一步式的，结果都是一样的
G匪 说：
小版本快速发布，才可能是一种好的方式
K匪 说：
关键不再软件开发本身而是软件开发之外的事情
K匪 说：
这种可能性，很小。因为小版本的发布的工作量其实和打版本是差不多的。
G匪 说：
商务操作上也有难度
K匪 说：
小版本的核心代码，应该与大版本相同。否则相当于每个版本都是推倒重来。核心编写的都是重复的
其实软件开发的成功与否，在于客户能否在开发之前充分的体验软件。
G匪 说：
占70%
K匪 说：
什么70%
G匪 说：
在于客户能否在开发之前充分的体验软件 相对开发的成功影响
K匪 说：
基本上是的。
但是这也是最为困难的。因为体验的时间成本是很高的。
G匪 说：
经验的获取成本很高
以至于其成本高到无法用钱来购买
K匪 说：
不是这个意思。
G匪 说：
我的意思是，这部分时间代价无法通过花钱来替代。
就和女人生孩子似的
K匪 说：
hehe
K匪 说：
关键是，你给他什么样的体验？？做一个DEMO??首先体验是不充分的，第二DEMO的实验性质会
降低客户对某些需求的重视程度。反正是个DEMO，到了正式版本的时候在改好了
G匪 说：
只能两头抓
一是 需求分析，二是 结构的灵活性
K匪 说：
结构的灵活性这是舍本求末。程序员对需求变动恐惧产生了结构的灵活性。
结构的灵活性，导致的一个问题是程序员忽视需求分析
G匪 说：
需要分析 占70%
灵活性占30%
K匪 说：
把本来简单的东西作复杂了
你很难界定，70%和30%的概念。
G匪 说：
问题是，我觉得软件设计的特点是它的进化性
就是说，当在正式开始前，无论是客户还是开发方很难对问题有比较充分的认识
K匪 说：
怎么说呢，软件需求分析应该和设计编码分开。
G匪 说：
在开发方能控制的范围内所能做就是，对问题域进行有效分割
K匪 说：
这些方法不是没有人式过，但是成功的人还是很少
G匪 说：
功力不够，环境不好，没有足够试错经验
K匪 说：
我觉得，软件需求分析是一会事情，他不属于软件范畴内的事情。我们现在想方设法用软件内
的方法论去控制需求分析。无疑是自己咬自己的尾巴
G匪 说：
这我同意，想通过30%范围内的努力，就控制70%的不可控因素
显然是不能得到满意效果的
K匪 说：
软件的需求分析，应该要有自己的一套理论去阐述和解释。相对于软件设计的角度来讲，
需求分析才是科学，而软件设计属于形而上学的一部分
G匪 说：
你是指因为软件设计的优劣并没有标准，所以他不是科学，而需求分析是可以验证的所以是科学？
K匪 说：
关键是软件设计是可以脱离现实的，他和数学一样不过是一套永正的逻辑符号。他并不反映给
我们客观世界是怎么样的
OO,GP,UML.脱离现实，他仍然具有一定的意义
G匪 说：
但抽象性是思维对付现实的武器
K匪 说：
问题是，软件设计理论的方法无法去描述软件需求。考虑一下数学和物理的关系。
牛顿不是认识到f=ma才看到苹果落地的。
K匪 说：
抽象的逻辑符号可以用于对现实世界的描述。但是现实世界的特性绝对不可能
从抽象的逻辑符号种推倒出来
我们现在欠缺的不是符号，而是对于现实世界的认识。
G匪 说：
我们除了得出 需求分析 和 软件设计基本 是两个领域。还能得出什么？
K匪 说：
还有就是一个关键性的问题:改变目前的软件设计的病态表现，只有从需求本身入手，而不是软件设计。
但是具体怎么做，我现在没有答案（我想专业咨询可能是一种出路)。但是至少找准了方向。
G匪 说：
这个方案比较低调，更具有有实际可行性。
K匪 说：
打个比方，软件设计好比防守
软件需求好比进攻。
G匪 说：
最好的防守是进攻
K匪 说：
如果光防守，你永远有漏洞。
K匪 说：
防守的弱点，就是木桶原理。你的设计无论如何灵活总有一块板是缺陷的。而一旦有板缺陷，
那么其他牢固的地方的作用几乎为0
G匪 说：
睡...

去看《人月神话》
所有的软件活动包括根本任务——打造构成抽象软件实体的复杂概念结构，次要任务——
使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。
而根本任务的根本问题就在于软件的复杂性
没有人会拿来一台彩电叫你把它改装成一台高清晰度电视，但在软件领域，相类似的例子
多了去了。

tuti的对话里谈到了“抽象性”，在《人月神话》里Brooks认为软件的复杂性是一种根本
属性，撇开复杂性不谈，讨论如何将现实抽象是毫无疑义的。也就是说，他认为软件和物
理、数学的研究方法不同，在物理学上，你可以假设出一个无限光滑的平面来建立一个抽
象的模型。而在软件领域，你必须考虑软件在各种情况下的特性。
上文中 K匪 应当是一个比较有经验的老鸟了，他对软件领域中问题的归类“需求”和“设
计”竟与Brooks的分类法不谋而合（或许是他已经读过Brooks的文章了，但不管怎么样，
他能有如此见解应该说是很了不起的了——至少比国内大多数程序员牛了），“设计”方
面的问题也很重要，虽然它无法解决软件开发的根本问题，但如果在这里出了问题的话，
会对软件的成功有极大的影响（两匪关于防守和进攻的隐喻十分恰当，如果一个球队防守
差的话，他们就很难不输，但要想赢球，光防守好也是不行的，还要有进球）
那么到底有没有解决进攻问题的方法（有没有银弹）？
期待两匪关于需求的获取能有更深入的讨论

借问mor大虾一下 Brooks在哪篇文章中谈到了（“需求”和“设
计”，Brooks的分类法”），我通看了《人月神话》2遍，好象
没看到有相应的描述。
mor文中用到了“隐喻”这词，看来也是饱读该类书籍。
希望多探讨。

很好的思考[]