纵谈软件预构（一）——开篇

      非常偶然地学到了一个概念，叫预构。接下来的时间，就对预构的各个方面做下简单的探讨。

      首先，我们先来看下什么叫软件预构。听到软件预构这个词，相信很多人第一个想到的词都是“软件重构”，我也不例外。但是这两个词完全是两个概念。

      重构是对一个已完成的项目利用模式进行实际的设计，代码上的修改。而预构是利用前人，或者曾经开发的经验来进行现有软件项目的开发。换句话说，预构是一种经验流，每个人都在预构，只不过没有接触到这个词罢了。只此而已。如果偏说预构和重构有什么关系。我大概概括了下，就是预构的经验是从重构中获得的，预构可以减少重构的次数。

      好了，解释过了这个词。我想我该对我这个系列的文章重新做下简介了。与其说我是在讨论预构，不如说我在谈我对软件工程各个流程方面不同的理解和思想。

      废话到此为止，现在开始正式的“预购”，在我的开篇文章中，主要就是说下“预构”的核心思想。

      从曾经的机器码，到汇编，Basic,C,C++再到今天的C#,JAVA，F#等等。我们不难看出，软件语言一代代地发展，趋势和目标就是用最短的时间开发出最好的软件。这里有两个字是核心：“好”和“快”！伴随而来的是软件工程的一个个新概念的诞生：XP极限编程，喷泉模型，螺旋模型之类等等。还记得学生时代第一次项目经历——在线学习考试系统。当时初探软件工程，小组会议上豪言我们要采用瀑布模型。当时学院给的项目时间是五个月。老师一周开一次项目会议，与其说是项目会议，不如说是不停地需求变更。于是我们就不停地总结需求，结果需求分析花了两个多月，基本确定了下来。然后开始搞设计，没有任何经验的我又花了两个月的时间，最后剩下了半个月开始写代码，接下来大家可以猜到，设计错误，界面设计不合理，模块无法整合。最后学院大笔一挥，.NET版本滚蛋，继续采用JSP。

      痛定思痛，学会了迭代-递增。接下来的项目开始越来越成功，从需求，设计，甚至到小组成员培训，一共算在内，往往可以超额完成任务。直到现在，我依然坚持着这样的流程：需求-->第一次设计-->编码-->代码优化-->设计重构-->需求变更-->第二次设计-->改善设计-->编码-->代码优化-->设计重构...........

      在《软件预购艺术》中，引入了这样一个词：极致——抽象化到极致，关注点隔离到极致，可读性到极致。对其中的观点，我并不完全赞同，下面仅陈述我的观点：

      1. 类型抽象极致化。我的意思是指初始化设计阶段，每种数据类型尽量不要用int,double等实际类型表示。如Age这个概念，恐怕用实体数据类型描述要花一番心思。不能太大，不能太小，不能为小数，在初始设计时，把精力花在这些细节上是不好的。就干脆写成Age age更好些。等整体设计确定后再来关注这些细节。

     2. 可读性极致化。这点不用我多说，没有谁爱看没有任何编码规范的代码。我个人基本不用任何简写，宁可名字很长，至少以后看起来不用动脑筋，有了智能感知，我也不用担心拼写错误的问题。

     3. 面向对象适度化。在初学设计模式时，处处设计，乐此不疲。但在实际项目中，过度抽象，过度对象化并不是件好事。抽象是为了变化，没有了变化就不要费力去抽象。

     最后，再套用一句话：“情境就是一切”。在山路上开着法拉利跑车不会被人羡慕，只会被人骂做神经病。一个优秀的软件设计，架构师最大的优势不在于他们的技术，而是他们的随机应变的能力，也就是经验流，回到主题，也就是“预构”能力！