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

ZGame

2024-05-13 10:22:43 +08:00

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

Ashe007

2024-05-13 10:37:08 +08:00

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

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

Ashe007

2024-05-13 10:40:24 +08:00

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

fredweili

2024-05-13 10:56:14 +08:00

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

chuck1in

2024-05-13 11:11:38 +08:00

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

ZGame

2024-05-13 11:38:28 +08:00

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

ZGame

2024-05-13 11:40:23 +08:00

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

imokkkk

2024-05-13 13:18:26 +08:00

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

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

Ashe007

2024-05-13 13:41:05 +08:00

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

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

Ashe007

2024-05-13 13:47:50 +08:00

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

Ashe007

2024-05-13 13:52:41 +08:00

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

exmario

2024-05-13 14:38:27 +08:00

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

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

jipf9046522

2024-05-13 16:40:21 +08:00

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

hadesxiong

364 天前

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

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

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

Ashe007

364 天前

@hadesxiong 牛，概括的很全面。

Ashe007

364 天前

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

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

liuzhen

364 天前

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

Ashe007

364 天前

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

hadesxiong

363 天前

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