哪些是建筑师，哪些是建筑师？ 这其实是谈论建筑时一个永恒的问题。

从心底里，我真的不想回答架构到底需要做什么，架构师应该具体负责什么。 从实际情况来看，架构师的职责在不同的系统层次、不同的需求下会有所不同； 从不同的技术角度来看，架构师是一条变色龙——一个是技术大师，另一个是技术规划师。 此人曾一度担任技术组组长。

那么，如何回答“什么是架构，谁是架构师？”这个问题？ 这可能需要先澄清另一个问题——程序员如何走上架构师之路？ 我从很多同学那里学到了很多实际案例。 程序员走上了架构师之路。 最概括的原因就是他们过去写的代码很好。

那么，好的代码编写就意味着架构吗？ 并不真地。 写得好的代码只是一种幻想。 一切都需要规划，尤其是复杂的软件系统，更需要规划，否则你可能一行代码都写不出来。 复杂的软件系统肯定需要规划动作，例如多目标设计、对象规划和界面设计。 这就是“老一代程序员”所说的：详细设计。 做架构主要的事情还是一样，需要对整个系统进行系统的规划：模块、通信、边界、扩展、技术下沉等等，只有这样的规划完成之后，项目才能正常进行。

其实架构不仅仅是规划，另一个重要的事情就是技术鉴定。 识别系统中的技术难点，将复杂的技术分解成技术黑包。 在此基础上，进行了新的技术规划，使整个系统从技术角度上是层次化的。 从难到易，从大到小，但每一层对彼此来说都是一个黑匣子。 这也常被认为是让系统模块达到“鸡犬相闻，至死不相往来”的状态。

系统技术鉴定完毕后，还必须鉴定另一类技术，即人类技术。 什么样的工程师适合写哪一层代码家政公司组织架构图，那一层技术要求程序员的技术深度达到什么程度。 做完这样的事情之后，整个架构看起来就运行得很顺利了。

但事实上，架构问题肯定会再次困扰我们：首先家政公司组织架构图，测试工程师会问：“从整体系统架构来看，如何更好地测试这个应用程序？” “我们需要使用什么样的技术来更好地测试整个系统架构？” 保证软件的质量？”然后运维工程师上来问“系统要运行在什么样的环境？”“我们应该提供什么样的服务器？”“我们要在系统上做什么配置和安装？”服务器？ 基础软件？”“我们需要提供什么样的网络环境？”“有哪些特殊的网络配置？”“我们需要什么样的安全策略？”……这时，架构师有时会觉得一个跌倒进入山洞的猎人万分无奈，头顶上飞过成群的苍蝇，对于这种问题，有人略知一二，有人不专业，有人听说过但没做过，还有有的只知道原理，虽然这种棘手的事情很考验架构师的能力：技术的长短。

架构师需要足够的技术熟练程度。 从软件到硬件，从开发到测试，从运维到安全等，都需要全面的了解。 事实上，你可能不是这个领域最深入的人，你需要知道它们是怎么做的（不仅仅是表面的，而是深入的原理），以及它们组合起来是什么样子。 技术层面足够宽广之后，是不是人人都能成为完美的架构师呢？

答案是否定的，因为还会有新的问题出现。 这次的问题包括“系统今后的运维需要做什么？” “系统如何在未来的功能迭代中更便捷地扩展？” “系统应该怎么改？” “系统应该如何升级？”这时候你是不是一头雾水？ 你以为这个结构化的世界这么长，你怎么能像保姆一样照顾一切呢？ 但仔细想想，这是恰当的，因为一个系统的最初开发和交付只是其生命周期的一小部分。 旁边的维护、改造、升级占据了整个软件生命周期的大部分。 你是它的架构设计师，也是它的灵魂。 你实际上应该设计它的未来。 这也是架构师所做的最后一件事：系统的未来设计。

仔细想想，上面提到的案例都是建筑尴尬，但尴尬似乎是建筑师成长的唯一途径。 因为没有经历过失败的建筑师一定不是一个好的建筑师。 只有经历各种磨难，克服各种坑、各种痛苦，才能成为一名优秀的建筑师。 建筑师也是一个非常独特的职业。 与现代教育中已经成熟的人文、数学教育体系不同，勤奋的人可以通过系统的阅读和教育获得成功。 建筑更像是一门艺术，更是一门哲学，建筑师经过多年的积累，似乎突然打通了任督两条通道。