关于语言与架构（三）

对于语言来讲，我讲得实在太少了，一方面是对于具体的语言而言，我很多是浅尝即止，没有很深入的研究，比如Ruby，Python，以及Prolog，等等，这些语言由于没有具体使用，所以谈不上理解。另一方面则是由于气氛的原因，怕引起无意义的争论，不能多讲。

前面谈到语言的具体使用，使用无疑是了解掌握语言最好的方法。比如，有一段时间由于需要，天天泡在“看雪”，熟悉了各种破解工具的使用，并因此将原来只是写在书本里的汇编装进了Head。我们在做这样一些事情的时候，我们仅仅只需要语言的帮助就可以了，我们写一些小程序的时候也是这样。当我们需要面对一个系统时，情况就发生了变化。

很显然，大家都会知道我要说的是“架构”这个词语。早期，在Dos下编程时，我还在热衷于用C语言画出来的按钮哪里要多画一笔以创建阴影，显示立体效果，并乐此不疲的时候，我并不会意识到系统是什么。到了现在，我还很难确切的去描述它，所以用一些感性的语言来说，而且仅仅是说我们常常面对的MIS系统。

时间是系统的一个重要因素，离开了时间这个概念，好像什么都失去意义了。对于系统来讲，时间在很多地方存在，系统第一次和用户见面的时间，系统建设所花的时间，系统存续的时间等等。时间对于开发者来讲，也是非常重要的，就不必多说了。

目标是系统存在的原因，因为要达到某个目标才会去构建系统，人们不会去构建一个比微生物还小或者比恐龙还大的不知道是什么东西的系统，你一定能够给你的系统取一个名字，这比给儿女起名容易多了，因为这个名字即系统的目标。

钱是世界上最大的游戏工具，在系统中自然少不了钱的概念，有了另外的名词：成本和利润。在系统的建设阶段，存续阶段，没有利润的事开发商不会做，没有成本预算的事，业主不会做，难道不是吗。很重要的事情是往往会忽视系统存续阶段的金钱问题，有两种典型：一种类似买了一辆国产车，前期便宜，后期金钱不断；一种是买了进口车，不管便宜还是贵，如果业主后期只愿意出很少的钱来维护，开发商没利润（不是什么技工都能修进口车的），车子实在没办法的时候只好当废铁。

人是系统中不可或缺的部分，这包括创建系统的团队和使用的团队。先说使用的团队：一般评估系统的规模时只从系统的目标入手，看看业务模型的规模，我也这样做过，但现在我看系统的规模首先看使用团队的规模，涉及到多少部门，多少人，多少领导等等是系统决策和定价的必要因素。

至于建设团队来讲，个说个话，有很多书，文章讲了不少了，都有道理，看你怎么应用。我想一个优秀的项目经理总不至于在一个团队中采用清一色的中科大吧，也不至于请中科大的人都来画按钮，团队需要分工，架构因此产生（顺口而已，架构怎么产生的我不知道）。

废话很多，后面再续吧