网站建设费 大创,wordpress好不好用,音乐网站开发教程,oa手机端app下载前言
hi#xff0c;正式接触web前端已经经过了两年的时间#xff0c;从大学的java后端转型到web前端#xff0c;再到后续转战Flutter#xff0c;逐渐对前端有了一些心得体会#xff0c;其实在当下前端的呈现形式一直在变化#xff0c;无论你是用原生、还是web还是混编的…前言
hi正式接触web前端已经经过了两年的时间从大学的java后端转型到web前端再到后续转战Flutter逐渐对前端有了一些心得体会其实在当下前端的呈现形式一直在变化无论你是用原生、还是web还是混编的形式去做我不希望前端被框架束缚住它本质上不过是一种产品的表达形式罢了是一种最靠近用户体验的实现方式所以这篇文章在大体上来说并不是针对于某一种框架或者技术栈而是我想表达我在使用某一个呈现方式的时候对其的理解和体会并尝试找出公共的特点希望我的想法可能对你有一些帮助。
实现准备
一款产品往往来自于产品设计的某一个想法再到设计再经过一系列的流程最终转化成设计稿交付到前端的手上那么这里面就有一系列需要前端有一系列的准备放心不是让你提桶跑路而是我认为大概率需要做的一些准备
沟通
沟通非常重要一位优秀的产品设计师或许并不是优秀的前端实现者他们考虑的并不是如何实现而是真正把想法设计出来而已。我们需要考虑用户体验、人机交互、UI绘制、实现成本这其中往往存在一些矛盾的地方这很正常开发本身就是鱼翅熊掌很难兼得的情况重点是你需要把这些地方通过对话的方式阐述出来。
举个例子产品设计跳转动画非常的华丽实现也能实现但是时间成本比较高在一些机型上甚至会出现卡顿的现象用户体验差了那么这种完全可以换一种实现方式具体怎么换换哪一种是需要沟通商议出来的。
甚至有一些问题是在开发中途遇到的这种时候也需要及时沟通注释一定要写清楚什么时候变更的怎么变更的谁指派的任务可能会引起的后果。
技术实现图
这一点对我而言也是非常重要的一环可能某一些开发者拿到设计稿撸起袖子就是干简单的设计流程可能还行但是一旦遇到复杂的业务逻辑就开始手忙脚乱了而且中间有一环错了都不知道错误在哪里后续代码更是难以维护我们以苹果支付流程为例。
逻辑分层
对于复杂的业务逻辑首先要做的是逻辑分层先把大体流程做出来。 先把一步步的逻辑拆分出来变成子任务最后汇总成大体的业务逻辑。
设计画图
我们在把逻辑拆分出来之后就要结合设计稿绘制我们的实现设计稿比如我在实现苹果支付的流程就是如此前者是逻辑思路的拆分后者是用户看到的一面真正给用户用到的功能图。
技术选型
这一点对于团队合作的项目来说十分重要哪怕只有你一个人在开发也要考虑后期的维护更新又或者说是接替项目需要做技术方案更换都需要考虑技术选型。
技术选型一般还需要考虑整体成本如果团队对某一个框架有很深的研究和理解那自然选择理解最深的框架最好时间成本最低维护成本最低。
当然也需要看技术本身的持续性官方生态是否齐全完善、论坛是否活跃、遇到问题是否有解决方案。
初步搭建
在进行技术选型之后我们大概率要经历框架的搭建这里主要考虑的可维护性和可拓展性。
比如后续可能会被其他项目所使用那么你可能要做成模块的形式。
比如后续可能会需要混淆代码、可能进行二次开发那么你可能要做成基类的形式等等。
开发范式
这里主要是分享一些我个人的开发范式当然可能企业内部有自己的代码规范网上也有非常多的代码规范所以这里不讲代码规范的东西如果企业内部有就遵从内部规范如果没有就找靠谱的规范去走。
纯粹性
这里的纯粹性更多指的是组件或者函数没有副作用比如你在开发一个页面的时候可能某一个布局会被二次使用这个时候大多数人会采用封装组件的形式这样可以全局使用或者局部使用不用二次编写造成冗余的代码这一点没错问题在于当组件不够纯粹可能造成的问题。
第一是数据依赖问题 封装的时候你需要弄清楚一点你的组件究竟的作用是什么
如果是纯粹的UI展示那么数据依赖大概率需要依赖于他的使用者它必须足够的纯粹遵循着单向数据源的原则。组件所有需要展示的数据来源于他的使用者具体展示是根据拿到数据之后去呈现一系列的交互数据都传递回使用者去处理你的组件只负责展示其余事情一概交给使用者。 如果你不遵循这样的原则组件的也能自己操作数据那么数据的变化你是无法预测和追踪的是不可控的。
我看过一个案例使用flutter封装了一个静态组件组件的某一处的ui依赖于某一个数据但是这个数据是组件内部创建的只是变化是由外部控制的这个时候就有一个问题当他页面刷新的时候组件重置了数据也重置了尽量没有调用变化函数但是ui还是变了最终变成不可控不纯粹的组件 后续改成所有变量、函数都由使用者进行传递组件也就能按照预期的工作了。
第二是你只是想进行抽离很大可能是这一块与当前的业务是无关的这个时候可以不遵循的单向数据源的原则比如你只是想放一个广告展示着数据是不会经常变动的也不需要外部传递数据它就跳转外部和关闭广告的功能也不需要埋点。
分层
复杂项目代码尽量遵循MVM模型
分层的目的更多的是为了提高代码的可维护性 Web端
这个模型在web端更多体现在开发者个人层面并没有代码层面上面的约束也就是在web端你是足够自由的。
比如我在做Vue2的项目或者Vue3甚至React你如果想抽离方法Vue2你可能会使用mixin当然非常不建议使用mixin官方说的话确实是真的Vue3或者React可能使用useHook的东西去自定义也可以使用todo这些注释类的东西这是因为框架本身就帮你做了很多东西已经帮你分层了暴露了一些操作数据就能引起UI变化的方法。
比如后端给了一个页面详情的json数据它可能长这样
{title:这是标题,content:这是内容,cover:xxxxx.png
}然后它会体现在你的页面上来你可能会说这也太简单了吧。
拿到数据之后给页面的局部特殊变量带有数据监听直接赋值页面监听到数据变化就会改变视图的呈现。
如果后端给的某一个变量不是字符串类型而是数字类型的这个在编译之后都不会被察觉到当然可能也不会报错但这是无法被预测到的你当然也可以选择使用Ts去增强代码的强度毕竟在js方面分层的概念还是比较弱的。
Flutter
Flutter我认为在这一块做得很好本身就是强语言对于类型的约束性是很强的当然我在一开始接触的时候还是非常痛苦的过程不断的报错可能结果就是已知的但是编译器会强迫你去考虑未知的东西。
但是无论你用的是怎么样的框架我都建议你去进行分层写一个伪代码。
实际上对于语言而已它并不知道或者说你要认为它是不知道它可能会获取到怎么样的数据你需要提前告诉它模型
定义好数据类型定义数据转化方法视图层并不是直接接触数据而是先接触到我们的内部定义好的模型视图层模型视图层来直接接触模型和视图模型层才能接触到真正的数据。
编译器支持 当你这么做了之后代码层面已经非常清楚将会拿到的是怎么样的数据之后的代码提示会非常清晰你对数据结构也会非常清晰高度的可维护性 一旦数据出现问题或者数据结构发生了变化你都能快速定位到相应的模型层去进行修改由于视图和模型是相互依赖的关系编译器也会快速的定位到需要修改的地方。
视图层也不会直接接触数据而是接触视图模型层所有的方法变量都在视图模型层去负责转化、分发视图层纯粹的视图展示模型纯粹的数据抽象化这也体现了纯粹性的好处。无论你在前端或者在后端对于复杂项目都请尽量这么做
容错
允许自己犯错 没有生来就完美的代码哪怕是Vue的作者回顾几个月前的代码都会感概当初竟然会这么写Vue已经被重写多遍了。如果不是核心部分受到伤害或者手眼可见的问题请不要去想着如何优化。一是这会加重开发的心智负担二是效率非常低开发的同时去优化代码会让自己陷入自我怀疑的境地走一步怕一步。先把逻辑写出来再去敲代码优化是后者的事情。提高容错率 这里实际上是需要建立在前者的基础上的只有你允许你犯错才能提高容错率先别急着反驳我除非你能向我保证你从来都不犯错只要键盘敲下就一定是最佳结果如果是那你可以跳过这一点。
1、逻辑分层 只有将大体逻辑罗列出来在后续的回顾中才能从每一点逻辑中预测可能会发生什么错误才能预防
2、视图分层 某一个视图专门负责展示某一块数据尽量根据逻辑去拆分你的视图。
比如商城首页 某一块都是单独的逻辑不会因为一处地方有问题就影响全局有问题既能够迅速定位又能够快速迁移二次开发。
3、注释先别急着删除 前期的初版代码或许有不完美的地方、产品需求的变动等一系列原因导致你的代码发生了大的改动这个时候你可能会删除旧逻辑代码这一点本身没有问题但是如果产品本身并不是特别稳定或者并没有经过长时间的琢磨或者沉淀的情况下尽量不要去删除旧代码谁知道呢哪怕要删除也一定要迭代几个稳定版本之后再慢慢去剔除掉。
官方为主
新人在接触新技术或者新框架的时候可能会先去搜索视频、博客、文档去看很少人能够直接阅读完整篇官方文档我并不否认官方外的东西对开发的帮助因为我也曾经这么尝试过。 官方文档可能在内容上比较繁多但是一定是最准确的如果不准确就是这个技术已经不活跃了或者根本没有阅读仔细。 外部资源也是在阅读理解了官方文档之后进行的拆解和分析所以我会更推荐官方为主其他资源为辅助的阅读方式
有demo先跑demo从效果中去看代码再进一步看实现原理。
清理
在web端浏览器自带有垃圾回收机制对于无法访问到的数据可以判定为垃圾当然也会因为操作不到导致内存泄漏和变量污染的问题。在web端可能体现在定时器、计时器、自调用、错误使用全局变量等等情况。在Flutter端可能存在各种流数据请求、变量等。
这里讲一个案例
我们做的一款产品是Flutterh5的某一些页面是用h5去做的但是里面存在某一些数据是需要加密请求获取到的。我们一开始的方案是h5通知Flutter端进行请求Flutter经过加密解密一些操作之后将结果发送给h5端如图所示 正常来说是没有任何问题的但是这里忽略了一个情况
假如h5页面发出去请求之后h5页面已经因为某一些原因已经卸载了Flutter无感知导致无法知道响应是否已经被接收到了甚至可能有某一些业务需要重复调用请求但是不知道h5已经无法处理了Flutter也没有做好回收机制导致请求满天飞的情况无法中止的情况当然如果是Dio本身就有提供回收机制的但是你也需要注意这种情况这又涉及到我之前的文章在混编的情况下请求究竟要放在哪里但无论在哪里你都要保证是可控的否则就不要使用
升级
这里最好使用版本管理工具例如nvm能管理node版本fvm能管理flutter那究竟是否要升级需要考虑以下几点
升级了是否会影响旧版本的运行新旧版本区别大不大是不是必须要升级版本才能上线升级了版本导致旧版本无法运行如何做好后期维护处理
结尾
写代码和构建 App 只是手段并不是目的学习技术的目的也只是为了能通过解决问题而表现你的价值。
企业也不会在乎使用某一项技术有多么牛逼他们看重的是技术能否以最小的成本换取背后最大化的收益
身体是革命的本钱
未完待续欢迎评论补充和纠正
