SegmentFault 最新的文章 |
- 组员重构代码千奇百怪,直接JS、ES6和Vue规范给一梭子
- 种类丰富的材质库,让开发者建模轻松高效
- 疑难杂症:运用 transform 导致文本模糊的现象探究
- vscode语音注释, 让信息更丰富(中)
- urlcat:JavaScript的URL构建器库
- 怎么说服领导,能让我用DDD架构肝项目?
Posted: 21 Feb 2022 04:00 PM PST 前言近期组员接手了一个"古老"的初始由后端大佬写的前端项目,业务层面的组件复用,全靠是 copy 相同代码咱不说,经过不同大佬们的维护,代码风格更是千奇百怪。该前端项目还在正常迭代更新,又不可能重写,面对 💩 一样的代码,两个接手的小前端抱着欲哭无泪,瑟瑟发抖。见状,只能安慰之,暂时发挥啊 Q 精神,规范自己的新代码,然后每次迭代开发任务重构一两个旧组件,此过程持续 2-3 个月后,上 eslint 和 prettier 自动化检测语法和格式化代码。 Javascript 代码风格使用有意义的变量名称变量的名称应该是可描述,有意义的, JavaScript 变量都应该采用驼峰式大小写 ( camelCase) 命名。
布尔变量通常需要回答特定问题,例如:
避免添加不必要的上下文当对象或类已经包含了上下文的命名时,不要再向变量名称添加冗余的上下文。
避免硬编码值
使用有意义的函数名称函数名称需要描述函数的实际作用,即使很长也没关系。函数名称通常使用动词,但返回布尔值的函数可能是个例外 — 它可以采用
限制参数的数量尽管这条规则可能有争议,但函数最好是有 3 个以下参数。如果参数较多可能是以下两种情况之一:
避免在一个函数中做太多事情一个函数应该一次做一件事,这有助于减少函数的大小和复杂性,使测试、调试和重构更容易。
避免使用布尔标志作为参数函数含有布尔标志的参数意味这个函数是可以被简化的。
避免写重复的代码如果你写了重复的代码,每次有逻辑改变,你都需要改动多个位置。
避免副作用在
另外,如果你将一个可变值传递给函数,你应该直接克隆一个新值返回,而不是直接改变该它。
使用非负条件
尽可能使用简写
避免过多分支尽早
优先使用 map 而不是 switch 语句既能减少复杂度又能提升性能。
使用可选链接
避免回调回调很混乱,会导致代码嵌套过深,使用 Promise 替代回调。
处理抛出的错误和 reject 的 promise
只注释业务逻辑
ES6 优化原生 JS(ES5) 代码风格使用默认参数
对象结构取值
拓展运算符合并数据合并数组或者对象,用 ES5 的写法有些冗余
拼接字符
includes 替代多条件判断
列表查找某一项
数组扁平化
可选链操作符获取对象属性值
动态对象属性名
判断非空
Vue 组件风格Vue 单文件组件风格指南内容节选自 Vue 官方风格指南。 组件数据组件的 data 必须是一个函数。
单文件组件文件名称单文件组件的文件名应该要么始终是单词大写开头 (PascalCase),要么始终是横线连接 (kebab-case)。
紧密耦合的组件名和父组件紧密耦合的子组件应该以父组件名作为前缀命名。
自闭合组件在单文件组件中没有内容的组件应该是自闭合的。
Prop 名大小写在声明 prop 的时候,其命名应该始终使用 camelCase,而在模板中应该始终使用 kebab-case。
指令缩写指令缩写,用
Props 顺序标签的 Props 应该有统一的顺序,依次为指令、属性和事件。
组件选项的顺序组件选项应该有统一的顺序。
组件选项中的空行组件选项较多时,建议在属性之间添加空行。
单文件组件顶级标签的顺序单文件组件应该总是让顶级标签的顺序保持一致,且标签之间留有空行。
| |||||||||||||||||||||||||||||||||||||||||||||
Posted: 15 Feb 2022 05:23 PM PST 材质,是图形学中描述光线如何在物体表面和内部进行交互的一种性质,由材质模型和一组控制参数来定义表面外观。如下图所示,左边的图添加各种材料的纹理后,真实感立显。材质贴图目前已经广泛应用在游戏、建筑、设计等领域。 在材质制作和应用的过程中,用户在纹理采集制作、贴图效果处理等方面都面临一些问题和痛点,如制作过程耗时费力,成本高,且用户可能还需要花费大量时间和精力去寻找合适的贴图资源等等。 如何解决这些痛点呢?我们提供三种思路:一是利用深度学习推理网络,一键生成符合PBR标准的纹理要素,提升纹理制作效率和质量;二是将技术美术的经验和制作规范固化为遵循PBR标准的数据,通过数据在不同项目和渲染器间复用素材,传承美术制作经验;三是充分结合上述两种思路,基于HMS Core 3D建模服务的材质生成能力,建立种类丰富的材质库,避免用户把时间浪费在寻找材质贴图上,通过材质库的高效筛选和应用让用户的模型更加美观。 一、材质生成能力HMS Core 3D建模服务的材质生成能力,可将RGB图像转换为PBR材质,用户只需输入RGB图片,便可一键生成包括diffuse map, normal map, specular map, roughness map,height map的五种贴图类型。材质类型包括混凝土、大理石、岩石、碎石、砖、石膏、黏土、金属、木材、树皮、皮革、织物、漆面、塑料、合成材料等,并且目前已经能支持1k-8k贴图的输出,帮助开发者生成更符合实际需要的材质。 二、种类丰富、高清、快速、好用的材质库基于强大的材质生成能力,3D建模服务为用户提供种类丰富的材质库。材质库能够依据用户需求筛选场景和种类并提供PBR材质贴图,且支持查询、预览和下载等功能,方便用户根据需要高效使用,提高工作效率。用户只需在AGC(AppGallery Connect)开通3D建模服务,进入"我的项目",点击"构建 > 3D建模服务",选择"材质库",便可进入材质库页面。 1、节约时间成本,快速精准获取材质资源在首页提供筛选搜索功能,在搜索框输入要检索的材质名称,点击查询即可获取相关材质。 点击分辨率、场景可筛选符合条件的材质。 应用场景选择。 筛选出符合指定条件的材质,可以灵活选择默认按上传时间或按预览量进行排序,帮助用户迅速高效地筛选出想要获取的材质。 2、1k-4k的高清材质贴图,想用哪里点哪里很多墙体、造型、木制,都需要用材质来表达结构、空间、预期效果等等。模型加入材质库的高清材质贴图后,可以看出明显差距。 点击图片即可进行材质预览,目前预览提供该材质的球体、正方体和平面三种形态的预览效果,并支持鼠标拖拽,环绕展示。
3、30000+海量材质,种类丰富,持续更新,可直接下载目前材质库提供覆盖16个种类的32066个材质,如果该材质满足用户需求,可在预览页面点击右下角直接下载。下载结果为包含材质贴图的zip压缩包,解压后输出为jpg格式,可直接使用,方便快捷。后续材质库也会根据用户需求不断更新升级,敬请期待。 了解更多详情>> 访问华为开发者联盟官网 关注我们,第一时间了解 HMS Core 最新技术资讯~ | |||||||||||||||||||||||||||||||||||||||||||||
Posted: 20 Feb 2022 06:40 PM PST 在我们的页面中,经常会出现这样的问题,一块区域内的文本或者边框,在展示的时候,变得特别的模糊,如下(数据经过脱敏处理): 正常而言,应该是这样的: emmm,可能大图不是很明显,我们取一细节对比,就非常直观了: 何时触发这种现象?那么?什么时候会触发这种问题呢?在 Google 上,其实我们能搜到非常多类似的案例,总结而言:
当然,这只是必要条件,不是充分条件。继续深入探究,会发现,必须还得同时满足一些其它条件:
譬如,上述案例触发的 CSS 代码如下:
由于元素的高度为 但是,需要注意的是,并非所有产生的非整数都会导致了内部的字体模糊。 这里有个简单的示意: 还是上述的例子,当高度从
在我实测的过程中还发现,这个现象基本只会发生在 dpr 为 1 的普通屏幕下。 类似于 MAC 的高清屏幕则不太会触发这个问题。 dpr = 物理像素 / 设备独立像素,表示设备像素比。这个与我们通常说的视网膜屏(多倍屏,Retina屏)有关。设备像素比描述的是未缩放状态下,物理像素和设备独立像素的初始比例关系。
为何发生这种现象呢?那么,为何会发生这种现象?针对这个问题,没有找到特别官方的回答,普遍的认为是因为: 由于浏览器将图层拆分到 GPU 以进行 3D 转换,而非整数的像素偏移,使得 Chrome 在字体渲染的时候,不是那么的精确。 关于这个问题,感兴趣的可以再看看这两个讨论:
如何解决?那么针对这个问题,我们该如何解决呢?社区里给出的一种方案:
如果你赋予给元素的
如果这个问题对你的页面非常致命,那么只能弃用 总结一下,本文简单探究了在 Chromium 内核下,使用了 最后好了,本文到此结束,希望本文对你有所帮助 :) 想 Get 到最有意思的 CSS 资讯,千万不要错过我的公众号 -- iCSS前端趣闻 😄 更多精彩 CSS 技术文章汇总在我的 Github -- iCSS ,持续更新,欢迎点个 star 订阅收藏。 如果还有什么疑问或者建议,可以多多交流,原创文章,文笔有限,才疏学浅,文中若有不正之处,万望告知。 | |||||||||||||||||||||||||||||||||||||||||||||
Posted: 20 Feb 2022 03:43 AM PST vscode语音注释, 让信息更丰富 (中)前言上一篇我们做完了最基础的功能"识别语音注释", 本篇我们要一起开发语音'播放'等相关功能。 一、mac电脑获取音频文件(后期有坑,到时会填) 要开发音频'播放'功能, 那我们首先需要一份音频文件, 上网找 这里演示 第一步: 找到软件:第二步: 将录制好的音频分享到某个app上
"m4a是MPEG-4音频标准文件的扩展名,与大家熟悉的mp3一样,也是一种音频格式文件,苹果公司用此命名来区分mpeg4视频。" 二、播放音频插件的选择 这里的播放指的是"鼠标悬停"即可播放音频, 那么就不能是 在网上用
安装走起:
使用播放:(这里暂时使用绝对地址)在`hover.ts文件内添加:
三、node-wav-player的核心原理 初始化的 | |||||||||||||||||||||||||||||||||||||||||||||
Posted: 16 Feb 2022 05:24 AM PST urlcat 是一个小型的 JavaScript 库,它使构建 URL 非常方便并防止常见错误。 特性:
为什么用?在调用 HTTP API 时,通常需要在 URL 中添加动态参数:
正如你所看到的,这个最小的例子已经很难阅读了。这也是不正确的:
我可以使用内置的
如此简单的任务,却又很难读,写也很乏味!这是这个小型库可以帮助您的地方:
这个库会这样处理:
如何使用?目前,该软件包通过 npm 分发。 (Zip 下载和 CDN 即将推出)。
在Node.js中使用官方支持 Node 10 及更高版本。由于代码在内部使用 URL 和 URLSearchParams 类,它们在 v10 以下不可用,因此我们无法支持这些版本。 要构建完整的 URL(最常见的用例):
要使用任何一个实用函数:
要使用所有导出的函数:
在Typescript中使用官方支持 TypeScript 2.1 及更高版本。 要构建完整的 URL(最常见的用例):
要使用任何一个实用函数:
要使用所有导出的函数:
在Deno中使用
APIParamMap:具有字符串键的对象例如, urlcat:构建完整的 URL
例如:
query:构建查询字符串使用指定的键值对构建查询字符串。键和值被转义,然后由 例如:
subst:替换路径参数用模板字符串中的值替换参数。模板可能包含 0 个或多个参数占位符。占位符以冒号 ( 例如
join:使用一个分隔符连接两个字符串仅使用一个分隔符连接两个部分。如果分隔符出现在 例如:
Github库地址:https://github.com/balazsboto... | |||||||||||||||||||||||||||||||||||||||||||||
Posted: 20 Feb 2022 06:14 PM PST 作者:小傅哥 沉淀、分享、成长,让自己和他人都能有所收获!😄 一、前言
我也苦思冥想,怎么跟领导说咱们从 MVC 升级到 DDD 吧,因为 DDD 代码结构更加清晰、领域驱动比测试驱动开发更加先进、研发的兄弟们也更想用用新框架等。 不过这么聊被喷一顿不说,还得说你是过度设计瞎折腾,咋回事呢?因为没聊到重点呀,你MVC升级DDD; 那就不搞了吗?搞哇,不让搞换领导!但搞之前,要考虑清楚,DDD 不是 Silver Bullet,你有一腔热血虽好,可是也得知晓 DDD 的设计原则是什么、它更适合的场景是什么、与 MVC 对比有什么云泥之别。 二、开发成本使用 DDD 模式开发代码的成本到底在哪?是因为使用 那这里的 DDD 领域驱动设计开发的成本在哪呢?这个成本在于对于一个复杂系统又尚未在开发前期就有非常充足的经验来 而通常使用的 MVC 结构基本不会出现这样的问题,因为在实际的代码中,DAO、PO、VO等都是共用的,大家在开发代码的时候,像 那不是可以设计模式吗,这就需要看你是站在哪个维度去思考问题。设计模式在这里是战术问题的,DDD和MVC是确定战略问题的,有点像是说:"方向不对,努力白费一样" 那么现在我们再来看这条开发成本曲线:
三、架构对比在了解和掌握 DDD 领域驱动设计的路上,你一定会碰到两个抽象的钉子 —— "贫血模型"、"充血模型":
1. MVCMVC 分层结构将:"状态"(数据,成员对象)、"行为"(逻辑、过程),分离到不同的对象中,只有状态的对象(VO -> Value Object) 被称为贫血模型,只有行为的对象,就是框架分层中常见的Logic/Service/Manager层(对应到EJB2中的Stateless Session Bean)
2. DDDDDD 的分层结构也是面向对象编程的本质:"一个对象拥有行为和数据",在领域层包括了:对象、聚合对象、仓储和Service实现。
四、设计原则首先 DDD 的设计分为战略和战术;
在以DDD领域驱动设计落地的过程中,要依靠领域驱动设计的设计思想,通过事件风暴建立领域模型,合理划分领域逻辑和物理边界,建立领域对象及服务矩阵和服务架构图,定义符合DDD分层架构思想的代码结构模型,保证业务模型与代码模型的一致性。通过上述设计思想、方法和过程,指导团队按照DDD设计思想完成微服务设计和开发。
DDD 的领域模型设计,界限内的上下文,可以拆分为独立的微服务。但不仅要从业务视角看问题,也要考虑非业务的技术因素,包括:高性能、安全、团队、技术异构等,这些非业务的技术因素,也会决定领域模型落地的具体落地。 五、举个例子你说我 MVC 不好,你说我 MVC 贫血模型,PO 类不断的膨胀,但让我用 DDD 又都是理论,程序员更喜欢看的是已经落地的代码,告诉我怎么干。 为什么这么难落地呢?因为从 MVC 过度到 DDD 描述对比 1. 工程结构所以为了让更多的码农看到在 DDD 上一条能走的路,专门折腾了个 整体系统架构设计包含了6个工程:
2. 流程拆解当我们拿到产品的 RPD 以后,并不是直接上手开发,而是需要从流程中拆解出一份面向对象设计的领域服务,举例;
3. 一起实践如果你对 DDD 实践学习的事情感兴趣,也可以一起加入 学习链接:https://bugstack.cn/md/project/lottery/introduce/Lottery%E6%8A%BD%E5%A5%96%E7%B3%BB%E7%BB%9F.html
六、总结
|
You are subscribed to email updates from SegmentFault 最新的文章. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States |
No comments:
Post a Comment