我转到智仓行业当前端的这 5 个月

各位 v 友们新年好呀，好久不见甚是想念。

从 9 月份入职新公司到现在只差一个月就要转正考核了，忙里忙外赶进度已经好久没有机会刷 v 站咯，年前有机会喘口气和大家分享一下见闻。因为很多东西在我这儿初步判断为是行业内的规则，所以不会像之前的蓝海那样直接爆出来，仅仅分享一下我在这个行业、公司里看到的不同于之前传统互联网前端的坑，供大家参考。（虽然一直没机会刷 v 站，但会时不时去 TimeFly 的"V2EX-苏州"微信群里吹吹水）。

1.藏代码

我这边听到的两位同期的后端新同事分享，仓储这块藏代码现象还挺多的，那种'教会徒弟饿死师傅'的理念比比皆是，正如徐浩峰《师父》里陈识看到的“大家都不想教真功夫”，我就只阐述我这边前端的情况了。
比较常见的，公司内部封装了一套前端基础组件框架，这块代码是我被允许看见的，不过有很局限的使用方式，与业务强相关。它使用了 pnpm-workspace 来将 packages 下的内容拆分成了多个项目，这些 packages 项目对我而言是完全不可见，也不可以被'师父'描述。我能看见的代码即我本地可运行的主程序代码，不同于生产环境中我被给予的主程序部署包，我还得针对部署后的问题修改我自己开发的 packages 插件。比如打包后主程序有个!important 修改了 antd 基础样式，我得给自己开发的东西基于主程序包再打个补丁。其他一些打包后主程序组件引用位置修改、冲突、使用方式变化啥的就自然比较多了。
'师父'呢，会教，但只是教组件独立出来是做什么的，只要花时间一般前端仔自己也可以看懂——暂且定义'师父'这边主程序+各个 package 组成了 [系统 B ] 。 [系统 B ] 中，大部分能看到的功能得对基础组件投入相当大的开发成本才能实现业务中的需求。甚至于一些关键功能，也被锁死在了别的 package 里，根本没集成到基础组件中。在此基础上，要遵依现有 [系统 B ] 的体验去'逆向'所见内容二开新功能。
然后呢，'师父'还会使辫子，不过我这边认为除开人的原因，可能是所属派系的身不由己行为，我会在第二章开讲。

2.派系斗争

假定我这边前端的'师父'是 n 派员工，即分公司 n ，我和两个后端新同事应该算 s 公司 s 派的。但充分了解现状后，发现我三其实是 s-n 派——即 s 派管理下学 n 的东西来做，自然会有“被用来架空 n 的嫌疑”，反正事实上也确实被 n 处处防着，而且 s 派里原本的 [系统 C ] 压根不给我们三碰(一个项目也没被允许开放)，相当于两边都不讨好了，属于是 s 管但转正考核还得 n 打。

我和新后端甲入职后“卧底”(调侃一下)到 n 公司坐了一个月冷板凳参加培训，出差前领导还大放厥词的说“培训完你们就能脱离 n 派独立开发啦”。事实上，实际的情况是各种推进一直在猛烈的被 n 卡脖子。n 那边确实很尽责的指导了 [系统 B ] 的使用以及一些示例业务描述，不过只是那种对于系统使用人员的训练标准。n 公司有更贴近开发者的一些描述文档，可惜对于 s-n 派是完全保密的。（有一次午间闲聊发生了差点没瞒住的情况，只能尴尬的转移话题，明确问出来了有）。前端这边，我被'师父'透露过，如果被发现擅自给了代码他那边要被追责。n 那边后端也是散装的，只有一个后端知道所有后端的总业务，别的都是各自开发各自的。

文章 1 提到的使绊子呢，一定情况下是因为我这边没有按照 [系统 B ] 以前的设计理念做二开，'师父'提出来的“不合理但必须实现的建议”闹出来种种返工和分歧。不过我开发的项目，拍板人是我的 s 派直属领导，所以'师父'那边现在基本也不好争执什么了。自然我也得做两边的兼容处理吧，而别的使绊子情况呢，就更有意思了。

[系统 B ] 的前身是 [系统 A ] ，在标准品范围内这是两个可以互相平替的系统。两年前，B 从 A 分出来后，各自进行了定制化迭代。组装那边的同事，是系统 A 的支持者，而且和 n 公司研发团队有浓浓的火药味（当然这是我们事后总结的，s 、n 两边的领导什么也没和我三说）。不知道是不是硬件同事故意提供给 n 派假的描述，'师父'给我们的假描述让我三去现场白忙活了好久。机缘巧合下，后端乙给出了他带来的新 mes 系统，现场的组装老大眼前一亮才和我们有了后来的细谈。谈完后发现是误解成我三是 n 派的了，直言到"不可能用 [系统 B ] "。

3.别的和传统互利网有区别的地方

套壳吧，我之前老东家蓝海里就有东西是套壳的，windows server 的服务器跑个破解版软件承担了 xx 业务。这个嘛，在我入职智仓后只能说，很多东西的实际实现，和宣发并不是一回事。不过我听那两个后端新同事讲，在非互联网行业还挺常见的，就是换牌那些。总之结果上而言大部分使用者看起来确实没必要知道真相，因为完全能用也能有售后的。开发者嘛，就有种《危楼愚夫》的味道(简单剧透一下，这电影就是讲主角根据专业知识算出来危楼随时会倒，上面人也知道，但是实际上就一直不倒，这样使用者就“不需要知道了”)。其他嘛，就是行业内专业术语门槛。比较明显的，“载具”这个词。游戏里面，载具一般就是用来驾驶的车辆。但是仓储里面呢，被运送的‘东西’，它抽象出来的概念，就是载具，诸如此类吧。再有的呢，系统里面效验的东西不能加太多，有些情况下是为了方便拓展，有些情况下就得兼容用户的”胡乱使用“——当然，也可以说成因为没有按规定使用。

更要求程序员会表演杂耍了，并不太看重怎么实现、能不能实现，更看重能不能早点做出能宣传的东西。

别的嘛，针对公司的抱怨提一嘴，分配给我的笔记本屏幕太小性能勉强够，申请的显示器怕不是转正后才有。至今 s 公司一直没有专属服务器，新项目的开发一直是前后端两个笔记本之间直接联调。

直属领导这边的特点是，最后一刻才会通知。不知道什么时候会通知我三搬到新办公地点 h 的消息，要是真搬的话，我就有个我自己能接受的正当理由跑了。我发现啊，那种有责任心的程序员吧(不是想捧高自己，问我自己有没有的话我自认为是有的)，为了按进度完成而拉满上班时间运转，最容易受 pua 破防。可能来自'师父'那边的 pua 是源于 n 老大的压力吧，不过确实在涉及到'有利益冲突'的工作领域上，'师父'完全是另一人了。