大话重构读书笔记——进阶篇二

我们怎样拥抱变化

软件系统应对快速变化的终极利器,是以领域模型为核心建立的软件架构。

软件发展的基本特征就是变更,不论是源于需求的变更还是源于技术的变更。

运用领域模型,通过图形化的分析,可以让我们快速掌握真实世界的规律,进而指导软件的设计与开发。领域模型是联系真实世界与软件世界的枢纽,首先通过对真实世界的分析绘制领域模型,然后照着领域模型设计软件,就可以保证真实世界与软件世界的对应关系。

一般来说,领域模型是基于用户业务领域知识的分析,这些领域知识源于用户对软件系统的业务需求,却超越了业务需求。

领域模型,就是我们在逐渐学习和掌握用户的业务领域的过程中,将业务领域中的相关业务规则,以图形化的方式抽象成模型,方便我们日后的学习和交流。

基于领域模型的分析过程是一个科学的分析过程,它有它的一套科学的方法。通过这些方法才能保证我们分析的正确性。两种领域分析方法:原文分析法与领域驱动设计。

原文分析法(Textual Analysis),是在用例分析的基础上进行的业务领域分析,是一项在需求研讨会后整理和分析需求的工作。采用原文分析法之前我们首先就应当将业务需求整理成用例模型,为每个用例编写用例说明,之后对用例说明中事件流的文字描述进行原文分析。

领域模型是一种图形化的模型,既然是图形化的,就非常容易交流,为各方面的人员所接受。领域模型脱离技术,纯粹站在业务领域的角度进行探讨与交流。它采用类图的方式在描述业务的问题。

作为一个系统架构师,应当考虑一个足够合理的折中,以最大限度满足各方的需求。

先熟悉整个系统,然后是某个模块,之后是某个功能,再然后是你要修改的某个分支,最后到某段代码。慢慢地,你开始将分析的工作由业务功能向代码实现上细化。不要一行一行地读代码,那样效率很低。一个函数一个函数地去阅读,如果明白了某个函数的作用,甚至可以不用去阅读函数的内容。

快速阅读代码的另一个十分有效的方法就是重构。运用重构的方法去分解系统,以支持你对系统代码的理解,是非常有用的。

领域模型的绘制体现的是你对业务系统相关业务的认知程度,最初可能是肤浅的,甚至还会有错误。但没有关系,它代表了你再一步一步积极地学习。

测试的困境

自动化测试不是银弹,它不能解决测试过程中所有的问题。它不能测试与web容器密切相关的程序,也不能测试与数据库密切相关的代码。因此,我们不能因为追求覆盖率而盲目地编写自动化测试程序。

我们建立自动化测试的目的是:为了在日后的重构过程中不会让这些既有功能出错。

建立自动化测试体系:

  起初,我们首先建立起基于QTP的自动化测试,让原有程序都能测试通过,接着开始重构。随着重构工作的逐渐进行,业务程序逐渐与web容器和数据库解耦,可以开始编写基于单元测试框架的自动化测试程序。

系统重构的评价

超大函数的数量就是第一个评价指标,无所不能的大对象也不失为一个客观的评价指标,因此,评价一流系统中大对象的数据,是第二个评价指标,系统代码的复用率,代码依赖度。 

posted @ 2015-04-09 13:31  Ribbon  阅读(254)  评论(0编辑  收藏  举报