架构师修炼III.docx

关于软件的设计原则有很多,对于设计原则的掌握、理解、实践及升华是架构师的一项极为之必要的修炼。记得在12年前第一次阅读《敏捷开发》时,五大基本设计原则就深深地植入到我的脑海中一直影响至今,我也由此获益良多。设计原则当然不止只有五种,最主要的面向对象的设计原则有以下这些: 单一职责原则(SRP)-就一个类而言,应该仅有一个引起它变化的原因开-闭原则(OCP)-软件实体(类,模块,函数等)应该是可以扩展的,但是不可以修改里氏替换原则(LSP)-子类必须能够替换它们的基类型依赖倒置原则(DIP)-抽象不应该依赖于细节。细节应该依赖于抽象。接口隔离原则(ISP)-不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。重用发布等阶原则(REP)-重用的粒度就是发布的粒度。P)-包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成影响。共同重用原则(CRP)- 一个包中所有类应该是共同理用的。如果重用了包中的一个类,那么就要重用包中的所有类。无环依赖原则(ADP)-在包的依赖关系图中不允许存在环。稳定依赖原则(SDP)-朝着稳定的方向进行依赖。稳定抽象原则(SAP)-包的抽象程度应该和其稳定程度一致。合成/聚合复用原则(CARP)- 要尽量使用合成/聚合,尽量不要使用继承 ….. 当然面向对象的设计原则远远不止这些,设计原则是伴随着开发语言的发展应用和软件开发经验的累加总结得出的经验汇总,随着语言的演变、开发方法的进步还会不断地衍生和进化出更多的的设计原则。应用设计原则可以避开很多的设计中的陷阱与误区,但在应用设计原则的同时需要紧记一点:设计原则本质上是一些经验条框,是设计的导盲杖而不要让它们成为束缚设计思想的牢笼。 每个架构师在经历长期的实践后也会慢慢建立属于自己的设计原则。多年来我也总结出了一些设计原则,并将上面这些这种可用于代码设计的原则归纳为:“代码设计原则”,另外一些应用于意识与设计过程中的原则称为“意识-行为原则”。以下我将会分别讲述我对这些设计原则的理解与运用的经验。 意识-行为原则  意识决定行为,很多的设计失误并不单纯源自于对设计原则的把握不足,而更多可能源自于架构师在意识指导上的错误,所以在开始设计之前应该先建立正确的思想与意识引导。以下的这些意识-行为原则是我从很多次的跌倒中总结出的一些心得,将期作为原则是为了时刻引导自己不会在类似问题中犯错。坚持创新原则首先谈谈模板式设计,我相信模板对于每一位开发人员和设计人员来说都是非常好的东西,因为它可以“快速”构建出“成熟”的代码、结构或UI。“拿来主义”在业界盛极不衰,对于架构师而言模板也有这种功效,在设计的过程中我们会经常遇到很多必须而不重要的“鸡肋”模块,没有它们系统会变得不完整,而它们的存在并不能为系统增加任何的“特色功能”,如:用户管理、角色管理或系统设置等。常见做法是,直接采用第三方模块或是从已有的其它项目中复用类似的模块,你是这样的吗?至少我是经常这样做的,因为我们的中国式项目通常是“验收驱动”,能通过验收、成熟可用就好。如果整个项目都只是由各类模板化的模块所构成,那么这个项目其实不需要架构师,因为不存在任何设计,所有的工作只是一种“融合”(Fusion)。可能这样说会有很多人会吐槽说这是一种“资源整合”能力,从“赶项目”的角度来说这无可口非,但从技术含量与本质上说确实不存在任何设计成分,这类拼装性或是“复制”性的项目只需要项目经理配备几个高级程序员就能完成了。我曾在“表达思维与驾驭方法论”一文中提到与销售的沟通方法,其中就有一条:“至少说出系统的三个特色”,这个表述对销售具有市场意义以外,其实对于架构师是起到一个重要的提醒作用同时也是在建立一种设计原则: 架构设计中模板的拼装是不可避免的,重要的是必须加入属于你的特色设计很难有人记得住整个软件的设计师,而却很容易记住某项极具特色功能的设计者。“特色”是架构师在软件中所留下的一种重要的印记,也是在团队中配备架构师的意义所在。设计出完全可被模板化重用的设计是一功力,而当中小型企业内出现这样的设计之日就是架构师离开企业之时,或许这也是当下中国架构师之殇。保持特色保住饭碗,你懂的。 固守本质原则  唯一不变的就是变化本身 — JerryMarktos《人月神话》不变只是愿望,变化才是永恒 — Swift 看到这两句经典是不是猜到我想就“变化”二字来一次老生常谈?其实不然,这两个字在业内估计也讨论了20多年了,也说烂了。我之所以引用这两位大师的名言只是想无时无刻提醒自己要了解身边的每一个变化,对他们的源头产生兴趣,从而深入了解。世界上不会有无缘无故的爱,也没有无缘无故的恨一切皆有根源,那是“本质”。我们来将“本质”与“变化”