最近想了想：在现在的项目里，我最关注什么东西？我期望它是什么样子的？实际上它是什么样子的？
第一个问题的答案，是代码质量。现有的项目中，有70%+的代码是我一手写出来的。然而现在回头看看，其中有90%+令我非常不满意。各种各样的问题充斥其中:功能上错漏百出，性能上隐患迭起；维护起来艰深晦涩，扩展起来困难重重。实在让我很不好意思承认这些垃圾是我制造的。
那么，我对代码质量的期望是什么样的呢？我想了想，有好几个方面。计划分别梳理一下。
先说说包结构。
1、代码的包结构应该是按模块来分。每个功能模块对应一个包。
这样做的好处在于，系统的结构会非常清晰。并且，这样处理会为后续的一些方面提供便利。比如第二条：
2、各个模块之间应该尽量相互闭包，互不引用彼此的类。
这应该是包结构上“高质量”的体现之处。包结构之间互相独立，能够将代码改动的影响范围限制在本模块之内，而且，在我们的项目中，存在这样一种情况：项目A中的某个功能A1需要以jar包的方式提供给项目B使用。在互相独立的包结构下，这个jar包很容易导出；但是在我们的项目A中，由于包结构和互相的引用非常混乱，为了导出这一个功能，常常需要把整个项目打成jar包。
但是要做到包结构的互相独立，很显然就会遇到两个问题。
第一，有一些模块的功能就是为其它模块提供基础支持服务的。这类模块可以不引用其它的包，但不可能让其它的包不引用自己。
这个问题只能特事特办。这类基础支持服务的包可以允许别的包引用它，但不应该引用到别的包；别的包仍应该坚持互相独立。
第二，如果某个包不得不引用到另一个包，那么该如何处理？
建议把被调用的服务放到基础支持服务的包里面。如果衡量之下实在不想这样做，那么就在被调用的包里放一个服务接口，为调用这个服务的包做一个适配器。
3、关于包的命名
这个无需太多赘述，一般都遵循类似“组织.项目.模块.子模块”的命名层次。只是对自己强调一句：各个层次的命名应该清晰、明确。另外，第二条所说到的包之间的独立性，从命名上而论，是在“模块”这一级别上的独立。
那么现在的状况呢？
这一点更加不必多费唇舌。我对包结构的期望，就是针对项目中的现状“有感而发”才产生的，由此及彼，现状不言自明。
第一个问题的答案，是代码质量。现有的项目中，有70%+的代码是我一手写出来的。然而现在回头看看，其中有90%+令我非常不满意。各种各样的问题充斥其中:功能上错漏百出，性能上隐患迭起；维护起来艰深晦涩，扩展起来困难重重。实在让我很不好意思承认这些垃圾是我制造的。
那么，我对代码质量的期望是什么样的呢？我想了想，有好几个方面。计划分别梳理一下。
先说说包结构。
1、代码的包结构应该是按模块来分。每个功能模块对应一个包。
这样做的好处在于，系统的结构会非常清晰。并且，这样处理会为后续的一些方面提供便利。比如第二条：
2、各个模块之间应该尽量相互闭包，互不引用彼此的类。
这应该是包结构上“高质量”的体现之处。包结构之间互相独立，能够将代码改动的影响范围限制在本模块之内，而且，在我们的项目中，存在这样一种情况：项目A中的某个功能A1需要以jar包的方式提供给项目B使用。在互相独立的包结构下，这个jar包很容易导出；但是在我们的项目A中，由于包结构和互相的引用非常混乱，为了导出这一个功能，常常需要把整个项目打成jar包。
但是要做到包结构的互相独立，很显然就会遇到两个问题。
第一，有一些模块的功能就是为其它模块提供基础支持服务的。这类模块可以不引用其它的包，但不可能让其它的包不引用自己。
这个问题只能特事特办。这类基础支持服务的包可以允许别的包引用它，但不应该引用到别的包；别的包仍应该坚持互相独立。
第二，如果某个包不得不引用到另一个包，那么该如何处理？
建议把被调用的服务放到基础支持服务的包里面。如果衡量之下实在不想这样做，那么就在被调用的包里放一个服务接口，为调用这个服务的包做一个适配器。
3、关于包的命名
这个无需太多赘述，一般都遵循类似“组织.项目.模块.子模块”的命名层次。只是对自己强调一句：各个层次的命名应该清晰、明确。另外，第二条所说到的包之间的独立性，从命名上而论，是在“模块”这一级别上的独立。
那么现在的状况呢？
这一点更加不必多费唇舌。我对包结构的期望，就是针对项目中的现状“有感而发”才产生的，由此及彼，现状不言自明。
现状中的问题，计划以小步走的重构、演进来逐步解决。后续的新的开发，应当注重遵循必要的规范才行。
本文转自 斯然在天边 51CTO博客，原文链接：http://blog.51cto.com/winters1224/826839，如需转载请自行联系原作者
