@ZGame 你会因为走路麻烦拒绝坐车吗？到达目的地不就行了，当然我可以告诉你车祸是世界上致死率最高的原因，你今天回家还是选择走路吗

@ZGame 有没有可能是你自己思想太固化？我在 Java 程序中使用策略模式，根据不同 JSON 路由到不同 bean 去执行，一样可以达到工作流的效果，实现各个流程互不干扰。

《因为原来麻烦 ,直接把工作流程就给干掉。。。》你每次反对的点为啥都这么奇葩？

@ZGame 遇到复杂 JSON ，十几个建表语句，一个表一千多个字段，你喜欢写你来给我慢慢写去吧，建好了还要调试字段长度（ postgresql ），关键最终入库又不需要考虑字段长度（ odps ）

@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 ，如果有也只能轮得到她吧，我还是想干个一两年的，环境不好找工作啊