标签：原型 roo 情况 src 学校 log 多个 变化 通过
《人月神话》中Brooks一直非常强调“概念完整性”对于系统的重要性。十年前看这本书的时候总是觉得不懂，是一种说不清，朦朦胧胧的感觉。
【转载自http://blog.sina.com.cn/s/blog_a49b04f601017533.html】
概念的完整性，是指针对于一个领域，不仅了解该领域的所有对象，并且了解所有对象之间的关系。比如，小学数学中的四则运算。所有的对象就是指有理数，所有的关系就是由加减乘除四种运算而能够产生另外一个有理数。如果对这样的计算完全了解的话，那么使用这样的领域来解决问题就不成问题。
概念的完整性在一本20年了还是非常深刻的软件工程书中被重点提出。这本书叫做《人月神话》。作者通过自己的经验及大量的数据而找到软件开发出现问题的主要原因——概念不完整。
概念不完整，就在开始注定一个软件项目要失败了。就本人的经验来看，很多项目都因为没有对问题了解得足够细致，然后就进行了软件开发，结果所写的代码不能实际解决问题，于是又改代码，并且是不断地去改代码，期望通过改代码来达到解决问题的目的。
其实，问题的根本在于，概念不完整，换言之，就是，始终都没有搞明白问题域有那些对象，各个对象之间是什么样的联系。能够考虑这样的问题的人，一般都是对完整的概念有着强烈的要求并且在这方面具备相当经验的人。写代码的人很难考虑到所写的这一部分代码是否真的解决了问题。在被要求改写代码的时候，只是大概了解别人要改一个需求。
但是，需求从来就不需要改，需要改需求，只说明一点——没有真正搞清楚对象及对象之间的联系。从而没有办法了解问题。在没有真正了解问题的时候，只能被动地等待问题的出现，然后去改代码，以头痛医头，脚痛医脚的方式去解决问题。
而概念的完整性，是建立在已经完全了解领域的对象及对象之间的关联。这种完全了解，并不是感性地了解，而是理性地了解。如，在小学数学这个领域，加法与乘法具有交换律。即，
a + b = b + a
那么在考虑加法与乘法的时候，可以只考虑将小的数放在前面，大的数放在后面这样的情形。从而可以得到简化的加法与乘法口诀。即，只要知道 2+3=5 就可以知道 3+2 一定等于 5。
这样的例子是为了说明，在了解关系的时候，要上升到理性认识，而不是停留在表象上。
又如，考虑社交网站的例子。表象上来看，社交网站要记录每个人的兴趣爱好，职业，曾经就读的学校等。这就导致需要建立一个用户表，建立一个爱好表，职业表，学校表：
而这样的关联完全可以抽象成：
User <--> User_Object <--> Object
name user_id name
object_id
type
time
社交网站所需要记录的是人与物的关系，及人与人的关系。一个人喜欢一个物（爱好），做一个物的事（职业），读书于一个物（学校）。以上的抽象，就可以将人与物的关系及时间概念完整地表达出来。
也就是说，概念的完整性，并不是将所有的东西都知道就可以了，还需要真正达到一定的理性认识。达到一定的抽象才行。
软件是一个修改起来代价相对较小的东西，比起造一辆车，一个软件做得再差，也不会造成巨大的现实世界的变化，它最多改变的只是硬盘中某一个区域的磁性。而造一辆车子，需要现实世界中很多物质发生变化才可以做成。从而，这推动了人不把问题想清楚的惰性。一个软件不再依赖于设计人员有着完整的概念，而依赖于开发人员不断地去改。
因而，概念的完整性不仅仅因为要做到概念的完整性不容易，同时因为软件失败的代价很小，更因为根本就没有认识到概念的完整性的意义，从而在软件项目中被忽略了。其结果就是，花费大量时间做着重复的事情，改着冗余复杂的代码。这就是为什么《人月神话》中重点提出：因为没有概念的完整性，从而造成大多数项目失败。
保证概念的完整性，一方面需要设计人员具备良好的经验。同时，不要尝试着去将所有人的意见都融入其中。
如，一个软件，要考虑的是大多数人的使用场景，或者重要人物的使用场景。对于个别人物或者次要的使用者，可以少考虑或者不考虑。本人在多个项目需求讨论中都会遇到这样的情况：某个人提到要一个功能，其理由是：我就是喜欢这样的功能。这样的“我”往往是代表着极少数使用者。
而作为一个要求概念完整的人，如果这样的功能影响概念的完整性，就需要果断放弃。而不能牵就于极个别的“我”。
在《人月神话》中，提到解决概念完整性的方法——外科手术团队式开发方法。在这样的团队中，外科医生（首席程序员）一个人来决定一个软件要做成什么样子，并且去写主要的代码。
也就是说，为了保证概念的统一性，需要有一个人或者一个团队（解决巨大问题的时候需要一个团队）来决定什么东西做，什么东西不做。而不是去牵就所有人的要求。这个人或者团队是要有经验的。
在制造一批汽车或者制造一栋楼房之前，设计人员都会做好详细完整的设计。之后再进行实施。一批汽车或者一栋楼房，如果没有造好，会造成很大的损失（这里的损失不是算钱，而是计算对现实世界的改变有效性）。
本人所遇到做得好的软件，其基本流程是：原型→确认原型→开发→测试。原型与原型的确认，就是在实施之前想把概念了解得更加完整，而不是在实施之后不断地去更改。
本文介绍了软件开发失败的主要原因——没有完整的概念。并且很多项目都还在不断地因为这样的原因继续失败。在考虑一个领域的概念完整性的时候，会因为各种原因而考虑不全，但努力方面是明确的——搞清楚完整的概念。
标签：原型 roo 情况 src 学校 log 多个 变化 通过
原文地址：http://www.cnblogs.com/Antiver/p/7580473.html
