TL日日谈:小程序框架/关于打C/智能开发/埋点

小程序跨平台框架


小爝:我最近要开始做各个平台的小程序了,业务量很大,有个比较头大问题是想要选个合适的跨平台框架。我们技术栈是vue的,内部有一套需要适配的HB方案,很想知道大家都用的什么框架?


七嘴八舌话框架


uni-app:需要更多原生开发,地图业务慎用,vue技术栈适用

Let it Go:如果有地图相关业务或者用到cover-view的话,慎用uni-app。

Andy:我们试过uni-app,感觉还是需要很多的原生开发。好几个项目最终还是选择了RN。

Memory丶:vue技术栈,推荐uni-app;如果是react的技术栈,推荐taro。


chameleon:多态协议理念先进,支持一般

Nickbing Lao:Chameleon 多态协议可以感觉不错。

前端🐶:理念比较先进,但支持感觉不太好。


mpvue:有点坑,做小程序还可以,转h5不行

晴晴晴晴晴晴晴天:我们还是用mpVue开发的,不过只有小程序,不会转H5,其实也转不了,太麻烦了。

芋头:生成的h5也就能跑起来,基本用不了。

小爝:当时我们也自研了vue快应用,比mpvue出来的要早一点,他们刚发布的时候,我们内部做了第一版转快应用的工程工具。所以他们快应用内测的时候我们就参与进去了,主要是做android的系统级别分发。做过这个的伙伴就会明白,所谓多端,一定是选择了多端的支持组件和特性的一个最小子集来开发的。这样做出来的h5,肯定是个阉割版…

前端🐶:mpvue自己不更新了,刚出来的时候真的很不错。

石燕平:我们也是被mpvue坑的屁颠屁颠的后续转战uni-app了。


weex:虽然有点坑,app內表现可以

朴喵pumeow:不考虑h5场景的话,weex在app内的表现不错的,我们是因为有app在的打开诉求。

baiduplus:我们之前搞过weex搭建多端可视化组件搭建活动页面的系统,也是踩了好多坑,开发了一半,补不好,又使用原生了。(朴喵pumeow:一样,感觉现在有点积重难返了,泥足深陷)


RN

matt:RN 虽然组件库很全,但没有一个像 antd 这样的一个稳定的团队维护的组件库。其它框架找不出什么理由用它们。


不使用框架:建议原生

占友伟.E滁州节点科技:强烈不建议选任何框架,小程序本身就很不成熟,在快速发展中,每一家都是如此。多端框架搞搞就搞死了。

mon🍜🍝:直接走原生。

Scaler:直接走原生。

Nickbing Lao:多端小程序原生各一套代码单独维护就有点累了。

Fun:各种小程序是新一代的兼容毒瘤…有没有一种时代倒退的赶脚。

一探:小程序我们也被坑 了,现在我们也是第三方+自研各种补丁,搞得现在心痛。


小程序框架调研与测评


幸福在家里:小程序框架测评➡️小程序开发:用原生还是选框架(wepy/mpvue/taro/uni-app)– 第1季

小爝:我们做的调研

TL日日谈:小程序框架/关于打C/智能开发/埋点

Nickbing Lao:

TL日日谈:小程序框架/关于打C/智能开发/埋点



一个四小时都无法结束的“C”面谈


TL:下午跟一个员工谈C谈了四个小时,员工死活不认可这个结果。本来应该是辞退的,但是后改成降职降薪了。C肯定会有的,我们是按271比例分布的。其实我是想辞退他的,确实不太匹配,hr那边会考虑到赔偿和再招人成本。


iamsunshow:降薪还不如辞退,员工在面子上过不去的。如果这是在大厂,估计还会停一次晋级。面谈能谈四个小时,肯定是考核维度不细致。


Jeff:271 这个划分有点太大了,精细化点更好。


