什么是软件开发的核心问题？

软件开发的核心问题，我想要分两个层次来谈论：

一是面向机器，也就是狭义的技术啦，这个层次的核心是离散数学

二是面向业务及结构，也就是广义的技术，如何用面向机器的技术去描述现实世界，这个层次的技术核心我就有点迷糊了

A best designer firstly is a best communicatee .
A best communicatee firstly is a best observer.

我觉得ｄｅｌｌ说的很有道理，无论作什么事情，我觉得人士关键的因素。人之间的交流和配合是最重要的，没有协作精神的团队能开发出好的产品吗？

哈哈，看了各位大哥的帖子，有一种豁然开朗的感觉，中国的软件不成熟和规范并不是做软件的人做的不好，而是有一些其它的因素在里面，你不屈服的话一个活都接不到！！！

我也来说两句，我是从另一个方面来看软件的，软件是一种哲学，是一种思想。包罗万象！
但是我还说不出一个***来。有一些思路片断，与大家参考参考
1）学习要用悟（禅宗），要学而时习之，好书包含的是思想，经常看，经常悟。因此最好是印刷板。
2）做事要学道，包括两个方面，一是思考和分析问题，则应该应用分离的观点来看问题（常与非常）。二是具体做事应考虑有效率的做法，不要书本主义（或知识主义）
。我们的老祖宗给我们留下了宝贵的思想财宝，而软件工作者基本属于近代的思想家，在我看来，国外这些大师可以说的上是诸子百家，每个人的思想都有一点闪光点。前提都是一些假定。但是这些假定在实际的环境中并不一样。因此常常。。。

再帖一次批评MDA的文章

MDA的核心论点是抽象层次提高，能够带来.......

但是软件开发的本质是什么呢？

－－－是翻译！
将有歧义的自然语言，翻译为无歧义的机器语言。
这里说的机器语言，是泛指所有能被机器理解的语言。

软件开发的最难的部分，就是消除对于软件的需求的歧义。

——————————————
再加一段
消除歧义，消除模糊，不是什么高级工具的任务，而是人的任务！
这个任务，没有任何机器能够代替。哪怕是最聪明的人，也不得不借助快速原型法，来确认真正的需求。
——————————————

基本上，所有的语言，最后都是一系列指令，告诉计算机，做这个，做那个，如果条件成立，做这个，否则做那个。

不同的语言，区别在哪里呢？
－－世界观
你如何看待你要操作的电脑，面向过程的看法，很贴近机器，面向对象的看法，很贴近真实的世界。

MDA呢？很贴近专家的梦想。

不同的世界观，为什么会带来不同的开发效率，不是因为抽象层次的提升，而是因为简化了常用的功能。

举个例子：
最早的机器，屏幕上的每一个点都要自己控制，显示一个字母，也很费力。后来出现了print函数，
可以直接打印字母，这样的功能当然方便，但是它简化了常用的功能，并不等于能实现当初一点一点
控制的方式能够达到的所有功能。如果要实现一点一点控制的方式的所有功能，一个print是远远不够的。
还需要很多很多的其他函数。

再举个例子：
在没有出现数据库之前，保存各种数据，都要对自定义的各种格式的文件进行操作。但是出现了数据库和SQL以后，
大多数的任务都变得很简单，但是真的要实现现实世界中各种数据存储需求，数据库的设计、使用，就成了专门的
学问。

MDA当然能够代给我们不同的“世界观”，但是这样的世界观能不能简化我们的劳动呢？不能！
当然，如果我们要做的项目，正好和MDA软件中给出的example一样，那一切都会变得很愉快。

————————————
再加一段
将软件开发与建筑工程进行简单类比，现在看来，越来越成为一种“陷阱”。这样的类比，可能会得出对于软件开发实质上有害的方法论。

因为软件是可以修改的，而建筑是很难拆除重建的。

修改，不断的修改，是软件开发的常态。
不承认这个事实，就会违反软件开发的本质。
————————————

实际上,经济因素是软件因素里面最最困难的地方.cost-effective,资源的调配.
实际上,方法学是有实施的背景的,离不开好多实际上的物理条件的(企业的方面),这点,在方法学的鼓吹者的文章里面从来不说的.
就好比追求永动机一样,没有一个total solution, 我没有读过silver bullet那本书,但是我所有的项目经验告诉我这么一件事情:技术和管理永远是计算机项目的两个脚,缺了谁都不行.没人负责也不行,只是leader负责也不能制造最好的项目.
好的机制不是管理压倒了技术或者反之,而是不断的改进,只要这个渠道是畅通的,如果你能在不犯不可挽回的错误之前完成项目的话,你和项目就都成功了.
反之,如果好多人都知道哪里错了,但是没有管道可以改善的话(至少是疏导),那么,10有8,9项目要失败的.

同意,有时候很无奈,但是搞技术的人就是干乱七八糟的修改的工作的,否则why boss要hire你呢?

只是希望企业能够成长,让自己能够位高权重事情少,用经验换环境,做一点不那么乱的事情罢了.

软件开发可和建筑工程类比的是建筑中的设计部分。
软件开发最困难的部分并不是对于需求中歧意的正确理解，而是软件开发概念的完整性的问题，也就是你理解这些有歧意的需求之后，拿出一个什么样的软件面对这样复杂的实际状况的问题。这一点在没有银弹中应该已经说明白了。
其实我们参考《分析模式》中最开始的部分，就说明了这样的一个道理。我们可以很简单的利用usecase来说明打台球这个问题，但是设计这样一个模拟的软件却是非常的困难，要实际使用很多物理的法则和还有添加很多偶然的因素。
而我们在实际项目中的实践也印证了这些，我们已经很清楚的知道了客户的需要，但是还需要找到办法满足他们的要求。

我恰恰不能同意的，就是这个论点。
软件设计与建筑工程设计，有本质的不同。
否则我们不可能在软件设计的发展过程中，看到XP，快速原型这样的方式。
按照《重构》的作者Martin Fowler的观点，你只要开始，然后发现不对了，再进行重构。但是在建筑工程可能这样设计吗？你可以想象先修楼，发现不对了，在对建筑物进行“重构”吗？

有一个曲线非常经典，“修改的成本随着时间加速上升”。通过这个曲线，似乎就顺理成章的证明了，必须重视设计，必须非常重视设计，甚至在前期的过度设计，都好过后期的修补。

但是这样的曲线是怎么得到的呢？为什么他们统计的那些项目中，修改成本到了后期就那么高呢？因为他们统计的那些项目，是仿造建筑工程的设计进行的。这样的设计，修改成本当然高。因为当初的设计，本来就不是为了便于修改的。本来就是抵触修改的。

作为一个恶性循环，这样的统计，得到的曲线，又进一步证明的了，设计应该更加被重视，甚至通过管理程序，限制客户的变更，限制修改的需求。

但是，软件的设计本来是可以“面向修改”的。在一开始设计的时候，就将系统设计为容易修改的，再通过技巧、过程、重构等等手段，将成本曲线拉平。这样的设计，才是符合软件本质的设计。



你说的软件，和我说的不是一种类型。
我说的，是这样的一类系统，无数人都已经做过，无数人还必须再做的。MIS，ERP，信息发布，工资管理，等等等等。这样的软件，只要需求清晰，实现起来其实早有“最佳实践”可以供参考。
而你说的，是复杂的，以前没有开发过的软件，这样的软件开发需求，即使非常清晰，实现也是十分困难。

但是世界上，大多数软件，都不过就是一个信息系统而已。