Evilom
19 lines
3.6 KiB
Markdown
19 lines
3.6 KiB
Markdown
# BuTXwr0boidXf8kUmv4cYAYSnKf
|
|
|
|
Source: https://ocnmca6f1o0p.feishu.cn/wiki/BuTXwr0boidXf8kUmv4cYAYSnKf
|
|
|
|
|
|
## 工作内容概述
|
|
1、财务取数工具交付并收集问题进行修改
|
|
## 一、多账期结构升级
|
|
面对业务方需同时输出连续多个月数据的反馈，我绝不能把系统的残缺转嫁给业务方。最初想到的加个账期参数让工具多跑几次的方案，不仅破坏了一键交付体验，更会引入跨月数据不一致的“版本漂移”风险。
|
|
我放弃了外置参数循环执行的方案，转而对底层逻辑进行修改。通过源底稿中错综复杂的日期格式进行归一化处理，现在具备了自动扫描底稿、识别存在月份并一次性全量输出的自适应能力。把复杂留给底层架构，把极简留给业务端，砍掉所有配置、让系统自行决策输出边界。
|
|
由于财务数据高度敏感且无法本地全量运行，系统的盲改风险极高。我采取了“抽样先行”的防御策略，本地整理制造数据。面对 openpyxl 处理大文件和海量空行时的严重卡死，我通过解析 zip 级 XML 绕开性能锁，实现了读取速度的跨越式提升。面对数据黑盒不能靠盲目硬跑，必须具备向下兼容、降维打击的解题能力。跑通单据流转只是业务工具的下限，压榨底层架构并彻底消灭操作门槛才是产品价值的上限。
|
|
## 二、对账工程化想法
|
|
在梳理财务对账工作流时，我意识到单次对账的成功不等于对账能力的沉淀。过去常关注“这版数据能否对齐”，但从工程化视角来看，高度依赖个人经验的“人肉核对”模式不仅是不可持续的消耗，更是系统潜藏的最大风险。
|
|
我将本次对账摸索出的判定标准、特定字段规则及抽样方法，彻底从个人经验中剥离，结构化输出为《财务数据校验方案》。为了避免文档沦为无人问津的归档件，我同步完成了实施工时评估并分阶段排定优先级。文档的终点必须是具备可执行、可度量特征的工程契约，这样才能确保沉淀直接进入后续迭代排期，成为统一的检验依据。
|
|
这次沉淀为后续的版本迭代和回归测试确立了一套完全可复用的标准动作。经验的口耳相传只会带来能力的递减，机制的白纸黑字才能实现能力的复利。标准流程的落地，彻底阻断了因人员流动导致对账能力归零的风险。说到底，个人经验的堆砌只是解决单点问题的下限，而系统标准的复用才是保障工程演进的上限。
|
|
## 三、取数规则重构
|
|
关键业务科目出现大面积且无规律的缺失，其根源并非某条规则配错的点状Bug，而是系统存在致命的结构性缺陷过度依赖物理位置进行绝对寻址。
|
|
我彻底推翻了“按列字母硬匹配”的脆弱逻辑，将涉及多个源表及列的取数机制，重构为“按表头列名”的动态匹配引擎。跟随物理布局的绝对定位注定脆弱，而锚定业务语义的解析赋予了系统极强的抗干扰韧性。现在只要列名代表的业务语义不变，取数逻辑就能够匹配上。
|
|
在重构期间，我克制了图快图省事、将“表头起始行号”直接写死在代码里的本能。与源数据结构强相关的元信息剥离至独立的外部配置表中。将变动的控制权彻底交还给配置层，是隔离技术债的关键。代码逻辑与配置数据能够解耦，未来的表结构变动均可交在配置表修改解决。代码能跑通只是凑合交付的下限，配置与引擎的彻底解耦才是系统长治久安的上限。 |