正文
那么，代码写的好就是架构吗？显然不是。代码写的好只是表象，做所有事情都需要规划，尤其是一个复杂的软件系统，这更需要规划，否则可能连一行代码都写不出。复杂的软件系统一定会需要做很多抽象设计、对象规划、接口规划等准备动作。也就是“上一辈程序员”口中所说的：详细设计。做架构主要的事情也依旧如此，需要对整个系统进行系统的规划：模块、通讯、边界、扩展、技术下沉等工作。这样的规划完成之后项目方能正常跑起来。
当然，架构也不仅仅是规划，还要做的另一件大事就是技术识别。识别出系统中技术的难易区域，并分解复杂技术，使之成为一个个技术的黑盒子，在此之上再进行新的技术规划，使整个系统从技术角度来看是分层次的，从难到易，从大到小，但各层之间又是互相的黑盒。这也常说的让系统模块间达到“鸡犬相闻老死不相往来“的状态。
系统技术的识别完成之后还要对另一种技术进行识别，即人的技术。什么样的工程师适合写哪一层的代码，那一层的技术对程序员技术的深入程度要求到哪个点上。在做完这些事情整个架构表面上看是平稳进行了。
但实际上，架构的问题一定会再次前来打扰：首先是测试工程师来询问“对于整体系统架构而言这个应用该如何更好的被测试？”“我们需要用什么样的技术来更好地保证软件的质量？”然后是运维工程师来询问“该系统将跑在什么样的环境之上？”“我们应该提供什么样的服务器？”“服务器上我们会做哪些配置和安装哪些基础软件？”“我们需要提供一个什么样的网络环境？”“有什么样特殊的网络配置？”“我们需要做哪些安全策略？”……此时，架构师不时会像是一个掉入冰洞的猎人无比无助，头顶成群的苍蝇飞着，这些问题，有的懂点，有的不专业，还有的听说过没干过，有些仅限知道原理。其实这些辣手的事情是考验架构师的一种能力：技术的宽度。
