公司最近做的管理系统，因为感觉工作中系统框架设计很不合理，导致开发花费的周期也特别长，我跟组长有些设计理念不同，沟通无果，几次差点吵起来。想想程序员一句话叫“Talk is cheap,show me the code”于是想自己利用业余时间把项目重新做一遍，也想借此机会锻炼和检验下自己独立完成项目的能力。
首先总结下我认为目前系统里几个主要的比较失败的地方：
- 权限系统：权限系统是我认为这次工作项目里设计最不合理的地方，因为有特殊需求，要对每个项目的每个模块分开授权管理，类似于ACL，现有的RBAC模型不能满足。组长自己写了套权限系统，基本上大致原理就是写一个接口，把各种判断权限作为一个方法，然后针对每个子模块写判断，写一个ModelAttribute方法，拦截所有的Controller，取查询参数上的项目ID，然后去数据库里查询对应项目的的权限，前台用c:if标签判断权限。我认为主要缺点是1，严重耦合，与模块管理还有流程管理很多地方都是耦合在一起的，且各个控制器里要加一大堆方法。 2，依赖参数，因为ModelAttribute的方法是拦截控制器中所有方法，权限系统写好后，我们又花了很多时间改造Controller和前台页面。3，代码臃肿，调试困难，每个都单独有个权限类，权限方法是写死在子类里的，写起来很麻烦，而且前台调试权限的时候要倒后台跟断点。4，多余的开发，之前我提出过把项目角色集成到系统角色里，被否决，这样就等于要多写一套管理入口。
- 模型设计：太拘泥于三范式，表分级太多，表个数减少了，但是开发难度成倍增长。
- 项目模块：模块都是在代码里硬编码，包括模块的结构，链接等，修改起来很麻烦。
- 流程管理：流程管理，没使用工作流或者设计模式，与权限系统耦合严重，导致要加不少逻辑判断，每个Controller里还要加方法。
- 代码生成器：jeesite本身带的代码生成器功能相对而言不够强大，在实际开发中也没有充分利用起来。
- 需求管理：我认为开发系统前期需要跟用户大量沟通，摸清楚用户实际需求，这次项目开发的角色分工，到项目结束才拿到，跟之前的表格不一样。
基于以上几点，我的新设计理念如下
- 尽可能避免重复造轮子，造轮子需要较好的基础跟设计模式，且调试开发周期长，容易自己给自己挖坑。尽可能简化设计，同样的功能，可能有几种方案可行，多考虑几种，尽可能早的选定简单的方案。应用设计模式，减少耦合，遵循单一职责原则，对扩展开放对修改关闭。最后，尽可能最大化利用好代码生成器。
- 基于以上，我先选定的框架是Jeeplus，自己花120买了个无工作流的版本，开始看中的是他的样式，但是试用了下发现他的代码生成器很方便，比jeesite改良的地方是数据库校验和自定义对象查询，很实用的功能。
- 权限系统：第一版方案我考虑用需要路径中加入projectId来判断，这样的话就不用去管参数问题了，但是这样仍然要用ModuleAttribute，且没法用代码生成器，需要手写很多东西，而且可能有个重大的弊端是因为是两部验证，可能导致权限转移，一下没想好怎么解决。第二版方案是考虑用AOP，在需要权限过滤的方法前加入判断。弊端跟前面一样在前段应用不方便。第三种方案还是用shiro，应该上是理论上最好的办法了，但是如何针对单一资源，开始还没想好，后来经过考虑跟试验，发现权限字符串本身可以支持，只要设计好怎么加入变量进行判断及如何授权。这种方法一旦把设计思路理顺了，绝对是最方便开发跟移植的方案。
- 模型设计：打算在一定程度上保留冗余字段，违反三范式里的第三条:比如这次的概算表，底下要分8个明细，这8个明细里除了基础属性外，还有几个价格字段，如果严格按照三范式的话，价格做成子表。现在实际开发过程中觉得不合理，如果只保留主表跟明细表，就可以直接用代码生成器，且简化了查询方法。也少了很多逻辑判断。上个项目跟组长也有过类似争执，他把报告的年限单独拆出来做成父表。这样报告就变成了项目->项目年限->报告三层数据，这样在查询，传递，逻辑判断等等方面都增加了困难。我认为年限作为报告的属性就可以了，减少的开发难度是最少也是乘法级的。
- 模块页面：打算单独做一个模块管理，模块分两类，主模块，相当于分组，没有直接的页面，子模块，实体的模块，有页面颜色图标等属性。这样，就方便管理和持久化，可以随时在web端更换图标链接等不用改代码。载入模块的时候，根据权限判断具体哪些能展示，哪些隐藏起来。需要在开发中进一步思考跟解决的是，模块如何跟角色挂钩，角色如何跟用户挂钩，项目如何给用户授权。这每一步都存在很多可能性，设计不当会成倍增加设计难度。 最开始模块管理我打算应用最近学过的组合模式，但是发现没有必要，自己已经能够方便的遍历出来了，增加模式反而增加开发难度。
- 流程管理：因为权限系统剥离出来了，流程也相对减少了开发难度。决定用状态模式来实现，以减少代码中的大量if else之类的逻辑判断，分离出来也方便扩展。另外原有系统内的流程设计我虽然没详细看（也看不懂别人写的代码），但是从数据库中观察分析认为，没有必要把审批意见单独分表---设计的时候不知道基于什么样的考虑，审核跟意见是一对多的，可能是因为其中有个动作是只填写意见，不审批？我认为一个审批动作对应一条日志，且一条审批动作有一个意见就好。估计是用普通逻辑不好实现，这样的话，状态机的好处就体现出来了，跳转到自己本来状态也可以看做一个动作，把审批流程按顺序记录下来就好。
- 代码生成器：因为选的框架好，且更改了些模型设计，概算表我预计一天内就可以开发出来（原来我用了至少一个礼拜，且后期花费大量时间修改样式跟调试）
- 报表系统：这里指的是概算表，我打算用观察者模式来解耦。
- 其他：原有项目用的是自己开发的上传下载系统，我用的不多，我打算拿项目自带的来实现，以前没接触过文件上传下载，可能要踩坑。
不准备完成的模块及功能有：
- 项目以外的模块，普通增删改查，项目预算表，大体上与概算表相同。
- 报表总览与导出：目前项目里用的普通文件预览是pot与docx4j，在样式上都不是很好。项目报表用的是ureport2，比较占内存，未来会留意有没有更好的工具。
- 上传下载持久化及加密：感觉把文件名保存在数据库没什么意义，加密也没意义，因为key是保存到服务器上的，如果拿到服务器权限，秘钥也能拿到，解密也不成问题，多此一举，且不方便以后迁移。
- 数据废弃：功能上不复杂，就是加个标记而已，且没什么太多可改进的地方。
- 项目计划任务：没接触这个模块，直觉上感觉也是体力活，架构上可优化的地方不多。
未来可待学习改进的地方：
- 工作流：状态机虽好，也存在一些问题，如，不能配置，不能解决一些复杂问题。尝试未来项目里尽量用activiti，或者自己尝试下别的模式。
- springboot：打算再多尝试一些框架，比如分模块的springboot，比如支持restful前后端分离的框架例如guns
- 在线excel编辑：看能不能找到一个类似于vaddin-spreadsheet的框架，本项目中很多功能其实就是带公司的excel表格标记，这个框架效果极好绑定方便，但是缺点太笨重了，前后端都带的框架，且没法分离出来前端单独配合springmvc使用。
- 其他设计模式。这次也算第一次在实战项目里用设计模式，虽然以前跟着书敲出来大概明白，实际用起来还是有不少问题，希望未来多在项目中运用。