结构化设计，本想用架构作为标题，但现有的眼光尚显短浅，避免标题党的哗众取宠。

结构化设计是一种相当宽泛的概念，几乎所有的归类思考都可以理解成结构化设计。架构，作为一个听起来高大上的话题，个人理解仅从表现形式上来看，是属于特定领域结构化设计的升华：一个独立的、可自运转的系统的整体结构以及成员关系的设计，可以称之为架构设计。对于某系统进行架构设计的人可以称为该系统的架构师。（本文后续基于此概念会好不脸红的使用架构代替结构化设计进行描述。）

成功的从无到有构建了面向编译器指令模型的工具体系，也成功的被剥夺了工具的参与权，一时间计划大乱，闲下心来写个总结，也不枉干过一票。

特此声明：本文非技术贴，仅仅代表现阶段个人的思考和总结。

架构设计并不是程序员领域的独有概念，比如这个概念可以迁移到写书上。如果对于段落和语句的构思属于基本的结构化设计，那对于整本书要凸显的主题、叙述结构等等这些规划便也等同于架构设计的概念。

架构设计在很多人看来（包括曾经的我）是一种技术组装，纯从结构来看，确实也是。但即使仅仅从结构来看，架构的宏观图景也并不是通过简单堆砌而构建起来的，粘合剂也非常重要。好的架构便如榫卯一样，看起来浑然天成，相对胶水粘连的更像一种艺术。就先前写过的长文和短文的感受，短文遂写随发，而长文想要把控太难，需要耗费了极大的精力去协调。

从某种程度上讲，每个人都是架构师，但由于领域经验、思考的深度和广度、抽象能力等不同，先有一个门槛将一大部分人过滤（对于领域技术的深度思考是对于该职业的基本尊重）。再者，完整的项目毕竟有限，大部分同学只能作为开发者，便又过滤掉了部分。架构师这个概念不像是一个岗位，更像是特定领域的实力证明。

能掌握某领域的架构设计，这样的人很少。有很多分析架构的书籍，作者可以表达出或者总结出一些经验和思考，这确实很厉害。但这类指导仅仅能够减少这个领域的弯路，最关键的部分还是要自身锤炼出来。一定程度上，架构设计是带有灵魂的技术结合。在个人有限的认识里面，大多能在架构领域立足的同事，一般都有非常深刻的世界观和方法论的思考，在扎实的基础上依然具有各类好奇心，他们的知识爱好可能会跨越不同领域……他们更像一方世界里面的哲学家、思想家，架构的每个角落总会包含些回溯历史、基于现状而又面向未来的思考，最终在可实现的领域落地展现。

有时候我们会期望在某个特定的领域，架构可以归于不变的一，但……架构在具有一些通用特征的同时，也包含非常多的架构师的个人主观色彩，这也是架构有意思的地方。即使同一个架构师，相同的产品，在面对具有不同知识面的团队成员、不同的产品运营方式、甚至今天心情如何，其思考的架构设计都会有所差异。能力强并不能代表架构的实力，大多数情况下，一个产品很难由一个人独立完成，需要多的，可能非常多的参与者。架构设计的核心要素之一：构建一个整体模型，这个模型挖出了很多洞，不同的角色可以自由独立的填充进去，可以与架构以及其他角色交互而不黏连。它是对于技术、对于人员、以及其他各类资源的宏观设计与把控。

架构的大部分内容是可以放开的，在这么个物质便利、矫情多于思考的年代，真心不用做过多的防范。甚至如果有人消化了自己的设计，应该感到庆幸，那他便是自身的延续；如果没有，那更不用担心什么……架构师成长的路上剩下的人会越来越少，这需要更多的伙伴才能持续成长，抱残守缺是没有前途的，这也失去了架构的趣味所在，程序员也是。

架构之路在很大程度上，便是不知何时起，不知何时终，也很难看到路在哪儿，施展之地在哪儿，只有持续学习保持自身强大，当机遇来临时，才不会有所遗憾。共勉！