软件开发之背靠背的坑

        写了七八年代码，打了七八年卡，突然感觉上班枯燥乏味，感觉生活失去了意义。倒不是因为对自己专业的不认可，随着年龄的增大和项目与技术经验的积累，会有一种错觉，老板和业务部门简直是愚蠢透顶，开局一副好牌尽能打成如此稀巴烂!

        于是乎，飘了。

        在大众创业万众创新的背景下，联合几个同样是如此状态下的码农兄弟一起离职做公司，然后一步步掉入不见底的生坑。

        随后赶上了不知道多少年一遇的全球性疫情，原本以为是要顶不住了，没想到还是挺了过来，一路走来的坎坷一眼难尽。九零后本是个幸运的年龄，我们赶上了移动互联网的崛起，赶上了电商，赶上了O2O，赶上了百团大战，赶上了互联网金融，赶上了大数据，赶上了AI，赶上了元宇宙，后面能赶上的内容就未知了。回顾过去创业的几年，想把最艰难的那段项目经历和大家做个分享，希望能帮到有同等经历的人和正在经历同等境况的人。

        那是疫情爆发的前两年，创业以来虽然软包业务不断，但是都是小活，七八万，十五六万的合同价居多，此时阴差阳错朋友圈子中推过来一个JX国电的项目，简单聊了下感觉都是CRUD也没啥太过于复杂的东西，当时的感觉是捡到宝了，却不曾想恶梦才刚刚开始。

        合同的形式是背靠背，因为i以前做的项目小，周期短，在交付的环节最大的风险无非是一些业务设计缺陷或者建设过程中额外想起来的一些功能甲方希望也能给做进去，说到底无非是增加一周左右的人天投入，本身也是小项目，而且新增的需求站在运营方的角度的确也是客观需要的功能，一般我们都会做妥协，而且这类项目一般都会有二期三期，以维护客户关系为重的前提下，额外投入一些小的工作量也倒是无可厚非，最终要的是这类小项目甲方和开发方最多中间只隔了一层商务关系，即便是出现一些不可调和的工作，中间人对双方的情况会很清楚，多少会有一个双方都满意的这种办法，即便开发方略吃亏，也倒不是什么大的投入。然而如果一个项目合同背靠背的关系有四五层之多，产生的影响和前者相比则完全不是一个量级，当时我们接手的项目国网是最终客户，其中有一家国网控股的公司HZHY是一包，HZHY把合同中的两个系统又分别转包给了了HZZY和SHZS，HZZY和SHZS又把项目转包给了BJCX（一开始我也不明白为啥两个公司能把分包下来的项目转包给同一个公司，后来才发现是自己太年轻了），我们则是BJCX的下包方，项目的最终开发团队。

        项目的商务情况就是这样，虽然一开始就知道这个项目客户招标的价格肯定是一千多万，但是一千多万的项目并不代项目就真的值一千多万，一包拿到项目后去掉一个零，然后击鼓传花的方式往下传，直到这个过程无法继续，那也就意味着这条利益链上的最后一层几乎没有什么利润，然而要承担绝大多数的责任，即使如此，还有一堆人抢着参与，这才是最残酷的，相比较那些没有入围的同行，我们在那个时间节点算是幸运的，用他们的话说只要参与进去了，后面有的业务，现在想起来真的是太单纯了。

        项目的分工结构是这样，一包HZHY派出了一个项目经理和几个所谓的业务经理，负责把控项目全局，他们在国网业务领域参与的时间比较多，对于客户的业务流程和项目协调的确只能有他们来做；HZZY和ZJHY作为二包分别派出了两个人作为项目调研的产品经理，在一包的带领下分别对两个项目的需求进行调研，最终的产出PRD相关的东西；三包BJCX直接让作为四包的我方来代表，原则上整个项目团队不知道四包的存在，这就是最荒诞的地方。

        以上情况应该是国内中小企业的现状，只有通过这种方式才有饭吃，除非自己有政府或者国企顶层决策者的一手资源，除此之外通过单纯的招标，很难很难。

        一包和二包在三包（其实就是四包）入场前的三个月就开始驻场做前期的工作，三个月后我们也到了现场，所有的坑从合同签订的那一刻其实已经就埋下了伏笔，但是有很多公司在同等条件下就做的很好，所以假定合同没有问题，坑则是从开发环节逐步出现的。

        驻场的第一周，不管是几包的人，整体上大家都很融洽，主要是有一包的人给其他人传递一些关于国网特殊性质而需要做到保密的内容，如电脑只能用现场特定的电脑开发，不允许连外网，不允许在开发电脑上插数据线给手机充电之类的，早年做过铁路和石油的项目，这种要求倒是没什么好说的，郁闷的是后面的事。入场后主要两件事，一方面是跟一包二包对接需求的人尽快熟悉项目需求，另一方面是根据目前的需求尽快搭建项目开发脚手架，确保在需求了解差不多的时候，驻场的人员能尽快投入设计编码的环节，其实说穿了这类项目都是管理类的系统，从架构上来说真的没什么好设计的，按照我们平时的技术选型，类似开源的RuoYi跟Jeecg-Boot其实就完全能够应付，根本不需要特殊的东西。而此时一包蹦出来一个人，也算多少管点事，他大概传递了这样一个信息：国网的项目在上线前必须要通过电科院安全部门的测试，只有通过了这个测试，项目才能被允许在内网服务器上部署；其次，我们自己选型的框架未来估计很难通过此类测试，目前国网在主推自己的一套开发框架SG-UAP，它是一套完整的开发体系，从IDE到框架都有完整的工具与之对应，如果我们用这套东西来开发，那么后期测试被通过的几率会很大。

        个人对SG-UAP的总结如下，把eclipse做了一次轻量的封装，其实就是改了个图标，如果在windows电脑桌面按住ctrl转鼠标滚轮，会发现它会恢复成eclipse的图标，这个倒是没多大的影响；其次SG-UAP作为IDE里面继承了前后端开发的脚手架模板，后端的选型是SpringBoot1.X，前端则是UAP这个研发团队利用MVVC模型弄的一个类似VUE又不是VUE的这么个前端框架，说是前端框架，其实就提供了一些很基础很基础的UI样式，跟当时主流的Element UI和AndDesign相比完全不在一个Level。

        坑一：技术选型太盲目

        后期我曾不止一次对项目复盘，以上的这个坑很大程度上影响了后续的项目进度。事后发现，这个SG-UAP只是国网应对内网环境的一个工具，比如说IDEA和Maven很多的构建过程需要依赖外网，SG-UAP内置了Gradle，很多jar包的依赖都放在了国网内网的环境中，这样后端的构建在内网环境中就可以满足条件，另外主推的前端框架也是为了避免npm内网使用不了的问题而退出的解决方案。能用不代表好用，后端的先不说，当时处在前后端分离刚热起来不久的一个背景下，很多前端的组件比如日历控件，时间轴等，UAP都没有与之对应的生态，所以那个UAP只是一个推荐的选项，如果作为商用则隐患太多。

        当时如果我们选用RuoYi前后端分离的开源框架或者Jeecg-Boot的开源框架，其实在后期测试的时候一点问题都没有，到后来我们才知道，测试方人家只需要你把软件部署起来，他们用工具进行扫漏，他们根本不关注这个jar包是用什么工具构建的还是说这个jar包的开发环境用的是VSCode还是记事本，所以千万不要轻信现场那些各怀心思的人，他们推荐用一些奇怪的技术选型可能就是因为后期项目要移交到他们手里，因为他们长期处在这样一个封闭环境的岗位，对这种奇怪的工具比较熟，想在后期多掌握一些话语权罢了，然而他的一句话，却能让我们的开发团队耽误一个月，所以有些决定还是要梳理清楚，不要盲目的下判断。

        后面还有很多个坑，最近工作有点忙先聊到此。。。。。。

                                                                                                                                         未完待续