从IT的角度思考BIM（一）：面向对象

还记得那个笑话吗：要把大象放进冰箱，总共分几步？这不仅仅是一个笑话，还是一个值得我们好好分析的笑话。

如果要放进冰箱的是一个苹果，那么也就不可笑了，但换成大象，就引起了我们的兴趣和注意，为什么？

我们现在对BIM已不再陌生，但如果跳出建筑的视角来思考BIM，我们是否会有全新的认识呢？

本文将从IT的角度来思考BIM，希望能给大家带来一些启发。

面向对象与面向过程

当我们把一个苹果放进冰箱时，我们其实并不太关注它（或者试试把苹果手机放进冰箱！），我们关注的是放进冰箱这个事儿。不，事实上我们也不太关注冰箱，我们真正关注的是“保鲜”这个事儿（谁说我不关注苹果的，我可不想吃一个烂苹果）。把苹果放进冰箱的目的是保鲜，且通过简单的开关冰箱就可以达到这个目的，太方便了，顺便拿出一盒酸奶来喝。

然后我们听说要把大象放进冰箱里！哦，不，怎么可能！大象那么大个儿，冰箱那么小点儿，这不科学！

非常好，现在我们关注的不仅仅是”保鲜“了，大象和冰箱已经进入了我们的视野。

在程序开发者的眼中，大象和冰箱都可以理解为是对象。面向对象编程将对象作为程序的基本单元，关注对象及对象间的关系。我们对于把大象放进冰箱的困惑，其实正是因为我们在关注对象，在不知不觉使用面向对象的思维方式考虑问题，而放苹果的时候，我们关注的是“开门，放入，关门”这个动作及“保鲜”这个结果，使用的是面向过程的思维方式。

看，就是这样，秘密就蕴藏在生活之中，看上去是那么的普通，只待我们去发现。

仅仅通过一个笑话还不足以对面向对象和面向过程进行充分的了解，其实建筑师和各专业的工程师一直都在“编程”，只不过用的不是计算机语言而是建筑语言，而且面向对象和面向过程的思想都有涉及。“面向对象的编程并不在于编写代码”这句话可以让我们好好地思考建筑师和工程师在建筑领域里的“面向对象编程”。

BIM与CAD

面向对象的概念和应用已超越了程序设计和软件开发，扩展到了多个领域，现在我们不妨对照着百科中的说明看看BIM，哇哦！没错，BIM就是面向对象的概念在建筑领域的延伸。

等等！难道说CAD就不是面向对象了吗？从图形的角度来说，CAD是面向对象的，从建筑的角度来说，这个真没有！

从不同的角度来看问题，我们的关注点也不同。如果从产品的角度来看待建筑，我们关心的是建筑及其组成部分，而不是图形及立体几何中的元素。

当你指着图纸里的一条带有线宽的线段说“这根梁的位置需要调整”，没有人会误会你，因为大家都在用这种方式在图纸上表达。我们都知道梁是有轮廓的，而且节点形式还比较复杂，可这些信息在这段粗线条里却无法看到。有人会说：没问题，我是个CAD高手，可以按照真实的情况来画，且不但会画二维还能画三维的。实际上这完全可行，只要技术过硬，完全可以基于CAD继续开发，实现我们想要的功能。有一些软件的确也是这么做的。

但对于普通用户来说，这种规模的开发是不切实际的。并不是每个会骑自行车的人都能发明一个“A型自行车马达” 对自行车进行改造升级，作为普通用户，直接买一辆改造好的自行车比较方便。幸运的是科技发展的很快，虽然去探索潘多拉还需要点时间，但现在我们已经有种类繁多的摩托车和电动自行车可以选购了。

永远相信美好的事情即将发生！软件技术的发展为面向对象思维在建筑领域的应用提供了强大的支持。

