从2016年开始，从传统外企进入互联网行业，一直抱着一颗创业的心。然而阴错阳差，互联网环境学历歧视和年龄歧视非常严重，最后只能去一些E轮以上的厂里当大头兵。当然也幸得朋友看的起，在工作之余给数家公司做技术顾问，也有幸承包了几个项目赚了不少外块得以安享晚年。虽然最终企业黄的黄散的散。但是在国内互联网行业，被技术所困却是一件稀疏平常的事情。下面我就来给大家讲一讲我这八年来给小微公司和创业公司做技术顾问和在北京看到的事情。
其实懒得吐槽，只是缘起最近2年的经历
在今年6月初我和朋友启动了一个项目，这个项目其实很简单，加起来十个页面，一个应用层后端20几个接口和一个RAG模块。人员配置典型的一个老板，一个产品，一个设计，两个开发加我。几乎每个初创公司都是这么起步的。技术栈的选择，前端选团队比较熟悉的Vue3，而后端因为整个团队一直做AI大模型相关产品，所以理所当然的选择了Python。而且由于需要使用RAG，也就顺理成章只能使用Python了。
但是好景不长，因为团队其他人介入时间比较晚。我就提前介入做了很多页面。把所有UI页面都搞完了，后来由于身体原因等其他2人有空了交给他们继续做。但是逐渐问题暴露了。功能的完成度极其差，主要体现在功能实现完成度不高，UI还原度不高，这也是团队之前在其它产品上暴露过的问题。所以为了做出更好的用户体验的产品，我再一次加入开发，但是发现代码很难改，一个是后端PY我并不熟悉，哪怕是应用层，一个环境问题搞了我好几天没搞定，再者前端同学按自己的习惯把代码改的面目全非，加上一些自己封装的库和一些独特的写法，虽然代码结构和代码写法看上去很清晰，对于我的学习成本成倍增加。
最主要原因是前端自己写了一套状态管理库，而这套库只是单纯的一个内存实例，每个页面要操作这个对象来同步数据。这下子尴尬了。我发现很多功能的奇怪体验的问题也是原至于此，状态凌乱了。但是在和那个前端沟通的时候，他觉得pinia写起来太复杂了。不如他这个简便。这也就引出了小微公司和初创公司的第一个技术问题 -- 重复造轮子。
重复造轮子之“自己写的也实现了一样的功能”
很多小公司和初创公司的前端特别爱自己造轮子。并且乐此不疲。之前面试别人的时候就经常遇到自称架构师的，然后主要负责维护公司自己的组件库，抽象公共组件，写一个api 框架，封装一套新的RPC库，CLI工具等。
我不能说小公司造轮子不对，毕竟有一些时候，我们确实需要自己突破一些技术瓶颈。比如我就曾经被要求过需要在一个Canvas拓补图中需要同时展示500个以上元素，而市面上普遍的库只能画200多个元素，1G的数据处理时长要在12s以内这种变态要求，而市面上成熟的技术都无法实现，使用Hadoop需要8分钟左右。
但是如果市面上已经存在了相同或者类似并且非常著名的库，你何苦还要自己搞呢？最常见的就是，不管公司大小，自己搞一套CLI，自己搞一个UI库，自己封装一套Nodejs后端框架，自己搞一套打包工具，虽然也是拿别人的代码来改一改。包括大厂也是这么干，甚至还有那种连注释都不删拿出去开源的也常见。
但是对于小微企业，初创公司，他们面临的技术问题是什么？是能够帮助企业活下来的技术，简而言之从技术层面来看，就是能够以较低的研发成本支撑公司产品快速迭代，快速产品试错。
而小公司，初创公司资金非常有限，人员能力也有限，所以每一分钱都要花在刀刃上。这个时候，不合时宜的造轮子往往会带来很多隐性成本。比如我之前那个项目就是，我后期加入因为框架适应性问题导致生产性大打折扣。
何为隐性成本？前面提到的就是一个例子，他自己搞了一套状态管理库，但是并不具备响应式能力，而状态逻辑，业务逻辑就都只能写在组件内部。并且UI和业务状态的同步就需要自己一点点实现，那么就很难保证每一个组件关联的状态都能保持同步。同时，这种创新的开发模式又缺乏文档，也会让其他人使用成本上升。那么，适应成本和维护成本就只能团队自己内部消化，甚至影响到某些交互的实现还要倒逼产品妥协，目前我们这个团队就是，最终落地的东西产品预期总是有很大偏差。
当然技术同学会说：功能不是实现了吗，这么用不能用么？这就是小公司技术怼产品经常看到的画面。确实对于小公司，他们没有完备的ABTest系统和业务指标来监控产品转化率，用户满意度。所以很难量化度量这些影响。
在一些成熟的公司。产品是绝对不能接受这种妥协的。尤其阿里，虽然阿里给外界的印象是技术氛围浓厚，但其实内部业务人员话语权非常大，他们要的功能，需要实现的交互，你就要完成。完不成就投诉你。年底你就得背325滚蛋。而对于toB，toG类交付项目，如果你做的不好，那么随之而来的就是回款难题，以及一锤子买卖，以后就很难再次合作了，更不会介绍身边的客户给你。对于初创公司获客是非常艰难的事情。
我们要技术驱动？
还记得3，4年前，一个小同学来问我，说他们公司有一个架构师，自己搞了一个框架，能跨端，然后其他人开发用起来特别费劲，还要经常让他改框架代码才能实现功能，搞得好麻烦。但是他们项目要一个月内上线，怎么办？
我只问了几个问题：
- 你们需要跨端么？
- taro和uniapp不行么？RN不可以么？
- 你们需要有多个工程使用么？
得到的回答都是否，那么为啥这么做呢？于是我就建议他直接小程序原生搞吧，蛮简单的。但是得到的他们架构师的回复是小程序原生非常难用，各种坑如此云云。
其实每一个轮子创造者都是这套说辞。但是他们搞得东西就比小程序原生好用么？mpvue，mpx，卡梅伦等等等等就好用吗？如果非要选一个跨端框架来用的话，我宁愿选择taro。原因很简单：JD一直在用，一直有一个稳定的团队在维护。可以给研发过程减少非常多的麻烦，何乐而不为呢，更何况你自己搞还要抽一部分人力去维护它，这个人力成本谁来出？而小公司一般都是这个人自己维护，换个人都搞不明白，或者短时间内都没办法顺利接手，那一旦这个人离职了怎么办？
我曾经遇到一个团队，老板为了留住一个人，给了这个人2倍其他人的工资，只是因为团队很多模块都是他封装的，又没有文档，学习成本又高，其他人没法接手,让他理所应当的成为了公司里面的"技术大神"。这种隐性成本在很多初创公司非常常见。而因此导致技术团队离职率上升的时候，老板更愿意相信是小公司对人才吸引力差，留不住人。
但是换句话说，谁都是打工人，同样工资不高，公司也不咋地，谁愿意一直在屎山上堆屎山呢？可能有人会问，那你把他重构了好了。这就是很有意思的事情了。说的简单，做起来就很难了。先不谈你需要面临对方的各种刁难，还有这个时间谁来给你，人家的东西已经占据先机了，你后来居上谈何容易。除非他离职走了，即使离职走了，在小公司也未必会给你时间去折腾，相反，你支持不好业务，老板反而会怪罪你能力不行，甚至因为这个哪怕出一点点小问题都会小题大做，这都是血的教训。
我们不重复造轮子，我们使用最新，最牛逼的技术
当Flutter刚刚出来的时候，所带来的技术特性让人为之疯狂，无数新产品都开始选择Flutter进行开发。然而，单单我在北京接触的创业公司，就死伤一片，最可气的是，客户端负责人挖完坑就借着Flutter这股春风拿高薪跑了。留下一地鸡毛和凌乱的老板。之后怎么办？只能加钱招人，因为Flutter技术比较新，市场上人少，大家都要Flutter。也就供不应求，带来的后果就是社会招聘成本上升，而一波人不断的借着Flutter这股技术风不断抬高自己的身价。
一些小的团队技术Leader苦不堪言，只能吐槽一句Flutter技术很坑。但是Flutter坑么？并不坑，只是这门技术从公司技术团队角度来讲，并不适合技术积累薄弱并且需要为了公司生存玩命的初创公司，它的使用门槛并没有看上去那么低。当然没有哪个TL会承认自己的技术团队水平差。
即使现在也还有一些团队因为在使用Flutter无法攻克一些技术难题，只能加钱招所谓的更牛逼的Flutter专家来解决问题。而此时想回头更难了，花费的成本会更高，所以只能硬着头皮继续走下去。
客户端和后端差距非常大，客户端需要受各种客户设备，发版，技术栈更替成本高等因素影响,所以在客户端前端这里更换技术栈是一件非常痛苦的事情，需要契机，并且还需要快，对于团队是一个非常不小的挑战，而后端只是简单的重启一个新项目，把原来接口替换掉即可完成技术的更替。所以往往客户端，前端折腾散的团队更多。而且一旦欠下技术债就很难短时间或者依靠一两个人扭转。费工费力又费时。对于小微公司和初创公司来讲是非常大的重创。
技术驱动？产品驱动？
在北京工作那段时间，其实大家都是打工人，公司发展好坏跟我何干？钱都被老板赚走了，给我多少钱？几乎每个小公司的基层技术人员都是这种心态。所以也就导致员工忠诚度很低。留烂摊子是很常见的。做的功x能能糊弄上可以用就很不错了。
对于初创公司，自己打造产品的公司，做到这种程度显然是不行的。他会让公司由于隐性成本的上升一步一步的失去竞争力。那么如何扭转这种局面呢？这就面临到底是技术驱动还是产品驱动的问题。
之前做过一个弹出屏播放动画的需求，我对这个需求本身就是非常抵触的，老板让干啥我就糊弄上就完事了，而后来也验证了我的猜测，上线后通过监控97%都在初始化的时候就失败了，而成功播放只有1%多一点点。但是这件事实现了一个技术突破，别人做过的实现方式我们做到了，属于技术创新。但是这种行为在小公司是根本行不通的。因为一个线上根本就无法正常使用的功能上线，哪怕对用户没影响，但是浪费的工时，完全可以去做更有价值的事情。
所以，我自己经常招一些外包团队帮我驻场开发项目。我只验收功能保证我的项目能正常交付拿回来钱，至于代码多烂，技术栈多落后我根本不管。
很多小朋友认为用新技术，造轮子就是产品驱动，所以不让造轮子就离职，造的轮子不让上就离职，不让用新技术就离职。这在北京特别普遍。所以有时候也是为了留住人，吸引人才不得不采用一些新技术。这些成本是值得的。对于公司，重新招人成本更高，如果可以通过这种方式留住人，也是非常不错的。
但是凡事都要有度，要控制好这个度，我就遇到过一次团队要搞组件库，其实就是把别人的组件库拿来改一改样式把author换成自己。然后就让大家去换掉原有的库。
最终这个事是做了，也完成了，并且负责这个UI库的小朋友还晋升了，虽然大部分复杂的东西都是其它人做的。这在大公司很普遍存在。但是，这件事花费了4，5个人月，而这套UI库也就一个项目在用。所以这就是纯纯的KPI项目帮人晋升的。大公司可以搞,也经常这么搞，因为大公司营收非常稳定，本身就允许存在大量的人员冗余，而冗余的人你也不能让他天天没事干吧？所以找点事也还好。
但是小公司，初创公司生存都是问题，资金也非常有限，你这么搞，就离死不远了。不如把这部分人力投入到产品打磨上去，对公司未来的生存还能带来一线生机。甚至把这个钱拿去抖音，快手，百度，google买一些流量打一些广告至少还能带来一些产品曝光，还有一些增长。
公司三部曲；活下来，活得好，活得酷
在我经历这么多年，公司都要经历这三步：活下来，活得好，活得酷。而活下来是最难的。企业为了活下来，就要不断的找钱，而钱无非几个途径：融资，老板，营收。
在2018年以前，大量的资本养活了互联网，让互联网企业不需要考虑营收问题，大家很容易拿到大笔的融资来烧，所以产研团队的投入更是每个互联网公司最大的成本开销。但是在18年之后，资本收紧，很难再拿到钱，而这时候，如果还不转换思维务实，就很难生存。很多公司开始开源节流，去肥增瘦。但是最后呢？只是中层干部把自己嫡系之外的人干掉了。换个脑子想一想吗，不是嫡系谁有空去造轮子，天天被业务都压死了，哪有时间去扯犊子。但是最后被裁的却都是这帮给公司做业务的人。
所以，很多公司各种去肥增瘦并没有除了账面上的数字符合预期之外，并没有取得什么良好效果。典型的就是某讯，某讯很多部门这两年都在折腾折腾，各个老板通过各种折腾重构来证明自己的价值。搞得鸡飞狗跳。
反观阿里却非常聪明，在22年前后一众业界知名大咖相继离职。而深入了解后发现，这些大咖都是在阿里重点搞技术产出和业界影响力的人。至于对阿里的业务价值，我一个外人不好评价，但是，每一个主动离开和被动离开的人都是有原因的,这也验证了阿里老板的那句话，给社会输出高端人才，反而不高端的阿里留着自己用，此事必有蹊跷就是了。
所以大厂尚且如此，作为小微企业，初创公司呢？在资本寒冬的大背景下就更禁不起折腾了。“务实”是当务之急。技术只不过是一个工具罢了。是帮助企业完成产品生产的工具而已。顺手就行了，可以很好的提升生产力才是第一要务。工具再牛逼，你用不明白，用不好，导致生产力下降，那不如不用。
而反观阿里早期就是买一套php商城代码就开始干了，滴滴早期还是找的外包做的一个app。而现在的初创公司呢？上来就要一众985，211，top100 海龟，毕业就在大厂的精英，可谓王炸开局，结果呢？即使在2018年以前市场好的时候，活过2年的又有多少？
当然，老板有钱真的无所谓。只是从我个人经历来看，这么搞的最后活下来的屈指可数，老板也有玩腻的一天，看看熊猫直播就知道了。
作为初创公司和小微公司，活下来才是第一要务。想活下来就要每一分钱都要花在刀刃上。
互联网行业的“阿里味”与“百度背景”
国内的互联网行业为整个社会创造了众多机遇。其中，阿里、腾讯、百度等知名互联网公司最为显著，它们吸引了大量人才投身其中。特别是阿里和百度，他们的企业文化和技术影响力在整个互联网行业有着显著地位。
阿里的企业文化被外界称为“阿里味”，这一称呼我个人觉得并不具有贬义。阿里的成功证明了其企业文化的重要性。然而，这种企业文化在小型和初创公司中可能并不适用，所以很难被其它公司所接受或在那里获得成功。
与此相反，百度被誉为互联网界的“黄埔军校”，许多知名互联网公司的核心人员和中层领导都具有百度背景。这也从侧面反映了百度企业文化和人才策略对于互联网行业的影响。我自己在北京的合作经历也证明，来自百度背景的同事和领导合作起来也更舒服。因为百度系的老板更注重业务，更注重ROI，而业务才是公司的立足之本。
完结
好了，牢骚发完了，我只是一个因身体原因提前退休的老码农。奉劝大家：别折腾啦。那玩意把公司折腾黄了，现在找工作多难啊。是不？更何况一点身体折腾废了，钱又没赚到。那不更可惜。
切忌切忌。踏踏实实做事才是根本。
