基于报告之复盘

报告在数据分析相关的系统里是非常常见的,如年度统计报告、某一公司季度分析报告、某一行业月度分析报告、某一功能日使用详情报告等。在今年中旬我也遇到这样的业务。做的过程中遇到了很多的问题,不过好在这些问题最终都解决了。但我觉得应该对这个过程做一个复盘。

一、技术选型

  • Apache Poi;
  • Freemark;
  • Poi-tl。

最终我选择了Poi-tl。

二、应用场景

当天产生昨天的数据分析报告(日报告),本周一产生上一周的数据分析报告(周报告)。

三、功能开发排期

当时领导安排我带小L一起做,给了两周时间做这个,第一周把日报做完,第二周把周报做完。根据当时的情况,我很快制定出开发计划,由小L主要负责实际的开发,而我负责总体把控和一些问题的处理,因为当时领导还安排我处理其它的事情。我把制定好的计划发给了领导之后,开始多方并行(日周报相关和其它事情处理等)。我当时制定完计划后,以为不是很复杂,到最后不料发现,问题巨多无比,整整差不多两月才使其功能相对完整。

四、问题清单

  • (1)代码可读性问题。
  • (2)代码可扩展性问题。
  • (3)报告由word转pdf出现乱码问题。
  • (4)报告注入图片变形问题。
  • (5)报告由word转为pdf,内容表格出现下划线。
  • (6)报告表格表头自定义以及表格宽高问题。
  • (7)报告Pdf预览问题。
  • (8)报告服务器环境配置问题。
  • (9)报告生成后的URL通过代理下载失败问题。
  • (10)报告与其它API程序通信失败问题。
  • (11)报告字体问题。
  • (12)报告下载缓慢问题。
  • (13)报告定时任务重复执行问题(微服务集群下)。
  • (14)报告自动化生成问题。
  • (15)代码处理业务数据过程中的问题。

其实,远远不止上面这15个问题。面对这些问题我可谓是加班加点不断的思考、不断的实践,终于把它们都给解决了。

1.代码可读性问题

问题描述:魔法值到处都是(缺失常量定义)、注释非常少且不是特别明确、命名极其不规范等。

问题解决办法:借鉴《阿里巴巴Java开发手册》中的编程规约进行整改。

2.代码可扩展性问题

问题描述:到处都是重复性代码,而这些重复性代码是可以抽取为通用型方法的。

问题解决办法:出现两次或三次以上的代码块,将其抽取为一个业务通用型方法。

3.报告由word转pdf出现乱码问题

本地Windows环境生成报告正常,一到Linux上,生成后的报告,根本就无法看。

问题解决办法:
我针对该问题写了相关的文章,文章为Linux下word转pdf中文乱码问题

4.报告注入图片变形问题

问题描述:生成图片尺寸看起来正常的,一旦注入到word中各种形状体现(椭圆、扁圆、缩小体等)。

问题解决办法:
编写图片形状控制方法,统一定义生成图片的标准。

5.报告由word转为pdf,内容表格出现下划线

问题描述:word生成的表格没问题,一旦转为pdf,每个表格里面的数据都会出现下划线。

问题解决办法:
采用aspose解决。这个玩意是需要花钱买的,不过网上有针对如何破解的资料,感兴趣的朋友自行搜索即可。

6.报告表格表头自定义以及表格宽高问题

问题描述:
表头或表格因内容过多导致错乱。

问题解决办法:
编写自定义表头或表格内容自定义宽高方法进行适配。

7.报告Pdf预览问题

问题描述:产生的pdf通过Nginx代理不能直接预览而是下载。

问题解决办法:
核心代码配置:

1
2
3
4
5
6
7
8
location /file {
alias /home/file/project/oop;
if ($request_filename ~* ^.*?\.(html|doc|pdf|zip|docx)$) {
add_header Content-Disposition attachment;
add_header Content-Type application/octet-stream;
}
autoindex on;
}

修改完配置后记得重启Nginx。

8.报告服务器环境配置问题

问题描述:每次搭建相关环境都要上传很多文件配置环境变量。

解决办法:
编写shell脚本进行自动化处理。