回想一下我们是如何使用 CAD 软件进行工作的：点，线，矩形，圆……使用各种图形对象进行组合来画图，通过处理图形对象之间的关系来实现建筑表达的目的。再想一想我们是如何使用BIM软件进行工作的：柱，梁，墙……使用各种建筑对象进行组合来建模，通过处理建筑对象之间的关系来在数字环境下创造建筑客体。如果把CAD比作是绘画，那么BIM就是雕塑。通过在不同角度描绘物体，我们可以得到多幅画像，但每一次我们都要从头开始画，且关注的是当前角度描绘表达的准确性，这就是绘画的方式。即便现在我们可以使用数码相机快速地拍照，那也仅是绘画技术的升级，方式并没有改变。雕塑关注的是客观对象，通过对每一个细节的琢磨，雕像可以展现客观对象的真实形态，我们可以从无数个角度进行观察，只要雕像在，我们随时可以绘画和拍照。如果你是个“冰冰棒”，是在家里挂一张大照片给力呢，还是3D打印一个1：1的真人模型给力呢？

实际上BIM中也有很多的几何细节，并不比CAD少，但这些几何细节经过了封装，我们通过建立建筑对象和建筑对象之间的关系后，才能得到这些几何细节。这些几何细节对我们的意义在于它们是建筑对象的属性，而不是独立存在的。

尼古拉斯·尼葛洛庞帝曾说过：真正想要了解一只青蛙，传统的解剖不是办法，更好的方式是构造一只青蛙。

我们先放下手中的建筑切片，看看通过BIM我们是否可以真正地了解建筑。

敲响BIM世界的大门

敲门前我先讲一个真实的故事。新办公室装修，我决定采用千兆网络来布设这个局域网。我对网线的事不放心，再三确认下，装修公司说他们经验丰富，放心好了。结果等到测速的时候发现问题了。因为装修公司做预算的时候网线的长度是按箱计的，粗算下来觉得一箱够了。结果施工的时候少了几米，他们也没在意，就随手把一根六类线一分二，以填补他们因缺乏准确的计算而导致的遗漏。如果是百兆网络，这种做法没有什么影响，但千兆网络要是这样做的话，网速就会降级到百兆，六类线就失去了原有的作用。装修公司表示他们一直是这样处理的，也没见客户提出异议，由于重新穿这根网线太费周折，反复交涉下，最后他们做出了一些补偿。

你也许会纳闷，这和BIM有什么关系？如果我们把CAD比作百兆网络，把BIM比作千兆网络，现在看起来清楚点了：因为用得久，所以我们对百兆网络太熟悉了，以至于我们升级到千兆网络后对旧有的原理和方法毫不怀疑，自以为这些同样可以使用在新技术上。

有时候让我们犯错的恰恰是我们的经验，当我们迎接新世界时，我们也要重新审视自己。

如果新郎认为新娘是个女人就可以，对红盖头下的新娘没有任何期盼和掀起盖头的冲动，那么这段婚姻很可能只会走个过场，不管新娘有多美，新郎也不会懂。

如果这个故事敲响了你，那么说明你已经做好了准备。

是时候敲响BIM世界的大门了！

从IT的角度思考BIM（二）：模式与框架

我们满怀着美好期许，鼓起勇气敲响了BIM世界的大门。忽然人群中有人高呼：BIM已死，大家都散了吧！

这时人群开始骚动起来。“我早就说这玩意是忽悠人的吧，你们不信还偏要来”，“我花了好多钱准备这次探索，这都死了，咋办？导游在哪呢，我要投诉！”有些人原路折返，有些人捶胸顿足，有些人呆若木鸡。

门慢慢地开了，人群又开始骚动起来……

模式与框架

软件设计中的“模式”源自建筑师克利斯托弗·亚历山大（Christopher Alexander）与萨拉·石川佳纯（Sara Ishikawa）及墨瑞·西尔弗斯坦（Murray Silverstein）在1977年合著的书《建筑模式语言》（A Pattern Language: Towns, Buildings, Construction）。书中说道：每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心，这样你就能多次使用该解决方案而不必做重复劳动。后来这一理念被引入到了软件设计中，在四人组（Gang of Four，简称GoF。指 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人）合著的《设计模式——可复用面向对象软件的基础》（Design Patterns: Elements of Reusable Object-Oriented Software）一书中被人们熟知，广泛地应用在软件设计中。使用模式可以让代码更容易管理、重用和扩展，从而提高软件开发的效率和质量。

