反模式——软件架构性反模式

	/**
     * 反模式——软件架构重构 3
     *      @软件架构性反模式
     *          关注系统层和企业层的应用结构和设计构件
     *              架构的重要性在于提供软件成功开发的重要关键。
     *
     *          架构师至少要进行复杂性管理。
     *          架构师和程序员的区别在于架构师要考虑他们的决策成本。
     *          架构关注
     *              划分
     *                  功能模块的划分
     *              接口
     *                  模块之间的软件接口，通信方式
     *              链接
     *                  应用于实现软件接口之间的接口链接实现的技术和功能性
     *
     *          @自生成烟筒
     *              把已有的软件接口转换为分布式接口出现自生成烟筒问题——自身软件无法很好完成工作，总是异常
     *
     *          @烟筒企业
     *              烟筒系统的特点是软件的结构限制了改变系统的能力，没有扩展性。
     *              系统之间缺乏协调和规划
     *              重构改进系统结构适应变化可扩展
     *
     *          @混乱
     *              当横向设计和纵向设计被混在一起，大概率产生不稳定的架构。
     *              不可避免的进行交叉，考虑如何能够保证稳定性和交叉性带给系统的伤害
     *
     *          @烟筒系统
     *              子系统被使用多种集成策略和机制即兴的混在一起时，而且都是用点对点的方式集成，每个子系统
     *              的集成方式都很难被其他子系统集成使用
     *
     *         @隐藏资产
     *              文档作者回避做出重要决策——不能承担责任，文档驱动的软件开发过程会产生没有太多价值的的需求和说明
     *              为了避免犯错误，作者会选择更加安全的路线，进行描述各种路线的各种替代方案
     *
     *         @供应商锁定
     *              在系统高度依赖于专有架构就会出现，对架构隔离层进行独立性设计，面向更多的供应商解决方案
     *
     *         @黄牛票
     *             交付时的接口和标准接口之间的差异过大
     *
     *         @实现主导架构
     *              集中关注架构中的风险和需求——居安思危
     *
     *         @温软身体
     *              有经验的生产力对软件项目的成功的重要，有经验的程序员的生产力是惊人的。
     *                  他们的生产力高出一个数量级
     *
     *         @委员会设计
     *              复杂，缺乏连贯性的架构设计。
     *
     *         @瑞士军刀
     *              设计过分复杂的类接口——追求100%的后果就是失去了时机
     *
     *         @重新发明轮子
     *              软件项目之间普遍存在缺乏技术转移导致大量的重新发明。
     *              可以利用就开始利用，如果可以提供利用就开始着手提供这个资产进行公用
     *
     *         @约客老公爵
     *              软件开发中的抽象派和实现派
     *              设计顶层，实现底层
     */