背景：作者刚结束练习时长两月半的滴滴前端实习
序
时间过得真快，一下子就到了要找实习的时候了（互联网行业）。参考上一年互联网软件开发的惨状，我是时候得去拿一段实习经历保底了，总不能0实习去头铁冲秋招吧。
抱着忐忑紧张的心态，我打开了BOSS直骗app，投了一些简历。途中，我发现这么几点情况（2023年2月初）：
- 广深地区/长三角地区的web前端实习岗位较为稀少
- 很多岗位虽然开了但也仅仅只是开了，发岗位信息的BOSS全是半年前活跃（据说下架一个岗位也要付费）
最后投了北京的滴滴和百度，面着面着不想去北京的心情越来越强烈，我就把百度二面给拒了。但是emo之后就理智了，恰好滴滴过了，我就收拾好心情，做好相关的心理准备之后，就起身去北京挑战一下。
历
在滴滴实习的那段日子里，主要工作是滴滴司机部落app的新功能新页面的开发，主要使用weex1.0, Vue2这些比较老旧的技术。
内部还有一个thanos项目，里头滴滴的同事都喜欢将weex应用说成thanos应用（不知道是不是约定俗成，thanos就是weex）
不过，thanos只是一个集成了webpack loader和plugin如weex-vue-loader，mpx-loader等，然后在其上开发出自己的一套 Plugin Service Config 机制、以及生命周期的项目。大致的工作原理如下
Vue2/3 Code(You write) -> Thanos(Load & Compile) -> H5 or Weex or MPX APP Code(Generated)
虽然很多项目和框架都抱着这样的一个美好愿景：“一次书写，多端运行”
但是，现实是残酷的，这些框架或多或少会出现一些多端行为不一致的情况（如H5/小程序，如微信小程序/支付宝小程序/字节小程序，如安卓/iOS）。因此，在使用跨段框架开发应用的时候，就不要总是想着一口吃掉一个胖子，只拿着安卓机或iOS手机进行自测，然后写出所有代码。
在应用层进行多端差异抹平这一步是难以、甚至无法逾越的，很明显的例子就是：滴滴内部的跨端代码充斥着各种端判断并单独适配。这是我两个月写weex应用得出的观点。
有一天我问过我的mt：为什么滴滴选择了weex而不是React Native呢？他给出的回答是
选择一个框架并将其落地使用，需要考虑很多因素。因为选择后，很难跳车换框架重写。
从框架方面考虑，当时weex框架是经过了淘宝app的历练，他的性能和稳定性都是有目共睹的。
还要从人的角度考虑，weex使用vue，并且大多数业务的复杂度也没有非常高，再加上当时团队开发者的人均水平，选择了weex而不是React Native也是有道理的。
而实际呢。。。weex1停更了，并且在停更的时候，weex本身还有各种坑。还是像Flutter和React Native这种生态活跃的社区比较稳
于是，现在滴滴不得不预估多20-30%的开发时间来处理weex应用的坑🌚
除此之外，还体验到了一个需求从计划到上线的全流程，收获还是满满的。内部的工具做的也不错，至少没有出现什么致命的错误（又不是不能用.jpg）。
据我认识的同学/朋友说：滴滴的DX（开发者体验）是互联网大公司里头最舒服的了。
在我一番体验下来之后，确实感觉挺好的，但不一定最舒服（因为我只待过这一家公司），同事们也非常nice，每天工作挺融洽挺开心的。
终
时间过得好快，5月12就结束实习，15号就要坐飞机回广州了。下飞机的那一刻，能呼吸到湿润空气真的感觉，真是太舒服了（虽然半分钟不到头发就开始发油了。。。）
如果没有意外的话，接下来估计是去腾讯音乐那边实习了。我觉得挺好的，主要是地理位置就在深圳，离广州只需要的一小时不到的车程；负责的是QQ音乐业务。
其实大城市之间可以这么组合，公司在x而家在y，北京vs天津，上海vs杭州，深圳vs广州。滴滴实习的时候，有些同事家在天津而自己在北京工作，每周都能买张高铁票回家，真的不要太方便。