所谓的“软件架构师”

最近在找工作，发现“软件架构师”这个词很流行，大牛或者自以为是大牛的研发人员都喜欢这么称呼自己，好多公司也张罗着说“我们没有软件架构师”。
今天去一家公司面试，部门经理向我介绍另一位面试官说“这是我们的软件架构师”。我突然想起有关软件架构师的一个段子，话说美国国防部组织的一个软件开发座谈会上，做军工产品的雷声公司的副总裁提问，问在座的工程师有多少认为自己是软件架构师，结果有一半人举手，又问有多少人认为自己是系统工程师，有三分之一的人举手。然后该副总裁提出了两个问题，其一是什么是软件架构师，其二是软件架构师和系统工程师有什么区别。然后就开始出笑话了，每当一个人提出软件架构师是什么的时候，总会有其他人反对这个说法，也没有人能说清软件架构师和系统工程师的区别，最后有人背了一段IEEE标准文档里面的话，结果这个定义不但没有澄清什么是架构师，反而制造出更大的争议，最后该议题只好草草收场，剩下一位一头雾水的副总裁和一大堆愤愤不平的程序员。
软件体系结构这种东西我也知道一点，不过据我所知，这方面其实学院派的气味很浓，离实际应用还非常远。而所谓的设计模式，其实仅仅局限于一个特定应用领域中的几个特定问题的成功经验积累。尽管事实让人沮丧，但这不妨碍好多自以为是的程序员称呼自己是“软件架构师”。似乎程序员和软件架构师的区别好像是建筑工人和建筑师一样，用软件架构师称呼自己显得水准更高。
然而写软件和盖房子不同的是，大多数的建筑都有标准结构和标准件，建筑师在此之上发挥自己的想象力和技术训练设计出别人喜爱的房屋。不幸的是，软件没有标准结构和标准件，软件工程师们更类似于建筑学成为真正的建筑学之前的工匠，带着几个小徒弟，使用自己熟悉的1～2种结构，然后从烧砖、锯木头开始建造房屋，有一点创新的就会被称为鲁班。可这不是建筑学。对于应用技术来说，首先要有清晰的问题分类，之后是知道解决问题的方法。知道什么是对的还不够，还要知道什么是错的。换一种说法是，工程人员使用技术去解决问题好像是带着镣铐跳舞，只有知道了限制在什么地方，才能跳出优美合适的舞步。在软件技术发展的历史中，最常见的现象是每隔几年都会有人提出来包治百病─或者至少是对某种病症有奇效─的药，当这药不灵的时候，药的崇拜者就会拿出萨满巫师治不好病人时的口气说，你的病不好是因为你对这项技术掌握的还不够。如果现在去看看当年面向对象技术刚出来时的广告词，肯定很多人有恍如隔世的感觉。
当然，这种话我不会在任何面试场合说，典型的砸场子行为嘛，对自己没有什么好处。不过每当我听到有人大肆宣扬自己是软件架构师，或者某个团队说，我们缺软件架构师，所以才什么什么的，我就会直接得到一个结论，这个人或者这个团队是绣花枕头。在没有建筑学之前，任何人称呼自己是建筑师都是笑话。
话题回到面试，我说了一个多小时，介绍我自己的研发经历，累得够呛，结果说完之后回到家一琢磨，NND，合着我是给人上了一堂科普课，介绍软件项目中所遇到的管理或者技术问题和我的解决方法。