@kinghui 没人要求我在家也基本坐着

朋友在南山学的感觉教练很不靠谱，很糊弄。其实上手在换刃前都可以自己学，教练教的和网上看的不会有什么区别。学换刃和去中级道的时候可以再请教练

我就是理发阳的

不是毕业人均大厂，而是大厂就是有这么多前端的坑啊，总有人拿的到 offer 。能到毕业 35w 上下这个水平的前端感觉应该在 4 位数人吧。晋升一波跳槽一波，基本就是你说的数了。

取决于在不在给的冒烟 case 中吧，如果小需求小优化不给冒烟 case ，那肯定算提测成功，当 bug 解。
如果大需求不给冒烟 case ，那是测试有问题。
如果给了冒烟 case ，但不包括这个问题，那只要冒烟 case 都过了就提测成功吧

互联网，好忙。。

@maobukui 然而市场上大部分公司其实都差的不多，很少有你说的差距那么大，如果都像你说的差距那么大的话，那肯定选现金了。现实是大部分都是 4 个月上下，差距不大，或者 30*12 和 25*16 这种差距

为什么还在这干，如果我是你，到你写的第二条第三条的时候肯定早就走人了

@zqlcrow 有没有可能，大公司不通过 bug 数考核。。。

@caicaiwoshishui 市场大很难定义。个人感觉，做硬件的，达到你描述的场景，roi 太低了，真做成你这样，要定什么价格，卖多少钱，又能卖几台呢？我咋感觉市场挺小的

@tool2d 自愧不如，这个主要还是看公司，其实只要能校招进一线公司字节快手阿里美团，最普通的前端也是 25k ，大家真没几个做你说的这种高要求的事儿的

你就算看官方文档，都整明白了，也改变不了目前找不到工作的现状吧。这已经不是五六年前了，没经验的做做 demo 就能转前端的日子早过去了

@yaphets666 我的重点在于，多方合作，逻辑复杂，我这种情况根本是不可能融合到一个系统中的，融合到一个系统只会越来越难维护。换一个负责人就再也不会知道前面的逻辑到底是什么情况了

@yaphets666 这不是你说的情况，老项目其实只是其中很小一部分，小于 15%。需要做的主要是接新项目

@RealJacob @yaphets666

btw ，在我的场景里，20 个业务方还是往少了说，感觉算上写老系统的 rd 的话，历史上前前后后需要参与的 rd 应该是大于 100 人的，这里仅说 rd ，不算 pm 、qa 等。

@yaphets666 只是举个例子，可能略有夸张了。但我确实实际遇到过类似的情况，我就是那个基座。一个需要兼容老系统，新系统，n 多业务方的系统。
你要说 iframe 能做吧，也能，但需要砍掉非常多需求。目前的情况个人感觉是一个微前端不错的实践，我觉得是有用的

@Envov
1. 和技术栈无关，那就是各个微前端方案要解决的问题。你可以理解为 iframe 也是一种微前端，主应用和子应用是技术栈无关的
2. 微前端加载和发包的区别，无需主应用发版。生产环境的子应用在经过测试后，可以直接发，不通过主应用。而发包不行。而发包也比较难避免“技术栈无关”这件事，react 项目怎么用 vue 包，反之亦然。（当然是有解决方案的，但也是有成本的，并且需要对当前项目有侵入性改动的）
3. 我理解子应用不影响主应用修复漏洞只是其中一个小的场景，还是有其他场景会用得到的

@yaphets666 你这不就是另一个需求了么，事实上没办法所有情况都有一个基座去做“一套”系统，如果只有两个业务方可能 ok ，那如果有二十个业务方需要协同开发呢？如何做到一个系统里？每个系统可能又是非常复杂庞大的，逻辑也都是不一样的，做到一起的话后续的维护如何维护？很显然是没法像你想的那样简单