银行科技岗,真香吗?

作者 | 沉默王二

来源 | 沉默王二(ID:cmower)

去年的时候,有个研一的读者私信我这样一个问题,“二哥,我拿到了四个银行科技岗的 offer,该怎么选,希望能得到你的一些建议。”

他提供了很详细的信息,我简单的整理一下,大家看一看,也可以作为自己未来的参考。

普通本科,985 硕士,家里能提供二线的首付,单身,个人对技术的追求还行,没拿到互联网的 offer,能接受加班,但不想 996 那种。

工行西安开发中心,18-20 万,学长说加班多一些,但如果熬过去,后面熬成元老会比较舒服。

中行西安软件中心,第一年硕士 6K+,有高温补贴节日补贴上浮 1.5k,第一年大致 12W,第二年 18W,第三年普调有 20W,第四五年会涨到 30w。

中国邮政储蓄银行,有加班,20 出头。

浙商银行,base 杭州,27-30W,但加班会越来越多,比较忙,刚成立了子公司,后面等于互联网工作模式了。

具体的数字肯定不是很准确,但确实可以作为参考。大家也可以就这些信息作出一些个人的判断,然后在留言区给出自己的选择。

至于说我的建议和读者最后的选择(比较反转),先不公布,看完下面这段内容后再来公布。这段内容是我根据知乎上一个叫因是旧梦离人的朋友整理后的,他对“银行科技岗”的这个分析还是挺到位的。



银行科技岗大概分为两类。

一类是银行的信息科技岗,这种岗位一般在省分行,大多数不咋敲代码,算是甲方,工资和普通银行员工差不多,不高,比如说中国工商银行浙江省分行信息科技岗。

另外一类是敲代码的,即研发岗,例如上面提到的工行西安开发中心、中行西安软件中心等等。建行是自己的子公司建信金科,招行也是自己的子公司,招银网络科技。

这种银行的研发岗要求会高一些,待遇也还可以。中(国银行)农(业银行)工(商银行)建(设银行)交(通银行)邮(政储蓄银行)、招(商银)行、宁波银行、浦发(银行)、上海银行、这将农商行等这些大行都有研发岗位。

朋友选择加入某行(求证后是农行天研)的研发岗位之前,也有两个互联网巨头的总包 offer(40W+),但最后还是没去互联网公司。

其实无论是互联网 IT,还是银行 IT,只要是适合自己的,都是好的选择。

对于朋友来说,他在硕士期间患上了严重的焦虑症,很清楚自己不太适合互联网那种加班模式。读博吧,压力又太大,会让他更焦虑。军工所,钱少活多;公务员,他又不喜欢。最后,他还是希望能从事 IT 行业,所以他的目光在 2019 年就投向了银行科技岗。

首先,朋友对金融科技比较感兴趣;其次,银行的稳定性不错。

银行分为股份制银行和国有银行。像招行、浦发、宁波银行就属于股份制银行,稳定性不如国有银行。

从平台和金融科技发展来看,首选四大行和招商银行。据说招行的 IT 技术是银行里最好的,不过它的主要软件研发力量来源于子公司。招银网络科技,在深圳、杭州、成都都有分店,听说早上 8.30 上班,晚上 9 点 10 点才下班,比互联网公司还累。

朋友是在 20 年 6 月份参加的春招,在毕业前成功加入,现在快入职半年了。

优点就是(凡尔赛专用):

  • 工作体面,世界 500 强中的前 40 强,国有四大行之一的总行员工,英国《bank》排行前三;

  • 工作时间基本固定,朝九晚五,偶尔系统上线加加班;

  • 总行合同,工作基本稳定,没有中年危机,工资还行;

  • 所在城市的高考优势也不错,离家很近,1 小时高铁距离;

  • 团队氛围很好,领导也很 nice。

当然也有缺点:

  • 银行的技术一般,毕竟银行的首要任务是系统安全稳定,技术应用更加保守谨慎,对于有技术追求的人来说,不太适合;

  • 工资增长一般,想挣大钱是不可能的;

  • 大部分人都有天花板;

  • 时候也是要加班的,甚至不比互联网公司少。


如果学校背景好、技术好、身体好,建议去 BAT 字节等大厂。

如果背景好,家庭条件也不错,想追求稳定,对技术没啥追求,可以选择银行科技岗。

我整理了一份银行 IT 企业的名单。

  • 中国农业银行研发中心

  • 中国工商银行软件开发中心

  • 中国银行软件中心

  • 中国邮政储蓄银行软件开发中心

  • 中国交通银行软件开发中心

以上是国有银行的,下面是股份制银行的。

  • 招商银行信息科技岗

  • 招商银行信用卡中心

  • 浦发银行信息科技岗

  • 不全

