当时只沉迷于这个组件带来的超强日志功能。不过很快我们就尝到了恶果经常在日志无输出时在试了google出来不知道原因的解决方法失败后只能将log4net源码全部attach上慢慢的一行一行追踪这个庞大的类库来找出原因。有时我们甚至不得不进行日志的日志设计在日志失败时使用我们自己的最直接的最简单的最少出错的方式来记录日志的出错信息。而在我们头痛时那个看似可应付无穷变化的组件却几乎一次也没有给我们带来惊喜。日志永远在Warn级别输出日志永远存在系统的D盘根目录/系统名称下异常和警告邮件永远都会发向开发组的一个共用mail日志的格式更是从来没有变过谁没事天天会去琢磨日志是不是该增加一个什么记录就算要增加那也几乎要修改所有调用日志的地方幻想只通过修改那个格式配置文件就行当我们最终想要换掉这个日志组件重新换上一个不超过100行的自己写的日志类时这时才发现日志的变化点在哪里原来日志模块可能的变化是抽掉整个日志模块而不是整天考虑是日志在C盘还是D盘是记录Error还是Warn是要输出日志到Console还是资料库为什么会这样为什么该变的没有变不该变的又频繁在变现在企业开发有很多平台和框架像.net的Enterprise Libaray和java的SSH等。无论是何种方式何种平台都无法逃避系统开发的一般问题域的处理。例如如何进行数据访问如何输出日志如何处理错误如何读取系统配置。。。在面对这些问题时人们更多的时候是在寻找一个框架即使这个框架大到你只想要一个轮子而不得不接收它的整个车子你依然不会怀疑为什么这样做当你终于被这个车子的其它零部件影响到你这个小小的轮子行驶而不得不到处google爬文或分析源码在弄得焦头烂额筋疲力尽之时你心里又会不会发出这个。。。 能不能简单点的抱怨系统设计中变化是一条军规变化成就了今天的各种框架类库和模式。然而当我们洋洋自得于我们的系统应对变化的能力的同时。却没有反思变化会带给我们的影响我们不得不为一个几百年都不会第二次实现的接口而带来的复杂性买单对于一个优秀的系统架构师来说他除了要为应对变化而施展他的艺术创作才华很多时候他也必须分清哪些是需要变化的哪些是可以变化的哪些是不会变化。而要认清这些不同的变化首先就要理解问题域的本质例如缓存处理为什么要缓存处理它有什么用在系统中处于什么样的地位和其它模块的接口在哪里哪些是缓存可变的哪些是缓存不会变的当变化时在哪里处理这个变化对系统的其它模块的影响在哪里只有认清这些才会在引入某个模块时做到心中有数避开它的负面影响。与到处考虑变化相反的是很多时候我们却在排斥合理的变化。如经常看到一些询问如何应对表结构修改如何在增加栏位时不修改系统的讨论。有人认为是需求人员或系统分析师没有做好要是做好了就不会栏位变化了。这可能是没有遇到一些比较复杂的系统我们这边一个财务系统因为供应商客户的付款收货规则每次都在调整因此基本上每个月系统都会对一些流程业务实体作修改想固定不变那我们的工资都可能算不出来了。实际上系统要做到不变是不可能的因为世界每天都在变市场也在变企业的管理者会随着市场的变化而持续检视自己的经营行为改变流程优化流程缩短流程而作为系统的架构师就是要当流程变化时最快的修改系统以适应新的变化。变化反应了一个系统的生命力只有经常变化系统才能持续产生价值。相反僵化这也不能动那也不能改的系统最终会很快地淘汰出局。作为一个系统架构师当然希望需求分析比较完整比较准确。但更重要的是了解系统会在何处变化会怎样变化会何时变化这也是经常讲的技术不重要业务重要的一层意思。因为如果一点都不了解你系统的业务就不能在需求信息不完整或不准确时作出哪些变化哪些不变的架构从而在系统真正发生变化时无力应对。企业开发中只有变化才是真正的不变而抓住那些可以不变或基本不变的保持稳定。大胆地将一定会变的很大程度会变的进行最大的变化设计最终完成系统架构。从事企业开发将近8年希望在满十年的时候能够完成自己对企业开发的理解和总结因此决定开始这个系列是为序。