中艺库平台项目一期代码问题分析总结
1. 系统性能问题
系统经常会在打开首页时超长，这在系统在多个查询点也会出现，这是个原因较多的性能问题，目前选择的一个解决方案是：使用Memcached分布式缓存，目前我已经搭建好了Memcached服务器，写DEMO测试运行正常。
2. ACL数据权限问题
最初的技术选择采用EMC做企业内容管理的重点是，以它ACL数据权限完整的解决方案为亮点，放弃了对其他开源项目的选择。但项目一年下来，没有看到任何数据权限实现的影子。这个问题我在去年9月和技术主管提到过，在软考论文中也写过。
3. 批量数据导入代理
批量数据导入项目选择WEBSERVICE实现，在代理子项目中也使用了多线程处理。这个技术选型是不合理的，如果是艺术网或拍卖系统的外部项目服务调用，可以考虑WEBSERVICE，而且批量数据导入是个耗时问题，WEBSERVICE的SOAP对象传输复杂而且又大又慢，如果只是项目内部处理，建议采用JMS异步调用。这个技术选型因为我住院遗憾没有参与。
4. 业务类事务问题
系统大量的业务类事务配置不正确，采用嵌套事务的类较多，查询方法也没有做只读配置。系统大量的DAO中也做了事务配置，必须清除。
5. 图片转换功能封装
图片转换功能封装在image-convert.jar，不知道是否满足两个要求：一是系统变动后它也要做变动，二是能不能放进其他系统中直接使用。当初改用Maven做多地部署实现时，就是因为这个jar包阻碍实现。
6. DCTM引用问题
系统开发引用的DCTM的一系列jar包，如果全部去掉，项目大量代码都有红叉报错。建议在设计模式上进行改进。
7. 文件上传控件
系统的文件上传控件采用FileUploadApplet.jar实现，对于Applet控件的安全性非常令人担忧，这个东西只适合Java初学者学习，系统中建议改用Javascript插件实现。
8. 界面操作友好度
系统在界面操作友好度上不是很好，Javascript前台开发程序员欠缺。同时系统没有采用Strusts默认的JSON插件，如果想改选JSON插件也应该挑选最优秀最快的，却选择了一个很古老的JSON插件。从这个小问题上提出忠告：以后系统需要添加JAR包前一定要开会讨论。
9. Sitemesh配置使用
右键点击系统页面查看源代码，会发现大量js或css文件重复引用2-3次，这样会严重影响系统性能，必须合理配置页面模版。
10. 代码质量检测缺陷
检查结果报告见：http://192.168.61.7:9000/dashboard/index/2。系统现存16893个代码质量缺陷，建议129个二级缺陷全部修复，6,532个三级缺陷部分修复以降低数量。四五级缺陷可以忽略不改。
同事A：
1. 性能：
使用memcached，是通过在内存中缓存数据和对象来减少读取数据库的次数到达减轻数据库负载，一期并不是数据库负载大而导致性能慢，个人还是觉得数据查询的逻辑设计得不太好，错综复杂的交错查询。
代码质量虽然会影响性能，但是也不至于导致性能特别慢，我们使用的客户也是特别少，代码上的性能问题我觉得达到了一个极高的使用数量才能明显的显示出来。
2. 数据权限：
非结构化：虽然将附件存得没了影子，但是导致的问题也是导出变得复杂，使用API导出到目录，然后复制改名，无形中对附件多进行了一步操作。管理好操作系统，我觉得数据就安全了。
结构化：分析数据库一样可以查出结构化数据，管理好数据库就是管理好数据。
3. 批量导入：
这个Webservice并没拿来传数据，只是接到命令，就对本机非结构化数据进行处理。耗时性能，所以才没放入到web中进行处理，算是第三服务器单独来处理，然后通过DCTM的API进行非结构化数据传输，我觉得一期是对这些结构化和非结构化的数据控制没做好。一直是知道一点做一点，后来又改，导致最终补不上来。这就是为什么表都设计成auction名称的原因。批量导入功能希望能当个单独的复杂功能来进行研究。
4. 事务
这里确实如上所讲，后来在代码中也发现了这些问题，也告诉过惠普方，没有进行重视和规范处理。
这个问题是从一开始架构就出现的，如sitemesh也是一样，从最初的用，到后来不用再到后俩用没用都不知道了。
5. 图片转换：没见以前他们写的，但是目前我写了一个，准备给二期使用，可动态配置graphicsmagick和imagemagick来使用。CMYK格式永远是个比较复杂的东西，判断图片是否CMYK比较耗时。
6. DCTM
7. 文件上传控件：js不可行，我们的文件太大太多，个人觉得使用active控件比较好。
8. 界面：前端工程师缺乏，望二期补一个
9. Sitemesh：这里js和css重复用确实存在。
10. 代码质量：要有标准，比如规定所有代码不许有警告等。
同事B：
1.由于人员流动性大（需求方和开发方）中间又没有标准的过程文档（需求规格说明书）及评审环节导致前后不一致，代码反复修 改出现了附件中的问题。
2.缺少设计，缺少的是规范化的业务逻辑设计。把功能模块全部割裂式开发，没有统一设计整体流程在分模块开发。个别设计考虑不到位导致性能等无法满足需 求。
3.使用新技术时调研不足，例如个别需求系统无法实现等（3000个字符长度等，）。
1. 系统性能问题
系统经常会在打开首页时超长，这在系统在多个查询点也会出现，这是个原因较多的性能问题，目前选择的一个解决方案是：使用Memcached分布式缓存，目前我已经搭建好了Memcached服务器，写DEMO测试运行正常。
2. ACL数据权限问题
最初的技术选择采用EMC做企业内容管理的重点是，以它ACL数据权限完整的解决方案为亮点，放弃了对其他开源项目的选择。但项目一年下来，没有看到任何数据权限实现的影子。这个问题我在去年9月和技术主管提到过，在软考论文中也写过。
3. 批量数据导入代理
批量数据导入项目选择WEBSERVICE实现，在代理子项目中也使用了多线程处理。这个技术选型是不合理的，如果是艺术网或拍卖系统的外部项目服务调用，可以考虑WEBSERVICE，而且批量数据导入是个耗时问题，WEBSERVICE的SOAP对象传输复杂而且又大又慢，如果只是项目内部处理，建议采用JMS异步调用。这个技术选型因为我住院遗憾没有参与。
4. 业务类事务问题
系统大量的业务类事务配置不正确，采用嵌套事务的类较多，查询方法也没有做只读配置。系统大量的DAO中也做了事务配置，必须清除。
5. 图片转换功能封装
图片转换功能封装在image-convert.jar，不知道是否满足两个要求：一是系统变动后它也要做变动，二是能不能放进其他系统中直接使用。当初改用Maven做多地部署实现时，就是因为这个jar包阻碍实现。
6. DCTM引用问题
系统开发引用的DCTM的一系列jar包，如果全部去掉，项目大量代码都有红叉报错。建议在设计模式上进行改进。
7. 文件上传控件
系统的文件上传控件采用FileUploadApplet.jar实现，对于Applet控件的安全性非常令人担忧，这个东西只适合Java初学者学习，系统中建议改用Javascript插件实现。
8. 界面操作友好度
系统在界面操作友好度上不是很好，Javascript前台开发程序员欠缺。同时系统没有采用Strusts默认的JSON插件，如果想改选JSON插件也应该挑选最优秀最快的，却选择了一个很古老的JSON插件。从这个小问题上提出忠告：以后系统需要添加JAR包前一定要开会讨论。
9. Sitemesh配置使用
右键点击系统页面查看源代码，会发现大量js或css文件重复引用2-3次，这样会严重影响系统性能，必须合理配置页面模版。
10. 代码质量检测缺陷
检查结果报告见：http://192.168.61.7:9000/dashboard/index/2。系统现存16893个代码质量缺陷，建议129个二级缺陷全部修复，6,532个三级缺陷部分修复以降低数量。四五级缺陷可以忽略不改。
同事A：
1. 性能：
使用memcached，是通过在内存中缓存数据和对象来减少读取数据库的次数到达减轻数据库负载，一期并不是数据库负载大而导致性能慢，个人还是觉得数据查询的逻辑设计得不太好，错综复杂的交错查询。
代码质量虽然会影响性能，但是也不至于导致性能特别慢，我们使用的客户也是特别少，代码上的性能问题我觉得达到了一个极高的使用数量才能明显的显示出来。
2. 数据权限：
非结构化：虽然将附件存得没了影子，但是导致的问题也是导出变得复杂，使用API导出到目录，然后复制改名，无形中对附件多进行了一步操作。管理好操作系统，我觉得数据就安全了。
结构化：分析数据库一样可以查出结构化数据，管理好数据库就是管理好数据。
3. 批量导入：
这个Webservice并没拿来传数据，只是接到命令，就对本机非结构化数据进行处理。耗时性能，所以才没放入到web中进行处理，算是第三服务器单独来处理，然后通过DCTM的API进行非结构化数据传输，我觉得一期是对这些结构化和非结构化的数据控制没做好。一直是知道一点做一点，后来又改，导致最终补不上来。这就是为什么表都设计成auction名称的原因。批量导入功能希望能当个单独的复杂功能来进行研究。
4. 事务
这里确实如上所讲，后来在代码中也发现了这些问题，也告诉过惠普方，没有进行重视和规范处理。
这个问题是从一开始架构就出现的，如sitemesh也是一样，从最初的用，到后来不用再到后俩用没用都不知道了。
5. 图片转换：没见以前他们写的，但是目前我写了一个，准备给二期使用，可动态配置graphicsmagick和imagemagick来使用。CMYK格式永远是个比较复杂的东西，判断图片是否CMYK比较耗时。
6. DCTM
7. 文件上传控件：js不可行，我们的文件太大太多，个人觉得使用active控件比较好。
8. 界面：前端工程师缺乏，望二期补一个
9. Sitemesh：这里js和css重复用确实存在。
10. 代码质量：要有标准，比如规定所有代码不许有警告等。
同事B：
1.由于人员流动性大（需求方和开发方）中间又没有标准的过程文档（需求规格说明书）及评审环节导致前后不一致，代码反复修 改出现了附件中的问题。
2.缺少设计，缺少的是规范化的业务逻辑设计。把功能模块全部割裂式开发，没有统一设计整体流程在分模块开发。个别设计考虑不到位导致性能等无法满足需 求。
3.使用新技术时调研不足，例如个别需求系统无法实现等（3000个字符长度等，）。
扫一扫
2899
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
