|
|
这段时间比较空闲，总在考虑自己经历的这些项目的一些设计和结构上如何做得更好，做开发的人有一个共性就是追求完美，我也不例外，以下就是我的一些感想，欢迎大家发表意见。
不同的系统的完美标准应该是不同的，最简单的例子：产品和具体项目的差异就很明显，产品需要一个非常简单的安装过程，尽量减少安装后的配置过程，而具体项目就不一样，具体项目不需要安装过程，会有熟悉项目的人员进行实施完成项目的启用。本文只讨论大部分的项目都应该考虑的一些问题。
1. 扩展性
对于增加新功能或者进行功能增强时，系统是否可以很好的支持？评判的标准就是新增或者增强功能所需的资源以及对原有系统的影响，如果需要很多的资源并且对原有系统会有负面影响导致部分功能需要修改时，扩展性就应该不算好。当然前提是新增功能或者功能增强不能是罕见功能或者某种底层结构本身就不支持的，一般应该是中小性质的改动。提高扩展性可以从几个方面加以考虑：
i. 系统需求分析：在把握系统的主体需求的基础上，分析人员应该根据自己的经验考虑系统可以拥有的其他相关功能，或者是基于易用性的角度提供可能的需求，也就是需要充分的挖掘系统的潜在需求。
ii. 系统架构：不同的系统架构对于系统的可扩展性的支持是不同的。
iii. 系统设计：主要是系统的主体骨架设计，结合全部需求和系统架构设计系统骨架，选用不同的设计模式尽量使得系统的各个部分可以分离并进行拼装。
iv. 代码编写：比较好的按照封装的特性（没有使用OO或者OP等是因为个人感觉OP也可以进行比较好的封装达到某种OO的特性实现好的扩展性）编写的代码的扩展性应该是比较好的。这个方面的影响可能主要是对于功能增强而言的，上述的三个方面对于系统的新增功能和功能增强都有很大的影响，代码编写对于功能增强的影响要大一些，对于新增功能的影响应该比较小。
2. 灵活性
定制的强度，用户或者系统实施人员对系统在多大程度上可以进行配置，如果实施人员或者用户自己可以很方便的修改系统的某些运行规则那么系统就应该是比较灵活的。一般的系统都可以修改系统的某些运行参数，但是对于大的系统而言，系统的各个部分之间的协作是非常重要的，定制以后可能会导致某些无法预期的问题。一个灵活的系统应该有单独的配置管理模块，各个部分的运行都是依赖此模块的。
3. 兼容性
包括很多方面，主要是操作系统、数据库、浏览器，一般而言兼容性肯定是有限度的，因为在多种不同系统上的兼容性需要大量的高强度测试，特别是考虑到不同的兼容方面的组合时，测试的强度可能会成级数增长。选用Java语言之类的新语言在操作系统的兼容性上会有比较好的表现，因为Java的虚拟机可以完成大部分的操作系统级的兼容性任务；对于数据库而言，可以选用如Hibernate之类的对数据库的兼容性比较好的产品，它可以帮助解决一般的数据库兼容问题，另外也不会对性能造成很大的损害；而对于浏览器的兼容性现在似乎没有比较好的解决方案，而且浏览器的兼容性本身又涉及几个方面，包括html、javascript、css等，可能最突出的问题就是javascript。
4. 负载能力
系统的并发访问能力，这个问题和系统运行的硬件有很大的关系，但是也和系统本身的能力或者架构有关系。如果系统在进行设计的时候考虑到了集群的运行方案，那么可以通过集群及负载均衡来对系统的负载能力进行扩展。
5. 运行速度
这个问题和负载能力很相似，和硬件的关系很大，但是系统的设计也有很大的影响。提高系统运行速度的一个可选的方法是增加一个缓存功能，对于系统中需要经常使用的内容进行缓存（缓存到内存中），缓存的大小应该是可以管理的，根据系统的特点选用不同的缓存策略，最常用的可能就是最近最常使用原则了，为了保证缓存内容的可及时更新，可以增加监听机制在缓存的内容变化时通知缓存管理器。
6. 可测试性
应该说一个设计比较好的系统，它的可测试性也是比较好的，这个可测试性主要是指单元测试，系统中的类是否可以单独测试？系统的某个功能是否可以单独测试？系统的某个模块是否可以单独测试？按照某些说法，一个符合OO思想的系统也是可以单元测试的系统，这个不无道理，因为符合OO思想的系统其各个部分甚至是各个类之间的耦合是比较低的，因此应该是可以单独测试的。
7. 文档
不同的系统对文档的要求是不同的，任何系统，使用帮助是必不可少的，应该是根据使用经验得到的常见问题的总结，而对于第三方库之类的产品而言，还需要开发指南和规格说明，开发指南应该根据使用经验说明使用此产品的常见内容的方法，规格说明提供产品的所有规格，比开发指南的内容更多，但是组织结构非常不同。
完美系统的实现需要投入的精力可能是按需完成的系统的数倍，一个比较现实的选择可能是一个折中的方案，在考虑主体需求的基础上挖掘最可能的需求增强，并应用一些设计模式进行系统主体设计，提供部分定制功能，选用一些兼容性比较好的语言、组件和第三方库完成系统的构建。
|
|
