软件工程革命三部曲 —— 软件工程
摘要
相信在博客园，大部分是工程师，而不是科学家。
阅读完本文，您将了解基于RBAC的权限理论、数据挖掘的核心理论、.net的设计思想等。软件工程的核心本质。
同时，本文是软件工程革命的三部曲系列之一，当第三部结束后（预计10年底），您将能领会到我提出的，尚未有人涉足的一个新的工程革命！
原始的开发与工程级别的开发
原始开发模式：
我一个人开发了一个MIS系统，部署到客户端。客户提出需求，我直接在源代码上修改编译，然后提着USB，或者直接传个package过去升级。如果我有需要修改代码，也是直接在代码上修改，然后编译，发布。
可是如果我面对着10个顾客，很快就会力不从心，有时候改了，自己以为所有影响都考虑到了，可是部署到了客户端，第二天就打电话来说启动不了。然后只好亲自去客户现场一个个修改。（亲身体会）
工程模式：
每次修改代码的时候，首先写一份分析报告，包括需要修改的代码部分，修改的目的，受影响的其他依赖DLL文件。
（省略N步的开发、回归测试、功能测试）
结束后，传到实验室的测试机进行稳定性测试。一般要进行3天到一个星期。实验环境和客户环境是一致的。然后再部署到客户端。
对比：
明显工程级别的开发烦琐很多，而且“不用脑”的更多了，我们胸前带着光荣的“software engineer” （软件工程师），表示我们干的东西就越不用脑子，越机械。
所以，我就得到了工程的核心思想。
工程的思想
核心思想是：在万变中寻找不变，并不用思考的服从。
无论是开发软件过程、还是开百货连锁店、还是任何大规模的项目，必定符合工程的思想，就是尽可能的不用脑子。
无论任何与工程相关的技术，也是体现了一点：让操作者更加的愚蠢。只有这样，才能实现工程的目标。
所以，问题就来到了 与工程相关的技术 这一点上了。
与工程相关的技术包括什么？例如ORM框架、持久层框架、金色海洋的自然框架、 hibernate、spring、基于角色的权限系统（RBAC）、数据挖掘（不包括分析）、甚至.net平台也是工程的产物，而不是科学的产物！
现在就让我一个个去分析这些工程技术的本质共同点。
RBAC权限理论 —— Role based Access Control
博客园上吵的最厉害的，无非就是数据访问和权限。
首先您的权限框架无论用什么死人技术、无论多么的方便甚至吹的天花乱坠，您的技术必定要提供一个功能：
根据当前登录的用户名（username），是否拥有对应的资源编号（ResourceID），如果有，表示能操作、如果没有、表示没有权限。
在很早的ACT理论里面，提供了一个访问控制列表。简单的模型，就是设定了每一个用户对应的资源列表。然后判断权限的时候去查看这个列表是否包含了资源编号。
User <------> ResourceID
可是伟大的工程师们发现，这个USER非常不稳定，小张今天是科长，明天是处长；小李今天在庶务二科，明天就到了庶务三科。这样变得经常修改权限列表。怎么解决？您动动脚趾头就想到了，添加一个中间层去隔离变动。于是出现了RBAC
User <------> Role <-------> ResourceId
调整之后，由于Role/Resource之间的变化是很小的，剩下的变化就存在了user/role之中，瞬间就解决了50%的工作量。
权限系统无论怎么设计，无非就是：根据具体的行业添加不同的中间表。例如角色表、科室表、部门表、上下级表等等等等。
Datamining ——数据挖掘的核心思想
一项技术不过瘾，我再解释下数据挖掘。
首先我先列举一些让这个技术与外行人隔离的术语。
OLAP / ETL / 数据仓库 / 事实表 Fact Table / 维度表 Dimention Table 。。。
首先，假设数据库的销售数据表是
{
MERCHANTCODE //商家编码
MERCHANTNAME //商家名称
SHOPCODE //门店编码
SHOPNAME //门店名称
ITEMCODE //商品编码
ITEMNAME //商品名称
SALESQTY //销售数量
SALESPRICE //销售价格
}
让我们回想下，如果要查询销售数据怎么查？写SQL贝。例如
A. 查询时间段内的销售记录，不就是
SELECT SUM(SALEPRICE) FROM POS_SALESRECEIPT WHERE CREATEDATE > :DATEFROM ...
B. 查询某门店的销售记录，不就是
SELECT SUM(SALEPRICE) FROM POS_SALESRECEIPT WHERE SHOPCODE = :SHOPCODE ...
如果门店有地区的区分，则使用JOIN去链接地区的表，然后修改一下查询条件。 剩下的例子就不举了。
可是伟大的工程师们又发现，这些销售记录往往是百万千万级别的，但是查询条件是百、千级别的。如果每次查询都需要遍历整个销售数据表，就太慢了。而且当业务发生变化，例如国内企业变成了国际企业，则销售数据需要添加国家的字段等等。
怎么办？让我们在动动脚趾头吧！添加中间表，然后加外键！
首先我们把销售表拆分成以下（先拆3张吧）：
POS_SALESRECEIPT ---- DM_SHOP（门店表） ---- DM_MERCHANT（供应商表） ---- DM_DATETIME（时间表）
---- DM_ITEM（商品表）
然后对应的表结构变成：
{
SALESQTY //销售数量
SALESPRICE //销售价格
DM_SHOP_PKCODE //外键指向门店表
DM_MERCHANT_PKCODE //外键指向供应商表
DM_DATETIME_PKCODE //外键指向时间表
DM_ITEM_PKCODE //外键指向商品表
}
DM_DATETIME
{
PKCODE //主键
ORIGDATETIME //原销售时间
DATEOFWEEK //销售时间的周
DATEOFMONTH //销售时间的月
DATEOFYEAR //销售时间的年
}
DM_SHOP
{
PKCODE //主键
SHOPNAME //门店名称
LOCATIONNAME //地址名称
DISTRICTNAME //区域名称
COUNTRYNAME //国家名称
}
（剩下的表结构就不列举了，反正就是简单的拆分）
现在我们查询，首先是搜索拆分的表，然后通过JOIN链接的销售表，就可以获得销售数据，例如
A. 查询时间段内的销售记录
SELECT SUM(POS_SALESRECEIPT.SALEPRICE) FROM POS_SALESRECEIPT INNER JOIN DM_DATETIME ON POS_SALESRECEIPT.DM_DATETIME_PKCODE = DM_DATETIME.PKCODE WHERE DM_DATETIME .XXXXX
最多加几个GROUP BY（貌似SQL的诞生就是为数据挖掘服务的。。）
怎么样，现在觉得够简单了吧。这个就是数据挖掘。。。MY GOD....
所谓的ETL，即使如何从一张原始销售数据表拆分成为多张表。
所谓OLAP，就是如何去用一些（助记符 ）更加方便的拼SQL
所谓FACT TABLE（事实表）就是POS_SALESRECEIPT，DIMENTION TABLE（维度表）就是DM_DATETIME ...
.NET的精髓
工程技术可以一直讲下去，其本质不过就是那些，咱们动动脚趾头也能想到的。篇幅有限，我先转战到.NET的设计。
.NET最漂亮的地方是：无耻的抄袭了JAVA的“中间语言”Java Bytecode思想，形成了自己的一套IL，即所谓的MIL。其他什么F#, C#, 动态、反射等等都是小儿科。
估计各位看到这里，会有一种醍醐灌顶的感觉，没错，这就是工程的核心思想。
计算机硬件不同，那么执行的指令一定不同，不同的操作系统支持的指令也不一样。如果要针对不同的硬件、平台去写不同的代码，估计大多数人会崩溃的。
于是伟大的工程师又出来露露脸了。无论计算机的硬件如何设计，必然遵循着一定的规律，比如寄存器、堆栈等等，那么通过引入中间层IL，让IL映射到目标代码（这部是非常简单的），然后我们的业务逻辑再映射到IL，是不是工作量就减少了50%？所以为啥IL长的有点像汇编之类的就是这个道理。
后续与下集预告
其实对于技术进步，我实在想不明白为什么会这么慢。例如.net，竟然要2k年前后才出现，而电脑在195x年就有了。不知道那些伟大的工程师们什么时候还会再出来露露脸。
下篇，我会针对现在软件工程中一个薄弱环节提出自己的工程化理论，并且分析。这项环节相信大多数人都会经历并且无可奈何。不是做不到，而是很多人没有去“工程化”。
咱们下回再见！（也许是几个月后） 希望您保持关注！鄙视我的人请点击推荐！支持我的人请点击推荐！反正只有推荐。哈哈哈！