9.报告生成后的URL通过代理下载失败问题

问题描述:生成的报告word或pdf,需要点击两次才能下载成功。

解决办法:
我针对该问题写了相关文章记录下来Nginx代理之大文件下载失败问题

10.报告与其它API程序通信失败问题

问题描述:报告中调用其它API,连接超时造成报错。

问题解决办法:
结合hystrix处理对应API的超时情况。

11.报告字体问题

问题描述:报告字体和数据注入后的字体不一致。

问题解决办法:
Poi-tl支持自定义字体。

12.报告下载缓慢问题

问题描述:点击下载报告,下载十分缓慢。

问题解决办法:
原来是响应式的,点击下载,后台进行数据处理,处理完毕后,生成word或pdf文件,后来改为定时任务生成,当天生成昨天的日报,用户一点击非常迅速,体验非常好。

13.报告定时任务重复执行问题(微服务集群下)

问题描述:不仅仅是报告定时任务在微服务集群下出现这样的问题,其它定时任务也如此。

问题解决办法:
使用Quartz解决该问题(Quartz是Java的定时任务框架,支持集群)或者使用ShedLock。我针对定时任务写过相关的文章,文章为Java之定时任务全家桶

14.报告自动化生成问题

问题描述:报告每天或每周会在特定的时间生成,但生成有一个前提,业务数据必须没有问题,否则会报错,最终导致无法生成。

问题解决办法:
优化代码,完善处理逻辑,不管业务数据是否有问题,均正常生成。

15.代码处理业务数据过程中的问题

问题描述:代码处理业务数据计算过程中较为缓慢,涉及取数据、存数据再计算、比较运算或调API以及一些算法等。

问题解决办法:
重新梳理和理解业务流程(之前写的时候,只想着快速完成,不管对不对或者代码执行效率如何),化繁为简,将复杂问题简单化。

五、总结-提炼方法论

每一次复盘是为了更好的汲取经验教训,提炼出相关的方法论进行团队推广,避免下一次少犯或不犯错误,从而使得产品研发的过程中高效率,使得最终交付的成品高质量。经过了这些问题的解决和开发报告的这一过程,我总结了如下方法论:

  • (1)技术选型确定后最好多写几个示例用于团队成员参考;
  • (2)每天跟进团队成员开发情况,询问遇到那些技术类难题,集中时间由Leader或团队技术较好的成员进行集中攻关,减少技术类难题的阻碍;
  • (3)统一团队编码规范(注释必须写、魔法值抽取为常量、重复性方法进行抽取);
  • (4)功能完成后,预留开发人员专门测试入口,方便问题的排查;
  • (5)理解业务,多问为什么,不要过于着急做,做的过程中,一定要把流程梳理清楚(简单txt文件就能搞定这件事);
  • (6)主动向上沟通,反馈进度和已出现的问题或可能出现的问题,让领导心里有底,知道这块并不是那么容易做的,多争取些时间;
  • (7)功能完成后,模板备份留存,示例备份留存(数据完整性的样例),以供领导需要时用;
  • (8)提测前,环境一定要搭建好,搭建过程中,将步骤流程化为脚本进行自动化(留待后续预生产环境、生产环境安装和配置等)。
文章目录
  1. 一、技术选型
  2. 二、应用场景
  3. 三、功能开发排期
  4. 四、问题清单
    1. 1.代码可读性问题
    2. 2.代码可扩展性问题
    3. 3.报告由word转pdf出现乱码问题
    4. 4.报告注入图片变形问题
    5. 5.报告由word转为pdf,内容表格出现下划线
    6. 6.报告表格表头自定义以及表格宽高问题
    7. 7.报告Pdf预览问题
    8. 8.报告服务器环境配置问题
    9. 9.报告生成后的URL通过代理下载失败问题
    10. 10.报告与其它API程序通信失败问题
    11. 11.报告字体问题
    12. 12.报告下载缓慢问题
    13. 13.报告定时任务重复执行问题(微服务集群下)
    14. 14.报告自动化生成问题
    15. 15.代码处理业务数据过程中的问题
  5. 五、总结-提炼方法论