软件设计中常提及两种模式：一种是架构模式，一种是设计模式。架构模式是从系统的层面上定义各个子系统的职责并据此进行组织设计，而设计模式是从子系统的功能层面上来定义功能的实现方式。

与建筑结构中的框架相似，软件设计中的框架也是指结构。这个结构实现了一些通用功能，开发者在特定的框架下只需要实现核心的业务逻辑设计，从而提高了软件开发的效率和质量。

MVC

MVC是一种模式（主要体现为架构模式，也体现为设计模式），也有使用各类技术实现的各种MVC应用框架。

MVC是三个字母的缩写，分别是 Model（模型）、View（视图） 和 Controller（控制器）。它的中心思想是“分离”，目的是降低代码的耦合性，提高代码的重用性，使软件更易于测试和维护。简单来说MVC的工作原理就是M产出数据，V展现数据，C响应用户请求并对M与V进行控制和协调，整个软件的代码就围绕着这些角色来组织编写。M和V的工作方式有点像是使用Excel为数据创建图表。在Excel中我们可以使用各式各样的图表来展现同样的数据，对于一个M来说，可以使用多个V，每一个V都有其适用的情况。不过实际情况比上述比喻要略微复杂一些，比如在M和V之间通常还有一个角色，就是VM（ViewModel，视图模型），VM通过业务逻辑（Business Logic）处理M而获得，用于与V直接绑定，实现“数据驱动UI（User Interface，用户界面）”的理念。

建筑、信息与模型

如果我们从模式和框架的角度把MVC的概念“生搬硬套”过来，BIM该如何分离呢？从字面上来看，就是建筑、信息与模型。不过BIM里的M并不是MVC里的M，而是V，它代表着工具。我们根据需要选取工具创建信息，同样的信息也可以在不同的工具中展示及使用。从这一点看，BIM软件就像是一个复杂的 UI，通过它可以实现使用者与数据的交互。BIM中的I是MVC中的M，它既包含元数据（关于数据的数据，定义并规范着数据），也包含大数据（所有的工作流程数据及工作成果数据）。BIM中的B比较特殊，它既包含业务逻辑又包含控制器。在BIM中，所有的信息都通过复杂的建筑逻辑进行处理，又在各个专业和不同工作阶段中流动。

从上述角度对BIM重新分解，它包含以下部分：

