架构与设计

虽然我其实在软件这个行业里面也干了不少的年头了，但是回想起来其实很多时候都在从事一些很“粗浅”的工作。因为那个时候虽然在不停的写程序，但根本不知道什么是对的，什么是好的。所以，人其实不能总是埋头工作，总要用一些时间来思考。

总的来说，在我看来，从事软件工作，专业能力是最重要的。什么是专业呢？我觉得其一，能够熟练使用工具；其二，了解材料的特性；（注：各种编程语言其实都是材料）。因此，程序是最重要的。软件公司的价值是首先是人，其次是程序，最后是文档。而且文档是否是价值的一部分其实还很值得商榷。

下面说说  什么是架构

我理解的架构其实是在程序这一层的。这层才是最有意义的。好的架构，能够固化业务的精华，同时还能够通过抽象手段的应用来提高对变化的支持。此外，通过合理的分层可以使程序能够适应多人并行开发以提高效率。注意，架构不是工作的步骤，或者模块的划分，而是程序的结构。并且，不是静态的程序结构，而是运行中的程序结构。静态的程序结构，你看到的都是在不同目录里面的文件，这其实没有意义。架构的意义在于让这些文件以不同的顺序，按某种约定的规则合理有效的运行，同时，还能很好的扩展。

要做到这些，首先就需要能够对业务进行合理的抽象。抽象的目的很明显，就是为了固化某些东西，并让整个程序呈现一种层次结构。这样，让了解业务的专业程序人员，很容易理解，并且很容易分工。所以，设计其实针对的都是运行时，都是内存模型。至于你使用的是什么抽象手段，到还在其次，因为这个需要看你使用的材料是什么，这个材料支持什么样子的抽象手段。

那么什么不是架构

架构不是模块的划分和工作的步骤。因为这些东西其实是属于业务的。做不同的事情，他们就必然不同，另外，如果做相同的事情，他们就注定是相似的。就算你认为这就是架构，你也要明白，这种东西价值不大。因为对于业务来说，这些划分与步骤基本都是固定的，不能改变。把大象放进冰箱，总是那三步。如果你设计一个炒菜的系统，你分几个模块？洗菜模块、切菜模块，入锅模块、翻炒模块，出锅模块。总是这些，也许你可以分的更细，或者你分的更粗，但这些没有意义，因为你需要人实现它。

把大象放进冰箱，你需要实现一个能放下大象的冰箱，我觉得这和如何分析步骤比起来价值更大。很多软件公司里面缺乏真正的程序架构师，而这样的业务架构师往往很多。他们一行代码也写不出来，最爱干的事情就是写文档和开会吵架，一群人讨论的面红耳赤，把模块分来分去，最后形成一堆堆的文档汗牛充栋让人望而生畏而如何程序实现没人知道。实现出来的程序最终往往是打了折扣的，比如原来设计可以放进一个大象的冰箱，可能只能放进去一个大象玩具。这样的产品除了能骗骗人，也没有什么用处了。

另外还有一种很有趣的现象，那就是程序很薄，数据库很厚。有些人特别喜欢设计极其复杂的表关系，认为这个似乎就是架构和设计。那么我只能说他还停留在20年前。

什么是架构师

架构师是这样的人，首先他必然是程序方面的专家，必须熟悉材料。其次，他必须有好的理解力，能够和上面说的业务架构很好的沟通，能够把业务转换成程序。所以，真正的架构师注定不可能是一个人。我觉得最好的架构师应该是一个team，里面有业务专家，有程序专家，有数据库专家。