@ZGame 我不需要你认为哪个方案更好，如果说你喜欢工作量与 JSON 结构复杂度成正比，你用就是了。根据工作流面板定位错误和看日志定位错误，我不认为哪一个更具有明显优势。

你的发言从始至终表露出一种自我带入，首先给我扣一顶 Java 能做 Python 不能做的帽子，然后说 Java 很难排查问题，现在又直接说有问题全部崩溃。没有测试环境吗？没有异常处理吗？

@ZGame Java 也有日志帮助排查问题啊，感觉你总是在强调 Java 能做的 Python 也能做，我也没说 Python 不能做，我否定的是现有的方案设计太麻烦（如果你非要争个语言优劣的话，就此打住）

@imokkkk 是没毛病，但若事事以此为准则，大家都会因害怕担责而拒绝改变，甚至不敢尝试新东西，从而落后于时代

@superliy 必不可能，我不是那种性格，谁足够优秀自然得到我的尊重，即便是很优秀的人我也不会随便舔，合得来才会走得近

@xjngbla 离谱的是，招人新手不要，入职培训不教，工作流程文档没有。
金融项目还必须要求面试者有金融项目经验，游戏项目要求面试者必须有游戏项目经验。着实难理解……

@Ashe007 现有方案存在很多冗余操作比如最终目标表是 odps （支持可伸缩字段长度），然而其设计先解构至 postgresql （需要考虑社交设计表的字段长度是否适合当前 JSON 的 key 对应 value 内容长度），再将 postgresql 表的内容同步至 odps

@ZGame 现有的方案是，每对应一个 JSON 解构，都是一套新的程序流程，各个地方都需要更改

@ZGame 不是纯 Python 处理，结合 shell 脚本一起执行。当 JSON 结构发生变化，很多文件都需要手动编辑，再整合到 azkaban 定时任务去执行。

我不是说 Python 不行，而是现使用的方案设计太低级，我自己是 Java 程序员，因此选择用熟悉的 Java 实现自动递归解析，当 JSON 结构变化也可实现程序自动解构 JSON ，自动创建表并自动插入数据

@haikea 新奇的角度，这样想她也城府太深了

@Meteora626 外包，我关注的核心不是文档，而是同事之间的态度和关系，以及如何处理问题的方式。至于银行本部（开发和业务），都是有锅都往外包身上推（听老同事的吐槽，该岗位未亲身经历），之前干的一份外包也是——干最多的活担最多的责（产品需求都没搞清楚就让我开发，做出来业务说不对，然后我来加班加点改，最后项目奖金是本部项目部瓜分的，几个月累计 bug 量来扣我一个月绩效考核，而是很多 bug 还是之前负责开发的人制造，只是由我接手来改），太难了

@jvee 这类项目通常包含：传家宝代码🤣祖传 bug😅加密编程😆

@jvee 很多人很多时候第一考虑就是，出了问题谁来负责，如何推卸责任。不知道是不是银行独有的工作氛围……

@jvee 这倒是事实，代码质量根本没有。重视的是业务稳定性和拒绝担责，因此甩锅很常见🤪

@duange7X24 嗯嗯，感谢老哥理解

@Ashe007 也可能她的初衷不是阴阳恶心咱，而是期望我能展现出更多独立分析问题的能力，或许真的是我自己想多了

@yasumi 晋升是不可能的哦，银行金融项目有很多系统，基本都是一个部门负责某个领域的几个固定 project ，如果有也只能轮得到她吧，我还是想干个一两年的，环境不好找工作啊

@duange7X24 不想撕破脸，并不是她没有帮我，而是我在问其他同事问题的时候她来恶心我（应该不是无意，因为不是第一次这样），让我不舒服。嗐，真不知该怎么做才能摆脱心里的膈应

@phrack Python 方案具体实现很废人力和时间，设计的有问题，每变一个 JSON 结构都要改很多东西

@an0nym0u5u5er Python 解析的方案需要手动改很多文件啊，改成 Java 递归子层级 key-value 的方式可以实现自动化解析，注意递归深度，从理论上完全可行，我也起草过 Demo 实现了。
因为害怕担责拒绝更好更有效率的方案，造成的结果不是在拒绝进步吗？银行业务确实需要稳定优先，但事事都是这种理念作为决策基准（懵），才导致很多银行系统老牛拉破车的现状

至于你说的领导抬头看天，找正确的道路，我只看到两个老同事有空就玩手机看小说（他们就坐我旁边）