在软件开发界，大家普遍关心的是如何高效构建通用的工程模板。目前市面上流行的软件包各具特色，从中提炼精华来构建通用模板，无疑是一种既经济又实用的做法。然而，也有一些软件包在结构设计等方面存在一些争议。
流行软件包分析
当前市面上流行的软件包种类繁多。比如，有些软件包会把各种全局包和类归入应用程序包中，这样的布局看起来比较清晰。另外，如果软件包包含很多模块，它们可能会被拆分成多个包，其中会有一个主模块。以网易新闻为例，它的工程结构就与众不同，它是按照组件类型来划分的，把相同类型的类都集中在一起。这反映出不同软件包在设计理念上存在显著差异。在移动开发领域，针对不同功能需求的软件包各有其特点。企业在开发过程中，需要综合考虑不同类型软件包的利弊，以便作出合适的选择。
主模块的结构
主模块在工程结构中占据重要地位。若存在多个大模块，主模块可能包含多个子包，并且需要设定基础类。然而，若项目仅有一个主模块，则可以省去模块这一层级。许多开发者设计主模块时都会面临这样的思考。比如，在小规模项目中，若模块相对简单，为了简化流程，可能会直接省略模块层。而在大型项目中，主模块及其下属的子模块等多层结构会设计得更为详尽。
实体模块的状况
在实体模块中，我们通常应当重点定义实体类以便于全局使用，然而现实中并非总是这样。许多实体模块中的实体类定义并不符合一般认知。尤其在某些Java实体类中，缺乏get/set方法，直接使用字段名。这种做法在移动开发领域颇受欢迎，因为它减少了get/set方法带来的性能损耗。在具体的项目实践中，我们常会遇到这样的例子，有些开发团队为了追求更高的性能，会选择采用这种简化的实体类定义方式。
第二层结构分析
在一些软件包中，第二层结构有特定的处理手段。这一层可能不涉及模块分类，而是将各类具体需求的实现类置于其下。以日记相关的包为例，日记功能所需的实现类便直接位于这一层。在包内容结构难以解释的情况下，如某些单一应用的专用包，其内容结构需仔细分析。而不同应用对第二层结构的运用，则取决于具体需求。
类的放置规范
放置类项要依照既定规则。比如，在创建公共库时，采用“公司名+模块名”的命名方式较为妥当。此外，诸如监听器、线程、适配器等众多相关类，若直接置于包中，会使包显得混乱。因此，建议以匿名类或内部类的形式，将它们置于适当位置。许多项目开发中对此都十分重视，若忽视类放置的规范，后续的代码维护将会极其困难。
构建通用工程结构
分析过前述软件包后，可以构建通用的工程架构。比如，某企业开发了三个应用，其中某些包可以被多个应用共享，例如oauth是可选的包，view包则存放了如对话框等通用自定义视图；若某些视图不通用，则可存放在应用程序类包中。在多应用开发中，还需考虑库的共享问题，如资源替换、工程复用等，这些问题在通用工程结构中需进行优化。这一流程对于实际应用开发公司来说至关重要。
在制作个人通用的工程模板过程中，大家遇到了哪些难题？欢迎点赞、转发本篇文章，并在评论区积极参与交流。