看了这么多关于银行科技岗的分析,是不是觉得挺香的?那就再来看看我那个读者之前的选择(很反转),我估计大家绝壁想不到:

还是那句话,没有最好的选择,只有最适合自己的选择。


☞爱奇艺一程序员用 10 万元“买”了个北京户口
☞壕!阿里开工红包惊人,最高 1000 万,有人却只收到一杯白开水
☞谷歌称居家办公影响工作效率!2021 年将回归线下办公☞雷军坚持了 10 年的东西,现在彻底凉了
点分享点收藏点点赞点在看

<think>我们正在讨论Maven的properties中是否可以定义多个altReleaseDeploymentRepository属性。 根据之前的讨论,我们知道: - Maven的<properties>是一个键值对集合,同一个属性名只能出现一次,后出现的会覆盖先前的。 - 因此,在同一个<properties>标签内,不能定义多个同名的altReleaseDeploymentRepository。 但是,用户的问题可能是想知道是否可以通过某种方式在同一个pom.xml中配置多个altReleaseDeploymentRepository,以便在不同的情况下使用(比如不同环境)。 然而,altReleaseDeploymentRepository是一个全局属性,它只能指定一个仓库。所以即使我们通过其他方式(如profile)来定义多个,但在同一个构建中,最终生效的也只有一个。 但是,用户可能会想:我能否在同一个pom.xml中定义多个profile,每个profile里定义不同的altReleaseDeploymentRepository,然后根据不同的profile激活不同的仓库? 是的,这是可以的,但注意:在同一个构建中,激活的多个profile中如果都定义了同一个属性,那么后激活的profile中的属性会覆盖前面激活的。因此,我们通常不会同时激活多个定义了相同属性的profile。 所以,严格来说,在同一个<properties>元素下,不能有多个同名的altReleaseDeploymentRepository。但是可以通过多个profile来定义多个不同的altReleaseDeploymentRepository,并在构建时选择激活其中一个。 因此,回答用户问题:properties元素中不能同时存在多个altReleaseDeploymentRepository属性,因为属性名必须唯一。 下面我们组织回答: </think>### 关于 Maven properties 中多个 altReleaseDeploymentRepository 的说明 在 Maven 配置中,**properties 元素内不能同时存在多个同名属性**,这是由 Maven 的属性机制决定的: 1. **属性唯一性原则** `<properties>` 本质是键值对集合,同一属性名仅允许定义一次。重复定义时,后出现的属性会覆盖前者: ```xml <properties> <!-- 错误示例 --> <altReleaseDeploymentRepository>repo1::default::https://repo1.com</altReleaseDeploymentRepository> <altReleaseDeploymentRepository>repo2::default::https://repo2.com</altReleaseDeploymentRepository> <!-- 最终生效的是第二个定义 --> </properties> ``` 2. **替代解决方案(支持多仓库)** 若需多仓库部署,推荐以下方式: - **Profile 动态切换** 在不同 Profile 中配置独立仓库,通过 `-P` 参数激活: ```xml <profiles> <profile> <id>prod</id> <properties> <altReleaseDeploymentRepository>prod-repo::default::https://prod.com/releases</altReleaseDeploymentRepository> </properties> </profile> <profile> <id>test</id> <properties> <altReleaseDeploymentRepository>test-repo::default::https://test.com/releases</altReleaseDeploymentRepository> </properties> </profile> </profiles> ``` 部署命令:`mvn deploy -P prod`[^2] - **settings.xml 全局配置** 在全局配置中定义一次,所有项目共享: ```xml <!-- settings.xml --> <settings> <profiles> <profile> <id>global</id> <properties> <altReleaseDeploymentRepository>central::default::https://repo.corp.com/releases</altReleaseDeploymentRepository> </properties> </profile> </profiles> <activeProfiles> <activeProfile>global</activeProfile> </activeProfiles> </settings> ``` 此方式避免了每个项目重复配置[^1]。 3. ** distributionManagement 的差异** `altReleaseDeploymentRepository` 是全局覆盖属性(单一定义),而 `distributionManagement` 支持同时声明正式库和快照库: ```xml <!-- 合法多仓库配置 --> <distributionManagement> <repository> <id>release-repo</id> <url>https://example.com/release</url> </repository> <snapshotRepository> <id>snapshot-repo</id> <url>https://example.com/snapshot</url> </snapshotRepository> </distributionManagement> ``` ### 最佳实践建议 - **单项目多环境** → 使用 Profile 切换部署目标 - **企业级多项目** → 在 `settings.xml` 配置全局仓库[^1] - **复杂需求** → 通过 Nexus/Artifactory 创建虚拟仓库聚合多个物理仓库
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值