基于报告之复盘

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

一、技术选型

• 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代理不能直接预览而是下载。

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

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)提测前，环境一定要搭建好，搭建过程中，将步骤流程化为脚本进行自动化(留待后续预生产环境、生产环境安装和配置等)。