志遥:如果对员工说清评估考察的维度,以及他在评估维度中做得不好的点,他有什么理由不认呢?这个情况引发的一个思考是:是不是平时对这个员工的反馈做的不够,让他工作中始终觉得自己做的还不错。


天元-tain:建议先了解员工诉求,如果真的只是耗着,不如辞退。一时痛比一直痛要好,就怕他会影响其他团队成员。这样的员工养到过年发年终,其实比辞退成本高,前提是确实了解了其诉求。辞退肯定是有标准的,这也是提升团队整体竞争力的一种手段。管理者想避免这种窘境,招人的时候,和面试者的三观契合很重要。


小爝:辞退我就聊过一次,不过是在试用期,能力不行的话,三个月试用期是过不了的。与员工面谈的时候,建议直接点,如果他能忍受不加薪不晋升,那就继续好好干;如果不能忍受的话,就请自己想办法,管理者可以冷处理一段时间看看。打c肯定是管理者有自己的考虑,直接告诉对方结果就行,这不是讨论,也不需要编理由。


sutter’s mill:降职降薪的处理方法,管理者是站在资本家角度了。有问题的话,建议管理者在试用期的时候提出。试用期过了,降职降薪是不合适的,辞退才是正解。



杂谈

智能开发的相关讨论


matt:我司前端开发想要提升效率,有谁知道我们的智能开发到什么程度了?


配置化

ChasLui:我们一直在探索配置化,因为业务特性交互不复杂,基本以 dashbord -> 列表 -> 详情 -> 表单编辑 路线走的。


砂锅米线:前端根据接口模型生成service,根据业务人员配置的字段和控件组装组件和页面。机械重复性工作都尽量用自动化工具完成,前端开发人员只负责写中间的胶水层,专注理解业务,做复杂业务开发提升用户体验,维护自动化工具。页面或者表单设计器这种概念本身就很有年头了,自己团队研发链路上的关键工具早晚要自研,绝对不能长期用第三方的。



邹慧东:接口模型生成service这个是怎么样的过程?

砂锅米线:比如根据后端生成的swagger配置文件,解析后生成代码,url、method、出入参和出入参类型都能取到。这需要后端配合,而且肯定有一定的磨合期,定好接口规范是非常有必要的。



何忠峰:这和现在的组件式开发有区别吗?如果页面、逻辑有很高的复杂度,那么开发的复杂度就不会消减了吗?

砂锅米线:复杂页面和“妖”的页面,的确是需要额外开发的。这么做主要是让项目组有更多的精力放在核心页面流程上。

何忠峰:的确,一般的页面都已有封装度很高、很易用的组件了,基本是数据驱动页面,特殊的页面可以特殊处理。


寒江钓雪的马甲:这些是已经在生产环境落地的实践吗?

砂锅米线:这些都是在开发环节做得,目的是提高开发效率的,不过自动生成的代码还是需要review的。2b就是要标准化,不然怎么提高效率。


xLogic市面上挺多的,面向中后台主流有2种模式吧, 比如:Component Tree编辑,阿里飞冰,Dynamic Logic 编辑,美团乐高。


imgcook

Scott:针对电商场景和模板级别的,大家可以看下 imgcook,https://imgcook.taobao.org


铁拐李:imgcook还原度有点问题,而且有出现解析出错的问题,最终无法导出代码。


砂锅米线:这个工具的主要意义还是在节省调css的时间。


L:这种工具对设计师有很高的规范性。


团队工作价值

小伙吱:除了效率,质量,体验,还可以如何衡量团队工作对业务带来的价值?

Nickbing Lao:可以关注前端结合产品。系统给公司业务流程、团队协作带来什么改变,产品又给公司带来什么效益。


前端埋点

Viktor:你们埋点系统方案是什么样的?

小爝:普通,无痕,全埋点,请右转➡️前端全埋点进化之路-付强-新浪移动


编辑:77

审稿:Scott

发表评论

邮箱地址不会被公开。 必填项已用*标注

相关