1引言
有一名专业的规划师（Jack）说过，一名工程师的20%时间应该用于做规划。随着我们经验的增加，对这一论断的相信程度也在增加。通过规划来很好的组织工作，生产率和效率都会得到极大的提高。不幸的是很多公司机构都试图把过多的规划活动形式化。规划在由个人来推动和利用时最有效，时间管理专家的一个减少压力的关键要素就是通过规划让生活中的各项活动保持均衡。随着这种实践活动的成熟，时间国立系统的形式和使用方法越来越个人化了。
2实现主体架构
本反模式的特点是开发中的系统缺乏架构规范。一般负责项目的架构师都有以前系统
架构经验，因此认为文档是不必要的。这种过度的自行导致在影响到系统成功的关键区域中风险剧增。比如下面某些区域往往会缺失架构定义：
1)包括对语言和库的使用、编码标准、内存管理等在呢你的软件架构和规范。
2)包括客户端和服务器配置的硬件架构。
3)包括网络协议和设备的通信架构。
4)包括数据库和文件处理机制的持久性架构。
5)包括线程模型和信任系统集的应用安全架构。
6)系统管理架构。
3带来的后果
1)缺乏架构规划和规范：对软件、硬件、通信、持久性、安全和系统管理架构的定义不足。
2)由规模、领域知识、技术和复杂性导致的隐藏风险随着项目的进展暴露出来。
3)由于性能不足、过度复杂、需求理解错误、可用性问题和其他系统特性导致项目将要失败或系统不成功。例如；大约1/3的系统在开发和运行中会遇到严重的性能问题。
4)不了解新技术。
5)缺乏后备技术和应急计划。
4产生的原因
1)没有风险管理。
2)管理人员、架构师或开发人员过于自信。
3)依赖于过去的经验，而这些经验与现实在某些关键区域有区别。
4)由于系统设计活动中的缺口导致隐含的和未解决的架构问题。
5重构方案
重构方案要求以有组织的方式进行系统定义，并依赖于系统的多个视图。每个视图从一个系统利益相关者的角度对系统进行建模，这里的利益相关者可能是真实的也可能是假象的，可能是个体也可能是一群人的聚合。每个利益相关者负责一组搞优先级的问题，每个视图都代表了整个系统并回答了这个关键的问题。这些视图包括一些图、表和规范说明，被连接到一个保证一致性。一般而言，视图是轻量级的说明。架构文档的作用是交流架构决策和其他问题的解决方案。文档因该易于理解，维护成本低廉。
只有完整理解一个架构的人才能够成功定义实现它。不过，现实往往并不是这样，因为很多项目采用了一些没有被很好理解的新技术。因此，从头开始建立良好的架构是一个迭代式的过程，大家都应该认识到这一点。起初的参考架构应该具备可以在第一个产品的开发期间被实现的强大策略。然后，可以使用将来的参考架构版本以增量的方式精炼他，并使用第一个产品或新版本来驱动这个过程。
具体流程如图：
躲在墙角、掩藏那孤独而又不奢怜悯的伤…
