架构坏味道定义的三点扩展

坏味道可能存在于代码、设计、系统模型、文档和数据中——正如食物腐坏前会发出异味一样，代码坏味道指某段代码不稳定或存在潜在问题时呈现出的明显痕迹。Lippert和Roock 2007年给架构坏味道下的定义是：一种通常使用的、可对系统生命周期特性产生消极影响的架构设计，可能因在不适当环境下应用了不合适的解决方案、或在错误粒度层次应用了某个设计抽象而产生，会负面影响系统的可理解性、可测试性、可扩展性、可重用性——这个定义把架构坏味道定位为”与代码坏味道类似，但出现在更高的系统粒度层次”。但Joshua等人认为这个定义没有明确区分代码坏味道和架构坏味道（虽然两者都影响生命周期特性，但影响的具体特性维度不一样），于是从三方面做了扩展。一是明确架构坏味道是一个独立于工程设计过程而存在的设计实例——分析员可以在完全不了解开发团队、管理方式和过程的前提下，仅根据架构设计文档就指出可能存在的坏味道，这条扩展把架构坏味道从”过程性问题”重新定位成了”静态可判定的设计属性”。二是不具体区分架构坏味道究竟属于设计计划还是设计实现——设计实现的软件产品和设计计划之间只要存在不一致，就会产生一种架构坏味道，因为这种不一致本身就可能影响可维护性；这条扩展把”架构坏味道”和”架构腐蚀”（预期与实际架构的偏离）在概念上连接了起来。三是可以依据组件、连接件、接口这类标准架构模块，通过明确定义架构坏味道种类来简化检测过程——这条扩展是为了让架构坏味道具备可被自动化检测的结构基础。理解架构坏味道的关键是：它不是普通意义上的Bug，不会对系统造成毁灭性破坏，但会让系统处于危险状态，导致可维护性、可理解性、性能、可靠性、安全性大大降低——例如修改一个没有基本文档注释、组件功能交叉、服务分散的遗产系统，仅仅”了解原系统”这个过程就可能耗费巨大人力物力，有时甚至比重新设计系统还麻烦。但书中也提醒：是否要处理架构坏味道必须权衡收益，因为有些架构坏味道在某些方面消极影响不明显，修改反而会产生更多消耗。