项目总结

最近的时间,进一步的接触项目经常用到的框架，有了一定的思考和心得，有些结论还需要接下来进行验证和证实！

gradle的使用

这次项目包含A和B模块，其中A部分依赖模块B，我需要同时更新A和B模块。所以需要在编辑器的project中关联A和B，但是第一次导入的时候，A和B总是不再统一层级，所以在网上找了一些解决办法，有些方式不能解决自身项目的关联关系，需要因地制宜解决实际问题。

项目环境： | 环境名称 | 版本 | | ——– | —–: | | 系统OS | window7 64位 | | intellectual ide | 2016.03 | | java | 1.8.0_112 | | gradle | 3.1 |

解决方式一(失败)：

父级目录
        ----A
        ----B
        ----setting.gradle

在A,B同级下添加setting.gradle文件，里面写上

rootProject.name = 'A'
include 'A','B'

然后重新利用ide导入，我自己试验了几次，ide还是不能识别同级的A，B模块

解决方式二（成功）：

父级目录
        ----A
        --------setting.gradle
        ----B

在A添加setting.gradle 文件 里面写上 includeFlat ‘B’ 这样ide导入A的时候，同级project导入B，但是如果直接用ide导入父级目录，还是不能识别A和B

解决方式三（成功）：

第一种方式和第二种方式合并，在父级添加方式一的文件，在A模块添加方式二的文件，ide直接导致父级目录，ide可以完全的导入A和B。这里可以把第一种的配置方式变成：

include 'A','B'

不需要添加第一行的设置信息。

关键知识点：

include：实际上对于模块的关系，利用setting文件可以完美的表达，实际对于include的关键字，表达的是组合的关系，表示的是当前目录下有哪些需要构建的模块。 includeFlat：对于此类关键字表达的是模块之间的依赖关系，当同级目录的需要依赖其他模块的时候。 > 在查询资料的时候，还发现有些setting文件还会有 rootProject.name的用法，仅凭这一关键字，无法表达模块间的关系，所以在表达模块组合以及依赖的关系需要上述的设置信息有效。

引用博客1 , 博客2 .

GWT的使用

这次项目的改动点涉及GWT的后端serive的新增接口的调用以及前端页面组件的数据处理过程。需求点是添加前端页面的一个图片，同时附带图片的hover和click的动作，这个动作的效果总结一句话是：出现一个浮层显示信息。 图片的动作就附带着前端和后端的数据的交互，考虑到本身框架编写前端效果的复杂性，更重要的是需求的扩展性和对于未来增强作用的前瞻性，我需要做的不仅仅是完成功能这么简单，如何保证下次会有增的需求（围绕图片动作变换的效果），达到代码改动最小性。

组件封装

组件如何封装能够据有扩展性：

最大的痛点:

页面的不确定性：这个是导致前端每次变更大的原因，即使组件化了，每次改动还是不可避免的向集合定制的组件，添加新的元素，进而添加新的动作。 GWT生成前端页面样式的不可控性：实现的效果总是很丑，在调试几次页面效果的时候，不难发觉，一个简单的样式，GWT自身生成的脸面都和想象的不一样，这里原因主要有两个：

一：看似GWT对应前端的组件，实际对应的前端代码和实际不一样，印象中记得用过一个XXXbutton的组件，最后看前端代码，实际是个div，和button完全没关系。 二：对于GWT的控件，不可能每个样式都要进行设置，GWT生成的前端页面，自带一套class样式。

如何在最大痛点下，尽可能的减少代码的改动性：

提升组合组件的功能性：对于组合组件进行归类，通过归类组件实现组合组件的接口化的操作，对于组件的接口，不建议直接调用GWT基本组件的方法，需要封装一层，保证下次变动的局部最小化。

利用参数控制组件的初始化以及效果化：其实这种思想还是，尽量的让影响的范围最小化，记得软件的开闭原则说的对于扩展可以接收，对于更改要坚决避免，利用参数化当不需要控件的时候，可以进行不初始化以及效果的隐藏，这种类似伪开闭原则的方法。

是否有过度设计和事倍功半的嫌疑：是否让开发变得复杂，或者说到最后连开发者都会对于组件的可用性进行选择都糊涂掉；目前我接触到的GWT的组件，一是需要在html页面进行标识，另外就是不需要通过注解标识。当组件变多的时候，我个人容易糊涂的地方是对于行为控制的不确定性，实质是一个函数控制相应控件的事件动作和效果的不确定性。

作者 无与伦比
2017 年 05月 10日