2024了为什么银行业还是屎山代码

        我们经常说银行的代码是屎山代码，一帮子搞金融科技的人才拿着上万的工资写出来这么拉胯的系统，被业内程序猿们狠狠嘲笑。在我干这行之前我也是这么看的，干了两年之后我也笑不出来了，今天来说说银行的屎山代码怎么来的。

        在我看来其实并不是银行的所有系统都是屎山代码。

        银行的系统一般按各职能部门需求划分，有各自的独立系统（要是这点都拎不清这个银行算是完蛋了）。像渠道科室有渠道系统，例如App、小程序、微信公众号、智能柜台等，客服部门有客服系统，例如短信平台、远程面签系统等，信贷审批、风险管理等等部门也有各自的系统。当然这些系统都归信息科技部门管理，项目集也是有顶层设计的，信息系统间要如何交互，会有专门的技术经理负责评估，各系统间的相互配合使得贷款从客户申请、审批、发放如同工厂流水线一般发放到客户手中。

        有这么多系统，职能也分得清楚，那就不能说所有系统都是垃圾。像一些部门内的只负责CRUD配置的独立系统，其实也是简单明了的，那么哪些系统才是真正让人头疼的？

        在我看来一种是充斥着大量个性化需求的系统。这类系统往往在N轮迭代后出现公共组件无法复用的情况。以一个人脸识别组件为例，客户端调用人脸服务，返回识别结果，封装一下组件交付页面调用就完事了，需求A可能会要求最多识别3次，如果低于80分就不通过，3次不过之后要做xxx交互，这时候组件是完全满足需求的，但是后来来了需求B，低于90分就不通过，还要换个页面标题，需求C要做埋点、需求D要做统计……以此类推，长此以往，开发人员在看某个需求场景的垂直业务代码逻辑的时候就会发现中间夹杂着这样那样的噪音，不得不感叹一句：什么屎山代码！

        有朋友可能会说了，这没什么呀，组件本来就是要预先设计考虑各种场景的，要做参数化配置。诚然，组件设计是要有一定的前瞻性，但是往往只能满足80%的功能性需求，无法覆盖全部个性化需求的应用场景，有些需求则是直接表述为直接复用xx页面的功能，在该页面基础上增加或减少ABCD功能，这就迫使工程师在开发需求时增加各种防御性编程的代码，大量的if-else看的眼花缭乱，而这类需求也是导致页面或接口服务在日常迭代维护中愈发臃肿的重要因素。

        那是不是可以将这类组件或页面通过提取公共组件的方式再提炼一下？这显然高级一点，但是现实往往受限于几种因素：

        一是提炼组件往往需要更多的工时完成，而这要求项目组提供更多的成本完成同样的需求，而项目如果要求在指定日期前完成，没有更多的时间让你做优化工作，则会形成技术债务，这是技术与项目进度之间的矛盾。

        二是提炼组件则会涉及改动原有的功能，需要进行回归测试，试想一下，为了提炼这个组件需要回归十几个用到该组件的业务流程，费时费力，这是一件多么糟糕的事情，领导批不批这个事情都要打个大大的问号。

        三是如果改出问题来那么谁来承担这个责任？开发人员轻则通报批评，重则记大过、连带测试人员罚钱甚至卷铺走人；业务只想要稳定，他们不看长远的东西，才不管代码屎不屎，做开发的就要确保系统正常运行是他们的观念，你私自改了代码那对不起，我没提过这个需求。

        考虑以上种种因素，工程师一般都会选择尽量不要动以前的代码，宁愿CV大法重新建个组件，毕竟功夫再高，也怕菜刀，你在代码里面看到有很多类似的代码也就不觉得奇怪了。

         代码质量的另外一个重要的因素则是外包。银行的系统开发人员一般由行员、人力外包、项目外包组成，行员一般技术经理居多，负责需求评估及技术评估；人力外包顾名思义就是行方跟第三方人力资源公司签订合同派遣劳务人员过来上班，中级工程师居多，鱼龙混杂；项目外包则是将一整个项目打包给第三方公司全权负责开发了，这类项目要么是不重要的项目直接外包出去，要么就是行方受限于自身的技术储备、技术水平或设备要求等因素，只能将系统外包给金融科技公司。在我看来，这些人员的技术水平往往是行员一般会优于外包人员，外包人员优于项目外包人员。外包人员受行员监督，代码审查知根知底，但是外包人员晋升难度高，最多干几年就跑，能指望他们写的代码多有前瞻性？而对于项目外包人员，行员是管不了的，代码并不托管在行方这边。从生产的故障率来看，项目外包要比人力外包要高，我甚至见过行员对接项目外包崩溃到寻求降低生产故障率的技术方案时，即使责任由他承担也要尽可能避免项目外包带来的生产故障概率。等这类项目回迁到行内后，你看到的将会是一坨屎，而这背后的道理不难想通：项目外包公司为了尽可能获得更高的利润选择中级+初级工程师的方案，他们背靠的是自身强大的技术储备或安全能力、运维能力，人并不是他们的核心要素，只是工具，这些工具人只需要在项目外包公司强大的基础上做些CRUD的工作就可以了，开发出来的系统质量能指望有多高呢？

        剩下的一些因素我觉得都是一些次要的因素了。有些代码看似没有用到，实则是为上游系统服务，这些代码由于缺失维护文档或注释，让接手的人摸不着头脑；代码审查的形式主义也会导致系统维护越来越困难。

        总结来说，时代在变化，过去工程质量不行可能单纯是因为IT人才不多没得选，随着技术的发展，技术人员的工程技术水平也不断提高，与此同时信息化系统的建设需求也不断增加，在银行业同质化严重的背景下催生了大量的个性化需求，这也要求工程师要有更高的水平来建设系统，而这并不单独依赖工程师的能力，更需要业务人员、项目管理人员、需求人员、技术人员多方共同配合才能做得更好，至于要怎样才能做得更好，希望我的观点可以为各位看官提供一些参考意见。