最近同事的一句话让我一直耿耿于怀，大伙帮忙分析下

[Ashe007]

我于去年底入职的银行金融项目 Java 开发岗位，同部门之前有两个干了三四年➕的老同事，加上我和另一个新同事共 4 人。 存在很多手动 shell ，Python 脚本流程解析非常复杂 JSON （对比我也构思出 Java 自动化递归解析方案，被否定，原因是出了问题谁负责？），工作交接基本没有，大部分都是安排工作遇到问题再给你讲。

我在遇到问题问老同事的时候，另一个老同事（女）就对我强调：上面对我们的要求都是中级开发巴拉巴拉……意思是我似乎不应该过于依赖他们啥的（不是第一次这样）

我个人看法时，工作流程没有任何文档，工作交接不存在任何系统性讲解，他们自己在讲问题时也可窥探出能力并不强，对这个💩山项目也是一直半解。又没人讲，遇到问题问一下还能被阴阳，我心理一直耿耿于怀每天看到她就想起她说的话，很不舒服

自我认知不是一个小气的人，但是她的话总是忘不了，而是每次工作分配，都是难度高的派给我，之前某个系统发版的热部署方案也就让我一个人来写，期间他们都是不闻不问，只关心进度，结果。我感觉这个热部署方案交给她写大概率她一个人写不出来。她们平时写的代码更是一言难尽，我看都不想看那种，警告满天飞

术业有专攻，闻到有先后。问个问题被这样阴阳，真是难以释怀，如果不是一起共事的同事也就罢了，关键她还坐我旁边，大家遇到这种情况怎么处理呢？

[ZGame]

@Ashe007 #60 ..... 假如说,现在出现问题了, 老的方案可以根据工作流的面板去查找报错原因,定位到哪个步骤。按你的方案,只要出现异常,全部就要崩溃了。还要翻 log 日志 ,我不觉得你的方案更好。

[Ashe007]

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

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

[Ashe007]

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

[fredweili]

别人没义务帮你，困难先要想自己克服，想要别人态度好一点就工作之外搞好关系

[chuck1in]

银行这种是这样的，他们应该是正式员工吧？

[ZGame]

@Ashe007 #63 我的意思是你做的这个活本身就是 etl 的事情, 老的方案是脚本推到工作流,而你说的方案只是实现的自动化具体一个脚本。 script 本身就不固定具体的语言实现方式(java or python).... 如果考虑到风险,检测一下历史 json 和当前 json 比对不就好了。 在根据新的 json 去生成工作流的样板代码。 这不比你直接把流程都给干了要好。。。
而且如果你觉得 etl 处理麻烦的话,应该考虑的是建立一个数据平台,类似 dlinky 那种,运用一下 java flink or 其他的技术栈,给其他人带来更好的体验。 而不是说因为原来麻烦 ,直接把工作流程就给干掉。。。

[ZGame]

@ZGame #66 数据治理的本身,本身就不应该只是便捷,还有数据溯源,和其他的一些管理

[imokkkk]

@Ashe007 #58 你说的也没错 可能工作久了 没这么足的干劲儿了 想要的就是少干点活 多摸会鱼 少点 oncall

说点可能不负责的实话 尤其是在自己明知道不会待太久的公司 对自己个人没多大提升的活 保证不出问题就行 不如空点时间多学点能提升自己的 哪怕是刷刷题 单纯为了以后面试

[Ashe007]

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

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

[Ashe007]

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

[Ashe007]

@ZGame 至于你说的数据溯源，原本就保存在一张表上，其他管理——不知道你想说个啥

[exmario]

银行 it 的核心从来都不是技术多 nb ，而是出了问题不背锅

你技术 nb 上天都没有意义的，只要有出问题的风险，那就不能动

[jipf9046522]

银行是这样的，只能靠自己熟悉。刚开始上手肯定是比较难搞，文档之类的几乎是没有的，只能靠问

[hadesxiong]

在相同的环境中呆过的人来给你补充个视角：
1. 大方向上，国内所有的金融行业的核心系统都是非常老旧的，目前系统迭代的方案基本就两个，要么就是核心系统功能前置到客户系统，要么就是走中台化，两个思路背后都是要把核心系统功能剥离掉；
2. 在 1 的基础上，结合国内金融行业的特殊情况，你可以留意下你们行内的开发流程和人员配置，讲不讲软件质量管理（当然我知道的大部分不讲，讲的也是有名无实），如果没有软件质量管理，什么都是瞎扯了；
3. 以我接触到的国内金融行业的科技部门，要么核心系统/功能/平台自研，非核心系统/功能/平台外包，要么就是行内员工负责设计（可能也就是讲个思路），外包负责开发落地；结合 2 ，你可以留意下具体留给开发人员的时间有多少，是否涉及频繁变更需求？是否有人做测试案例报告等等；

当然，以上这些都是我碰过的坑，如果这些侥幸你都没碰到，再从人际关系的角度去了解下：
1. 是不是你的收入和他们不一样？比如高了？
2. 是不是有派系/小团队斗争，这个你只能适应融入，没办法反抗；

这个环境下，并不是做事做对了就好的，如果说做事做好，技术过硬是 10 分的话，满分可能在 100 分左右，剩下 90 分其实非常。。玄学，你应该能明白这里面啥意思。

[Ashe007]

@hadesxiong 牛，概括的很全面。

[Ashe007]

@hadesxiong
1.目前是中台化。
2.几乎没有质量管理，程序能跑就行。
3.行内业务出需求，行内产品排期，外包开发。需求临时变更略显频繁，没有测试，自己测。

收入可能比他们高一点点，但是只对另一个新同事透露过。
派系斗争应该没有，毕竟我所在部门就 4 个人

[liuzhen]

银行 it 用的通常都考虑稳定第一，有的项目还在用 jdk1.5 你想想，"出了问题谁负责"站在她的立场没毛病，都是老油条只想混口饭吃，互相理解，这种环境靠你应该很难改变，只能适应，或者跑路

[Ashe007]

@liuzhen 是的，暂时只有适应环境。想开了就不在意了

[hadesxiong]

@Ashe007 所以这个问题基本无解，技术实践不是那么好实践的，有些同学在找工作的时候非常在意的就是平台，当然在意平台的并不只是平台足够大，而是要平台提供足够的实践机会以及平台自身的运转需要正常。可是国内的传统金融行业，从银行到保险再到券商，全都是一副 d 样，且不说你今天只是个中级/高级/资深开发，哪怕把你们行科技部老总这个位置给你，你依然解决不了这些问题。再一言以蔽之，你所在的部门之于银行就是个成本部门，成本部门想改变流程和规范（公司层面），基本是不可能。