BI(Building Intelligence，建筑智能），由建筑知识，建筑逻辑和建筑流程组成。

I（Information，信息），由建筑信息与工作流程信息组成。

IM（Information Maker，信息制造者），由各专业团队和生产力工具组成。

目前我们主要还是在局部范围内使用IM产生的信息片段，还没有能够有效地在全局范围内使用I。由于目前IM的问题已基本解决，软件公司正在朝着I和BI进发，当他们解决了I和BI问题的时候必将爆发建筑业的空前革命。

对建筑企业来说，如果不想被各类软件 “绑架”，就要从以上各部分着手将各类软件“消化”为企业应用平台的组成部分。

踏上BIM之路

门慢慢地开了，人群又开始骚动起来，因为人们看到了远处美丽的胜景和阻挡在眼前宽广的河流。

有些人自信满满地跳入了河中打算孤身游过彼岸，可是却失败了。

有些人匆匆忙忙地造了船胡乱地滑向彼岸，可是也失败了。

要想继续这段探索之旅，众人必须齐心协力紧密合作。

是时候把一群人变成一个团队了。

从IT的角度思考BIM（三）：敏捷开发

人们看到了远处BIM的美丽胜景和阻挡在眼前的宽广河流。有些人自信满满地跳入河中打算孤身游过彼岸，可是却失败了。有些人匆匆忙忙地造了船胡乱地滑向彼岸，可是也失败了。要如何继续这段探索之旅？

无论是《星际之门》还是《速度与激情》，好莱坞告诉我们无论一个人有多么牛，他仍旧需要一个紧密合作的团队。

敏捷开发

我们先来看看百度百科里对敏捷开发的解释：“敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。”

百科中还列出了敏捷建模的价值观：沟通，简单，反馈，勇气，谦逊。

简单总结一下，敏捷开发就是：

一个价值观：沟通、简单、反馈、勇气和谦逊。

一个核心：以用户的需求进化为核心。

一个模式：迭代和增量开发。

一个目标：保持软件持续可用。

目标

《命令与征服》中有一句经典标语：One vision，one purpose（一个愿景，一个目标）。可以把这句话稍作改动来说明“保持软件持续可用”这个目标：One version，one purpose（一个版本，一个用途）。

软件开发中的原型是一个基本的实用模型，体现了软件的核心功能。原型经过不断的改进完善，形成了最初的可用软件版本。而随后的升版则是不断地完善软件的稳定性、性能以及功能。

产品需要目标，团队和个人也需要目标。

管理大师彼得·德鲁克在开创管理学时就提出了目标管理，可见目标的重要性。乔治·多兰（George T. Doran）在德鲁克的基础上提出了SMART原则，简单清晰地揭示了目标管理的原则。

SMART不是SM的ART，而是5个单词的首字母，分别是：

Specific（具体的），目标必须是具体明确的。

Measurable（可以衡量的），目标必须是可以量化衡量的。

Attainable（可以达到的），目标必须是可以实现达到的。

Relevant（相关的），各个目标的实现具有相关性。

Time-bound（有时限的），目标的完成是有时间限制的。

你也许听说过WBS，GTD，6点优先工作制，四象限法则，番茄工作法等等，这些方法的本质都是要进行目标管理。

BIM的目标是什么？解决碰撞问题？设计持续准确？项目持续可控？资源持续优化？进度持续加快？工作持续自动化？这些都可以是BIM的目标。目标即会限制视野也会扩大脑洞，选择的目标不同，开展的工作就会不同。

你希望BIM实现什么目标呢？

模式

目标不是凭空实现的，那么如何实现呢？

敏捷开发采用了一种模式：迭代和增量开发。

Scrum是敏捷开发的一个主要分支，它定义了一种工作模式，包含了特定的角色、流程和规则，以便使团队更有效率地进行开发工作。

Scrum中使用的术语：

产品订单（Product Backlog），按照优先级排序的功能需求列表。

冲刺（Sprint），进行迭代和增量开发的时间周期（通常是固定的），团队在此期间细化并实现部分产品订单，交付可用软件。

用户故事（User Story），以一种短小简单的方式从用户的角度来描述渴望得到的功能。通常描述为：作为一个<角色>，我想<功能需求>，以便<受益>。

燃尽图（Burndown Chart），通过可视化图形的方式显示剩余的工作时间与待做事项。

Scrum导师（Scrum Master），负责帮助、引导、管理团队按照Scrum工作模式开展工作。

产品负责人（Product Owner），负责设定和管理目标，维护产品订单。

开发团队（Team），由负责自我管理开发产品的人组成的跨职能团队。团队具有自组织特性，个体需要跨越他们本身的专业而尽可能想办法帮助团队其他成员。

计划会（Sprint Planning Meeting），在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行工作估算的计划会议。

每日立会（Daily Standup Meeting），是团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。

评审会（Review Meeting），在冲刺结束前给产品负责人演示并接受评价的会议。

回顾会（Retrospective Meeting），在冲刺结束后召开的关于团队与个体工作改进的会议。

Scrum团队用来改善工作质量的常用技术实践：

测试驱动开发（TDD，Test-Driven Development），在开发功能代码之前先编写单元测试用例代码，通过测试来推动整个开发的进行。测试驱动有助于优化和改善软件的设计和质量。

重构（Refactoring），通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

集体所有权（Collective Ownership），是指所有的开发人员共同负责开发过程中的所有产出内容，特别是代码和自动化测试。它鼓励任何一个团队成员可以在任何一个程序模块上工作，确保开发人员不会变得太专、只能从事某方面的工作，以免只有个别人清楚某个地方的问题、完成某项工作。

持续集成（Continuous Integration），是指尽可能快地将开发和修改过的代码通过自动化的方式进行集成并测试，从而尽早地发现集成错误。

结对编程（Pair Programming），是指两个开发人员一起写代码，互相帮助，积极讨论，能力叠加。

也许有人会疑惑：不就是写个代码么，怎么那么复杂？实际上建筑工程也不是画个图、砌个砖那么简单。

工作中我们经常能听到：我只是个建模的，我只负责结构计算，我只负责方案……也会听到别人说：他就是个建模的，他就是个计算结构的，他就是出个方案的……也会自己说：这模型是我建的，这结构是我算的，这方案是我出的……身处建筑领域的我们，是否思考过敏捷？是否打算采用敏捷？是否可以做到敏捷？这是一个值得探索和实践的方向。

不管BIM是不是佛瑞德·布鲁克斯的银弹，至少它对敏捷实践会有很大的帮助。建筑数据化给设计和施工的进化带来了更大的动力和空间。也许十年后人们只负责创意，剩下的事情全部由Cortana、Siri和Now来完成。

核心

一听到“以用户的需求进化为核心”，设计师怒发冲冠、拍案而起：改图？！

咱们先看看ADAPT。

ADAPT是5个英文单词的首字母，它们是成功且持续实施Scrum必备的活动。

意识（Awareness）：意识到当前的工作方式已不再有效。

渴望（Desire）：渴望变革，渴望实施新的工作方式来解决问题。

能力（Ability）：通过学习新的思想、新的技术以及创造新的工具来拥有变革的能力。

推广（Promotion）：分享交流变革的知识和经验。

传递（Transfer）：将变革的影响扩大到整个公司，实现整个组织的敏捷转型。

有些程序员会因他们使用的语言建立自己的阵营，然后膜拜自己的语言，嘲笑和攻击其他的语言阵营。这像是技术宗教，语言就是教徒的神。在建筑领域也在发生同样的故事，只不过在这里软件工具才是神。CAD和BIM的口水战，各BIM软件的口水战……

当我们冷静下来时才明白，原始人钻木取火为的是取暖而不是烧香，语言和工具为的是解决问题而不是建立宗教。

如果模型可以自动生成，检查可以自动完成，图纸可以自动绘制，那么甲方和设计师是不是就可以牵手漫步在大明湖畔了？

别逗了，这些怎么可能做到自动呢？为什么不呢？到底是我们觉得不可能，还是我们没有能力让这些变得可能？看看我们的团队构成，建筑有了，模型有了，信息去哪了？建筑信息模型，听起来也和IT脱不了干系吧，可是仍有很多人对IT的认识就是“修电脑的，管网络的”。我们是否意识到BIM本质上就是一个关于建筑的数据模型，而我们现有的知识已经不够用了呢？是否系统性地思考过几个专业的协作和交融呢？使用CAD时我们也许没能意识到跨专业的重要性，但是使用BIM如果还是没有这种意识，那就只能呵呵了。

价值观

软件可以买，知识可以学，模式可以套，价值观呢？

一个人价值观的形成是有意识的还是无意识的？价值观可以进化或颠覆吗？

一个团队、组织、企业的价值观又是如何形成的？

稻盛和夫的经营准则是“做人何谓正确”，它表现为：公平、公正、正义、勇气、诚实、忍耐、努力、善意、关心、谦虚、博爱等。回看一下敏捷建模的价值观，非常相似。

阿米巴经营本质上和敏捷开发是一回事。星星还是那颗星星，月亮还是那个月亮，团队还是那个团队，人还是那个人。成功背后究竟是什么改变了，是价值观。

BIM可以精确到一个零件、一个螺钉，我们可以使用BIM计算出工程量以及投入的人力物力。在一个完全数据化的工作活动下，一切都是透明的，团队和工作是没有隐私的，实现“玻璃般透明”。

虽然实现这些有一些技术问题，但最大的问题则是——人们是否能接受。

企业高管们热衷于学习各种先进理论，然后感叹“听话的总是别人家的孩子”。人们被各种真人秀和梦想秀吸引了眼球，看着一个又一个的人“实现梦想”，而自己的生活却原地打转。一切的问题归根结底都聚焦到了人的问题。

为什么知乎上的回答者非常认真？为什么开源社区的人们愿意分享他们的代码？为什么萨尔曼·可汗愿意向人们提供免费的课程？

你准备好改变价值观了吗？欢迎来到BIM世界。