作为一名程序员，我们经常会面临工作压力和时间紧迫的情况，因此有一个好的自控力对于我们的工作和生活都是至关重要的。以下是一些可以帮助程序员增强自控力的方法：

1. 设定明确的目标和计划

制定明确的目标和计划可以帮助我们更好地管理时间和精力。我们可以使用日程表、任务清单、时间追踪工具等，来帮助我们控制时间并更有效地完成任务。

2. 掌控情绪

作为程序员，我们需要面对很多挑战和压力，容易受到情绪的影响。因此，掌握情绪是一个非常重要的技能。可以通过冥想、呼吸练习、运动等方法，来帮助我们保持冷静、积极和乐观的心态。

3. 管理焦虑和压力

焦虑和压力是我们常常遇到的问题之一，所以我们需要学会如何管理它们。我们可以使用放松技巧、适度锻炼、交流沟通等方法，来减轻我们的焦虑和压力。

4. 培养自律习惯

自律是一个非常重要的品质。我们可以通过设定目标、建立规律和强化自我控制等方式，来培养自律习惯。

5. 自我反思和反馈

经常进行自我反思和反馈可以帮助我们更好地了解自己的优缺点和行为模式。我们可以使用反馈工具或与他人交流，来帮助我们成长和改进。

6. 持续学习和自我发展

程序员需要不断学习和自我发展，以保持竞争力和提升自己的技能。通过阅读书籍、参加培训、探究新技术等方式，可以帮助我们持续成长，增强自我控制力。

结论

自控力是我们工作和生活中重要的的品质之一，可以帮助我们更好地应对各种挑战和压力。通过设定目标、掌控情绪、管理焦虑和压力、培养自律习惯、自我反思和反馈、持续学习和自我发展等方法，我们可以帮助自己增强自我控制

背景原因

最近裸辞离职在老家，正在收拾老家的房子准备住进去，但迫于经济压力，只能先装非常有必要的东西,例如床、马桶、浴室柜等。

但是垃圾桶是生活必备品，我发现大家现在都在用智能垃圾桶，那种可以感应开盖的，还有那种自动封袋的。我极其的羡慕。但是迫于经济压力，我没有足够的资金购买智能垃圾桶！

作为一个学美术的程序员，我在想我要不要去少儿美术培训教小孩，或者去街头卖艺，甚至去给人画遗照赚点钱呢？我想了想算了，给别人留点活路吧，我这么专业的美术人才去了，那些老师、街头艺人、画师不得喝西北风去。我想了想，我除了是学美术的，我还是个程序员啊！

虽然我没有学过嵌入式、硬件、IOT等等技术，但是入门应该不太困难吧！已经好多年没有从0开始学习一门技术了，非常怀念当时学习Web技术的那种感觉，可以没日没夜的去探索新知识，学习东西。之前上班的时候根本没有精力去学习或者搞一些有趣的东西，下班只想躺着看动漫，听爽文。既然现在赋闲在家，那就搞一搞吧！

项目启动

俗话说得好，找到一个好师傅就是成功的一半！在这方面我有着得天独厚的优势，我的前公司，北京犬安科技就是一个做车联网安全的公司，这家公司的Slogan是：从硅到云，守护网联汽车安全。可以看出，犬安的硬件软件安全能力都非常的强。像我，天天和测试组的同事去山西面馆吃鱼香肉丝盖饭，喝青岛雪花，他们组里面都是硬件大佬，甚至有人造过火箭。此时不向他们学习，更待何时？

他们告诉我，我需要一个开发板、一个超声波传感器、一个舵机。

我还在研究什么是stm32/esp32的时候，他们告诉我用Arduino，特别简单。我就去研究Arduino，在B站上搜了 Arduino，有一个播放量比较高的系列教程看了一下。我顿时就悟了！

我本来以为我需要买烙铁，焊电路板的，后来我发现，只需要买以上提到的三个东西，外加一个面包版，一些杜邦线就可以，甚至可以不需要面包版。

当然为了学习，我在淘宝上买了一些乱七八糟的东西，比如按钮、各种电阻、各种颜色led灯、面包版。买各种颜色的LED灯的时候，购买欲泛滥了，就想每个颜色都买一些，什么白发红，白发黄，白发翠绿，后来我买回来发现，不亮的情况下都是白色的，我根本分不清颜色。原来那个白发黄的意思就是不亮的时候是白色，亮了以后发黄色的光～我还买了接受RGB三色的LED灯，不知道为啥不是RGBA，难道不能让灯透明吗？

我还发现不同欧姆的电阻他上面的“杠杠”是不一样的。

主要是这玩意太便宜了，两块钱就买好多，但是作为新手玩家来说，根本用不了。我只买了公对公的杜邦线，然后我又单独下单了其他杜邦线，果然两块多就能包邮。

我在不同的店铺里面选了很多配件，包括我使用的主要配件：Arduino uno 开发板、SG90舵机、HC-SR04 超声波传感器。

开搞

设备买回来以后，废了9牛2虎之力才成功的能把我写的程序上传到开发板里。

一开始一直报下面这个错误，网上众说纷纭，始终没有找到解决方案。

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x30

后来我去淘宝详情页仔细研究了一番才搞明白，我本以为我买的是Arduino的开发板，其实是esp8266，只是兼容Arduino。我从淘宝详情页找到了正确姿势，成功的刷入了程序。

看了 Arduino 的视频，我主要悟出来了什么？

开发板、舵机、传感器上有很多小尖尖或者小洞洞，他叫引脚，我们需要把舵机、传感器的引脚，通过一种名为杜邦线的线（通常有公对公/母对母/公对母，代表线两头是小尖尖还是小洞洞），连接到开发板的引脚上。然后使用程序控制某个引脚的电平向舵机发送信号，或者接受传感器的信号。

第一个项目

我举一个最简单的LED灯闪烁的例子： 线是这么接的：

面包版上面，竖着的五个小洞洞里面其实是连在一起的。我的电路是从一个引脚出来，到了一个电阻上，然后连接一个LED灯，然后接地。 接地的概念应该和负极的概念很像，但是不是，不过我暂且不关心它。 为什么不直接从引脚出来接LED，再接地呢，因为视频上说，LED几乎是没有电阻的，如果直接从串口出来接到LED，直接接地的话，开发板就废了，所以加了个电阻。

接下来我让ChatGPT帮我写一个小LED灯闪烁的代码：

我们可以看到在loop里面，调用了digitalWrite，把那个引脚进行了高低电平的切换，这样就实现了小LED灯闪烁的效果，高电平就相当于给小LED灯供电了。

我们只需要把他写的代码中的引脚的编号改成我们的编号就好了。

每种开发板的引脚编号都不一样！我在淘宝上买的这个板，他没有给我资料，我干了一件特别愚蠢的事情，分别给不同的数字编号供电，插线看哪个亮，就记录对应开发板上的引脚号和数字。

第二天我在网上稍微搜了一下资料就找到了。后来我发现，竟然还有一个编号对应两个引脚的，具体为什么我也不知道。

不过具体怎么给舵机传信号，或者接受传感器的信号呢？如果在 Arduino IDE 里面的话就是简单的调用API就好了。这一块我没写代码，都是ChatGPT帮我写的。

实现目标的主要部分

我使用同样的方法，制作了垃圾桶的功能的电路和代码。 使用超声波传感器的时候，我发现这玩意都好神奇啊，仿佛是魔法一样。 比如超声波传感器，要先发送一个超声波信号出去，然后等待回波信息，拿到发送和接收的时间差，通过计算得到距离。

我在调试超声波传感器的时候，我发现我能听到超声波传感器发出的声音，只要耳朵对着它不用靠太近就可以听得到。我朋友说我是超级耳。

有了LED灯的经验以后，超声波识别距离，调用舵机旋转很快就实现了。

最开始我在考虑这个舵机的力道到底能不能支撑起来垃圾盖子，不过现在感觉力道还是挺大的。不过现在没有办法试，因为我还没有做出来合适的垃圾桶。

接下来

接下来我要去找到一个合适的垃圾桶，我也不确定需要用什么方式去打开垃圾桶的盖子，是不是需要其他的比如初中学过的滑轮、齿轮、杠杆原理什么的？这块还没有开始涉猎，等我接下来研究研究来写第二部分。

感谢大家阅读～

今年都做什么了? 刷视频 打王者 空余时间维护了一个项目 就这样吧

仔细想了想今年也没有做什么呀! 真是年纪越大时间越快

为什么有大有小啊?

95的够大了吧

步入前端也才不到3年

So一个大龄的小前端

技术有长进么?

一个PC端项目 用了 react antd redux-toolkit react-router ahooks axios 也就这样吧,就一点简单的项目,react熟练了么?有点会用了,可是我工作快3年了,写项目还是要来回查文档,antd用的熟练的时候倒是可以不用去查文档,可是过了就忘了,今天写项目就有点想不起来怎么用了,查了文档才可以继续写下去

有长进么?

1. 
   

   react熟练了一些,可以自己看源码了

   
   


2. 
   

   自己解决问题的能力有了一点提升

   
   


3. 
   

   技术的广度认识有了(23年目标是深度)

   
   


4. 
   

   数据结构了解一点了 二叉树 队列 链表 队列 (还学了一点算法,不过忘了🤣)

   
   


5. 
   

   写代码喜欢封装组件了

   
   


6. 
   

   node学了一点又忘了

   
   


7. 
   

   ts会的多了一点

   
   


8. 
   

   antd也好一点了,以前在群里问一些小白问题,还好有个大哥经常帮我

   
   


9. 
   

   css 还是不咋地 不过我刚买了一个掘金小册 s.juejin.cn/ds/hjUap4V[…

   
   

生活上有什么说的呢?

生活很好 吃喝不愁

就是太久没有回家了 老家黑龙江 爷爷奶奶年纪大了 有时候想不在杭州了 回哈尔滨吧 这样可以多陪陪他们 可是回哈尔滨基本就是躺平了 回去我能做什么? 继续做前端? 好好补补基础去做一个培训讲师?

回去的好处是房子压力小 可以买一个车 每天正常上班 下班陪家人 到家有饭吃 想想也挺好

不过女朋友想在杭州,所以我还会在杭州闯一下的,毕竟我们在杭州买房子也是可以努力一下的

女朋友对我很好 我们在一起也快3年了 我刚步入前端的时候我们刚在一起 2020-05-20 她把我照顾的很好 她很喜欢我我感觉的到 我平时不太会表达 其实我是想跟她结婚的我也喜欢她 我对她耐心少了一点 这一点我会改的 以后我想多跟她分享我每天发生的事 我想这样她会更开心一点吧

今年她给我做了好多的饭,有段时间上班都是她晚上下班回来做的(她下班的早 离家近) 第二天我们好带去(偶尔我们吃一段时间的轻食) 可是我还是胖了

2023要怎么做?

我想成为大佬 我想自律一些 还有工资也要多一点吧

• 开年主要大任务 两个字 搞钱 咱们不多来 15万可以吧 嗯 目标攒15W


• 紧接上条 要是买 20W-30W的车 那你可以少攒点 8万到10万 (买车尽量贷款10W)


• MD 减肥可以吧 你不看看你多胖了呀 175的身高 快170斤了减到140斤 (总觉得不胖,壮)


• 技术一定要提升 你不能再这样下去了 要被清除地~

技术我们来好好的捋一下,该怎么提升

1. 现有项目自己codeReview(改改你的垃圾代码吧)


2. css多学点
   
   
   
   1. css in js
   
   
   2. Tailwindcss
   
   
   3. css Module less 写法好好研究一下
   
   
   4. css 相关配置要会
   
   
   
   


3. react源码要搞一下
   
   
   
   1. fiber
   
   
   2. hooks
   
   
   3. diff
   
   
   4. 一些相关的库的源码 (router,redux等)
   
   
   
   


4. webpack vite (要能写出来插件)


5. node 这个一定要学会 (最起码能自己写接口和工具)


6. 文章要搞起来 (最起码要写20篇,前5篇要一周一篇文章)

2023 搞一个 pc端 H5 小程序 后台接口 要齐全 必须搞出来一个 加


1 背景介绍

1.1 问题

• 
  

  搜索结果落地页，按照价格筛选及排序，结果不太准确；

  
  


• 
  

  用户按照价格筛选后的商品与实际存在的商品不符，可能会缺失部分商品，影响到用户购物体验。

  
  

1.2 到手价模块在促销架构中所处的位置

在整体架构中，商品的到手价涉及红包，活动等模块的协同工作。通过将商品售价、红包、活动等因素纳入综合考虑，计算出最终的到手价，为顾客提供良好的购物体验。

2 设计目标

• 体验：用户及时看到商品的最新到手价，提升用户购物体验；


• 实时性：由原来的半小时看到商品的最新到手价，提升到３分钟内。

3 技术方案核心点

3.1 影响因素

影响商品到手价的主要因素:

1. 
   

   商品，发布或改价；

   
   


2. 
   

   红包，新增/删除或过期；

   
   


3. 
   

   活动/会馆，加入或踢出。

   
   

3.2 计算公式

如图所示，商品详情页到手价的优惠项明细可用公式总结如下：

商品的到手价 = 商品原价 - 活动促销金额 - 红包最大优惠金额

4 落地过程及效果

随着业务需求的变化，系统也需要不断地增加新功能或者对现有功能进行改进，通过版本演进，可以逐步引入新的功能模块或优化现有模块，以满足业务的需求。

商品的到手价设计也是遵循这样规则，从开始的v1.0快速开发上线，响应业务； 到v2.0，v3.0进行性能优化，升级改造，使用户体验更佳，更及时。

4.1 v1.0流程

v1.0流程一共分为两步：

1. 
   

   定时任务拉取拉取特定业务线的全量商品，将这批商品全量推送给各个接入方；

   
   


2. 
   

   促销系统提供回查接口，根据商品id等参数，查询商品的到手价；

   
   

4.2 v1.0任务及接口

1. 
   

   v1.0任务执行时间长，偶尔还会出现执行失败的情况；而在正常情况下用户大概需要半小时左右才能感知到最新的商品到手价；

   
   


2. 
   

   需要提供额外的单商品及批量商品接口查询到手价，无疑会对系统产生额外的查询压力，随着接入方的增加，接口qps会成比例增加；

   
   

4.3 v2.0设计

针对v1.0版本长达半个小时更新一次到手价问题，v2.0解决方案如下：

• 实时处理部分

商品上架/商品改价；

商品加入/踢出活动；

商品加入/踢出会馆；

这部分数据的特点是，上述这些操作是能实时拿到商品的infoId，基于这些商品的infoId，可以立即计算这些商品的到手价并更新出去。

商品发布/改价，加入活动/会馆，踢出活动/会馆；接收这些情况下触发的mq消息，携带商品infoId，直接计算到手价。

• 3min任务，计算特定业务线的全量商品到手价

红包: 新增/更新/删除/过期；

这部分数据的特点是，一是不能很容易能圈出受到影响的这批商品infoIds，二是有些红包的领取和使用范围可能会涉及绝大部分的商品，甚至有些时候大型促销会配置一些全平台红包，影响范围就是全量商品。

综上，结合这两种情况，以及现有的接口及能力实现v2.0；

推送商品的到手价，消息体格式如下，包括商品id，平台类型，到手价：

[

{"infoId":"16606xxxxxxx174465"，

"ptType":"10"，"

realPrice":"638000"}

]

首先在Redis维护全量商品，根据商品上架/下架消息，新增或删除队列中的商品；其次将全量商品保存在10000队列中，每个队列只存一部分商品：

queue1=[infoId...]



queue2=[infoId...]



...



queue9999=[infoId...]

右图显示的是每个队列存储的商品数，队列商品数使其能保持在同一个量级。

多线程并发计算，每个线程只计算自己队列的商品到手价即可；同时增加监控及告警，查看每个线程的计算耗时，右图可以看到大概在120s内各线程计算完成。

注意事项:

1. 
   

   避免无意义的计算: 将每次变化的红包维护在一个队列中，任务执行时判断是否有红包更新；

   
   


2. 
   

   并发问题: 当任务正在执行中时，此时恰巧商品有变化(改价，加入活动等)，将此次商品放入补偿队列中，延迟执行；

   
   

综上，结合这两种场景可以做到:

1. 
   

   某些场景影响商品的到手价(如改价等)，携带了商品infoId，能做到实时计算并立即推送最新的到手价；

   
   


2. 
   

   拆分多个商品队列，并发计算； 各司其职，每个线程只计算自己队列商品的到手价；

   
   


3. 
   

   降低促销系统压力，接入方只需要监听到手价消息即可。

   
   

4.4 v3.0设计

可以看到随着商品数的增加，计算耗时也成比例增加。

解决办法:

1. 
   

   使用分片，v2.0是将一个大任务，由jvm多线程并发执行各自队列的商品；
   v3.0则是将这个大任务，由多个分片去执行各自队列中的商品，使其分布式执行来提高任务的执行效率和可靠性；

   
   


2. 
   

   扩展性及稳定性强，随着商品的增多，可以适当增加分片数，降低计算耗时。

   
   

5 总结

• 
  

  系统扩展性 数据量日渐增大，系统要能做升级扩展；

  
  


• 
  

  系统稳定性 业务迭代，架构升级，保持系统稳定；

  
  


• 
  

  完备的监控告警 及时的监控告警，快速发现问题，解决问题；

  
  


• 
  

  演进原则 早期不过度设计，不同时期采用不同架构，持续迭代。

  
  

关于作者

熊先泽，转转交易营销技术部研发工程师。代码创造未来，勇于挑战，不断学习，不断成长。

转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~

作者：转转技术团队
来源：juejin.cn/post/7240006787947135034

随着API越来越广泛和规范化，对标准化、安全协议和可扩展性的需求呈指数级增长。随着对微服务的兴趣激增，这一点尤其如此，微服务依赖于API进行通信。API网关通过一个相对容易实现的解决方案来满足这些需求。

也许最重要的是，API网关充当用户和数据之间的中介。API网关是针对不正确暴露的端点的基本故障保护，而这些端点是黑客最喜欢的目标。考虑到一个被破坏的API在某些情况下可能会产生惊人的灾难性后果，仅此一点就使得API网关值得探索。网关还添加了一个有用的抽象层，这有助于将来验证您的API，防止由于版本控制或后端更改而导致的中断和服务中断。

不幸的是，许多API网关都是专有的，而且价格不便宜！值得庆幸的是，已经有几个开源API网关来满足这一需求。我们已经回顾了六个著名的开源API网关，您可以自行测试，而无需向供应商作出大量承诺。

Kong Gateway (Open Source)

Kong Gateway（OSS）是一个受欢迎的开源API网关，因为它界面流畅、社区活跃、云原生架构和广泛的功能。它速度极快，重量轻。Kong还为许多流行的基于容器和云的环境提供了现成的部署，从Docker到Kubernetes再到AWS。这使您可以轻松地将Kong集成到现有的工作流程中，从而使学习曲线不那么陡峭。

Kong支持日志记录、身份验证、速率限制、故障检测等。更好的是，它有自己的CLI，因此您可以直接从命令行管理Kong并与之交互。您可以在各种发行版上安装开源社区Kong Gateway。基本上，Kong拥有API网关所需的一切。

Tyk Open-Source API Gateway

Tyk被称为“行业最佳API网关”。与我们列表中的其他API网关不同，Tyk确实是开源的，而不仅仅是开放核心或免费增值。它为开源解决方案提供了一系列令人印象深刻的特性和功能。和Kong一样，Tyk也是云原生的，有很多插件可用。Tyk甚至可以用于以REST和GraphQL格式发布自己的API。

Tyk对许多功能都有本机支持，包括各种形式的身份验证、配额、速率限制和版本控制。它甚至可以生成API文档。最令人印象深刻的是，Tyk提供了一个API开发者门户，允许您发布托管API，因此第三方可以注册您的API，甚至管理他们的API密钥。Tyk通过其开源API网关提供了如此多的功能，实在令人难以置信。

KrakenD Open-Source API Gateway

KrakenD的开源API网关是在Go中编写的，它有几个显著的特点，尤其是对微服务的优化。它的可移植性和无状态性是其他强大的卖点，因为它可以在任何地方运行，不需要数据库。由于KrakenDesigner，它比我们列表中的其他一些API网关更灵活、更易于接近，这是一个GUI，它可以让您直观地设计或管理API。您还可以通过简单地编辑JSON文件轻松地编辑API。

KrakenD包括速率限制、过滤、缓存和授权等基本功能，并且提供了比我们提到的其他API网关更多的功能。在不修改源代码的情况下，可以使用许多插件和中间件。它的效率也很高-据维护人员称，KrakenD的吞吐量优于Tyk和Kong的其他API网关。它甚至具有本地GraphQL支持。所有这些，KrakenD的网关非常值得一看。

Gravitee OpenSource API Management

Gravite.io是另一个API网关，它具有一系列令人印象深刻的功能，这次是用Java编写的。Gravitee有三个模块用于发布、监控和记录API：

• 
  

  API管理（APIM）：APIM是一个开源模块，可以让您完全控制谁访问您的API以及何时何地。

  
  


• 
  

  访问管理（AM）：Gravite为身份和访问管理提供了一个本地开源授权解决方案。它基于OAuth 2.0/OpenID协议，具有集中的身份验证和授权服务。

  
  


• 
  

  警报引擎（AE）：警报引擎是一个用于监视API的模块，允许您自定义多渠道通知，以提醒您可疑活动。

  
  

Gravitee还具有API设计器Cockpit和命令行界面graviteio-cli。所有这些都使Gravitee成为最广泛的开源API网关之一。您可以在GitHub上查看Gravite.io OpenSource API管理，或直接下载AWS、Docker、Kubernetes、Red Hat，或在此处作为Zip文件。

Apinto Microservice Gateway

显然，Go是编写API网关的流行语言。Apinto API网关用Go编写，旨在管理微服务，并提供API管理所需的所有工具。它支持身份验证、API安全以及流控制。

Apinto支持HTTP转发、多租户管理、访问控制和API访问管理，非常适合微服务或具有多种类型用户的任何开发项目。Apinto还可以通过多功能的用户定义插件系统轻松地为特定用户定制。它还具有API健康检查和仪表板等独特功能。

Apinto Microservice针对性能进行了优化，具有动态路由和负载平衡功能。根据维护人员的说法，Apinto比Nginx或Kong快50%。

Apache APISIX API Gateway

我们将使用世界上最大的开源组织之一Apache软件基金会的一个开源API网关来完善我们的开源API网关列表。Apache APISIX API网关是另一个云原生API网关，具有您目前已经认识到的所有功能——负载平衡、身份验证、速率限制和API安全。然而，有一些特殊的功能，包括多协议支持和Kubernetes入口控制。

关于开源API网关的最后思考

不受限制、不受限制的API访问时代已经结束。随着API使用的广泛普及，有无数理由实现API网关以实现安全性，因为不正确暴露的API端点可能会造成严重损害。API网关可以帮助围绕API设置速率限制，以确保安全使用。而且，如果您向第三方供应商支付高昂的价格，开源选项可能会减少您的每月IT预算。

总之，API网关为您的API环境添加了一个重要的抽象层，这可能是它们最有用的功能。这样的抽象层是防止API端点和用户数据不当暴露的一些最佳方法。然而，几乎同样重要的是它为您的API增加了灵活性。

如果没有抽象层，即使对后端的微小更改也可能导致下游的严重破坏。添加API网关可以使敏捷框架受益，并有助于

前言

距离上一次的年中总结已经过去了一年，来深圳的日子也即将一年过半，看了看去年的年终总结，基本上已经全部完成，除了依然没吃胖点，反而有了两三次低血糖之外(T＿T)。

工作

去年2月26上完最后一天班晚上到的深圳，3月8号来现在的公司入职（印象比较深是因为入职当天有500的女神节红包，哈哈哈）。

今年年初的时候，公司换了办公地方，再也不用过地铁转公交的日子了(^▽^)，现在可以从坪洲坐8站直接到深大，通勤时间少了一点；

年后陆陆续续做了三四个公司内部用的系统，用到了一个腾讯的UI框架，使用感还不错，顺便学习了TDesign 提供了一个脚手架 tdesign-starter-cli，通过它来初始化项目，有兴趣的可以看看（新手不会搭建脚手架的可以做个参考）。

上个月调薪（10%），虽然没有预期的涨薪幅度高，不过涨了总比不涨好（O(∩_∩)O哈哈哈~），经过一次涨薪，也明白了这个涨薪幅度跟什么有直接的关系，如果明年年初不跳槽的话，到年中的时候能涨个15%吧，虽然不多，但是福利好，工作不多，不加班，如果明年离职，掘友们有兴趣的话，可以来找我内推(^▽^)。

学习

今年在一边工作之余，也一直有在坚持学习，当然有时候还是会摸鱼偷懒（捂嘴笑（^▽^））。

1. 
   

   收货

   
   
   
   
   • 输出30余篇文章（不过写的水平很一般，基本上都是记录自己的学习，没有给广大掘友带来什么收货）
   
   
   • 学习了vue3
   
   
   • 学习了react（不精通）
   
   
   • 学习了react native（为了接项目挣钱）
   
   
   • 接了个小程序的项目，顺道回顾了小程序的写法（长时间不写，真的会忘记）
   
   
   
   


2. 
   

   不足

   
   
   
   
   • 学习的vue3一直拖延重构，没有实际用到项目中去
   
   
   • react前面学着，后面忘着（记性真的差）
   
   
   
   

生活

早上一口气写完了这半年的工作和学习，到了生活这里，好像卡壳了——

1. 
   

   吐槽

   
   

   好像没什么说的，又好像想说的很多，今年这半年，是对这慢无休止的疫情最烦闷最讨厌的半年，马上快八月了，核酸做的已经变得麻木，想必辛苦做核酸的护士们也麻木了吧，这么热的天气做的一次比一次敏捷（敷衍），从年后回到深圳，基本上一天一做，最少的时候三天要做一次。

   
   

   后来上海疫情爆发，封城，看着曾经的朋友们封城后的生活，心情五味杂陈，难以言说（此处省略500字）。

   
   

   吐槽结束，把刚刚的丧收起来。

   
   


2. 
   

   平淡

   
   

   其实除了疫情，无休止的核酸，就是工作，出租屋两点一线的平淡了；趁着清明，和朋友们一起自驾游了一次，我是纯游，因为有俩司机开车，哈哈哈哈。在五一也去了一直没去的珠海玩了一趟，虽然上了外伶仃岛，被困在岛上了，但在海边，心情真的有被治愈。

   
   

   图片放到文章最后啦！

   
   

总结

曾经看到的一句话：

生活可以忙忙碌碌随大流，思想必须偷偷摸摸求上进

其实以前挺不喜欢这种生活方式的，后来发现自己也是这样的活着，还是和去年文章中一句话说的那样：

行到水穷处，坐看云起时是选择，卧薪尝胆，三千越甲可吞吴也是选择，怎么选，都有理，怎么选，都对

因为我们都在为自己想要的生活，或努力或躺平着。

接下来，还是该工作工作，该学习学习，该玩玩，该吃吃，该喝喝。

晒图

1. 清明——潮州-南澳岛
   

2. 五一——珠海-外伶仃岛

3. 吃吃喝喝

一个月前我曾撰文《使用batik在kotlin中将TTF字体转换为SVG图像》，介绍了如何将汉字转为SVG Path路径进行展示和变换，以此为基础不妨畅想一下，用动画将一个汉字变为另一个汉字，听上去是不是很简单呢？下面动手实践一下：

我随便找了一个字体Aa剑豪体，然后随机选取了两个汉字：鼠和鸭，再用上文提到的文章介绍的提取整体字形区块方法取出了SVG：

可以看到很简单就提取出了两个字整体的字形，下面用D3做一个简单的变换动画展示：

初始变换

<!DOCTYPE html>

<html lang="en">

	<head>

		<meta charset="UTF-8" />

		<meta http-equiv="X-UA-Compatible" content="IE=edge" />

		<title>鼠鼠我鸭</title>

	</head>

	<body style="text-align: center"></body>

	<script src="https://d3js.org/d3.v7.min.js"></script>

	<script type="module">

		const _svg = d3

                    .select("body")

                    .append("svg")

                    .attr("width", "1000")

                    .attr("height", "1000")

                    .style("zoom", "0.3")

                    .style("transform", "rotateX(180deg)");

		_svg.append("g")

                    .attr("transform", "translate(0, 160)")

                    .append("path")

                    .attr("fill", "#3fd")

                    .attr("stroke", "black")

                    .attr("stroke-width", "4")

                    .attr("d", 上面提到的鼠的SVG_Path...)

                    .transition().delay(1000).duration(1200)

                    .attr("fill", "#ef2")

                    .attr("d", 上面提到的鸭的SVG_Path...);

	</script>

</html>

这里调整了svg尺寸以及zoom、transform等属性更好的适应画面，还做了个g标签套住并将定位交给它，动画效果如下图所示：

很明显的看到，效果非常奇怪，怎么一开始就突然变得很乱？一开始乱这一下显得很突兀，这是因为两段图像的path长度就相差很多，绘进方式也完全不一样，很难真正的渐变过去，我试了一个有优化此过程的库d3-interpolate-path，用上去效果也没有什么差别，而且它用的还是d3@v5版本的，不知道怎么path中还会穿插一些NaN的值，很怪异，看来只能自己做了。

想真正的点对点的渐移过去，可能还是有些难的，所以我想出了一个较为简单的方案，实现一种队列式的效果，鼠的笔画慢慢消失，而鸭则跟随在后面逐步画出，实现一种像队列中常说的FIFO(先进先出)的效果

首先就是拆解，做一个while拆分两个字所有的节点，然后再一步步绘上拆出来的节点以验证拆的是否完整，再才能进行后面的处理。

事先要将“鸭鼠”各自的path定义为常量source、result，将二者开头的M与结尾的Z都去掉（中间的M不要去掉），因为动画中字形是流动的，起止点不应提前定义。

拆分路径点

const source = 鼠的SVG_Path(没有MZ)...

const result = 鸭的SVG_Path(没有MZ)...

const actionReg = new RegExp(/[a-z]/, "gi");

const data = new Array();

let match;

let lastIndex;

while ((match = actionReg.exec(result))) {

        data.push(result.substring(lastIndex, match.index));

        lastIndex = match.index;

}

data.push(result.substring(lastIndex));

就这样就能把鼠的部分拆开了，先直接累加到试验一下是否成功：

叠加试验

let tran = g

        .append("path")

        .attr("fill", "red")

        .attr("stroke", "black")

        .attr("stroke-width", "4")

        .attr("d", "M" + source + "Z")

        .transition()

        .delay(800);



let step = "L";

data.map(item => {

        step += item + " ";

        tran = tran.transition().attr("d", "M" + source + step.trimEnd() + "Z").duration(20);

});

首先是把上面path独立出来改一改，变成红色的利于观看，然后下面慢慢的拼合上每个节点，效果如下：

是理想中的效果，那么下一步就是加速FIFO先进先出的变换了：

FIFO先进先出

这一步是不能用SVG动画的，要用setInterval定时器进行动画调节，SVG始终还是只能处理很简单的path变化，效果不如直接变来的好，这里设计成把每一帧的动画存进一个方法数组然后交给setInterval计时器循环执行（写起来比较方便），先是改一下tran的定义，因为不是动画了，所以现在改叫path就好了，border也不需要了：

let path = g

        .append("path")

        .attr("fill", "red")

        .attr("d", "M" + source + "Z");

就这样简单的初始化一下就好了，然后就是最核心的一个过程，path的绘制循序就像一个FIFO队列：

let step = "";

let pre = source;

const funs = new Array();

data.map(async function (item, i) {

        step += item + " ";

        match = pre && actionReg.exec(source);

        if (!match) {

                pre = "";

        } else if (~["M", "L", "T"].indexOf(match[0])) {

                pre = source.substring(match.index + 1);

        }

        const d = "M" + pre + (pre ? "L" : "") + step.trimEnd() + "Z";

        funs.push(() => path.attr("d", d));

});

首先是pre负责鼠的字形，这个字形是要慢慢消失的前部，这个前部不是所有的节点都能用的，而是"M", "L", "T"这种明确有点位的动作才行，毕竟这是动画的起始点。然后step就是代表鸭，要一步一步累加。循环结束funs数组也就累计好了所有的帧(方法)，然后用定时器执行这些带参方法即可：

const animation = setInterval(() => {

        if (!funs.length) {

                clearInterval(animation);

                return;

        }

        funs.shift()();

}, 20);

这种方式虽然非常少见，不过这个定时器流程还是很好理解的过程，效果如下：

是想象中的效果，但稍微有些单调，可以加上一段摇摆的动画配合变换：

摇摆动画

let pathTran = path;

Array(8)

    .fill(0)

    .map(function () {

        pathTran = pathTran

            .transition()

            .attr("transform", "skewX(10)")

            .duration(300)

            .transition()

            .attr("transform", "skewX(-10)")

            .duration(300);

    });

pathTran.transition().attr("transform", "").duration(600);

这段动画要不断赋值才能形成连贯动画，所以直接用path处理动画是不行的，因为上面计时器也是用到这个path对象，所以要额外定义一个pathTran专门用于动画，这段摇摆动画效果如下：

时间掐的刚刚好，那边计时器停掉，这边摇摆动画也缓停了。

写的十分简便，一点小创

闲来无事研究了百度图像识别 API，发现该功能还算强大，在此将其使用方法总结成教程，提供大家学习参考

首先预览下效果

从以上预览图中可看出，每张图片识别出5条数据，每条数据根据识别度从高往下排，每条数据包含物品名称、识别度、所属类目

准备工作

1、注册百度账号

2、登录百度智能云控制台

3、在产品列表中找到 人工智能->图像识别

4、点击创建应用，如下图：

已创建好的应用列表

代码部分

1、获取access_token值

注意：使用图像识别需用到access_token值，因此需先获取到，以便下面代码的使用

access_token获取的方法有多种，这里使用PHP获取，更多有关access_token获取的方法以及说明可查看官方文档：

ai.baidu.com/docs#/Auth/…

创建一个get_token.php文件，用来获取access_token值

PHP获取access_token代码示例：

<?php



    //请求获取access_token值函数

    function request_post($url = '', $param = '') {



            if (empty($url) || empty($param)) {

                return false;

            }



            $postUrl = $url;

            $curlPost = $param;

            $curl = curl_init();//初始化curl

            curl_setopt($curl, CURLOPT_URL,$postUrl);//抓取指定网页

            curl_setopt($curl, CURLOPT_HEADER, 0);//设置header

            curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);//要求结果为字符串且输出到屏幕上

            curl_setopt($curl, CURLOPT_POST, 1);//post提交方式

            curl_setopt($curl, CURLOPT_POSTFIELDS, $curlPost);

            curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);

            $data = curl_exec($curl);//运行curl

            curl_close($curl);



            return $data;

        }



    $url = 'https://aip.baidubce.com/oauth/2.0/token';                //固定地址

    $post_data['grant_type']       = 'client_credentials';            //固定参数

    $post_data['client_id']      = '你的 Api Key';                    //创建应用的API Key；

    $post_data['client_secret'] = '你的 Secret Key';                //创建应用的Secret Key；

    $o = "";

    foreach ( $post_data as $k => $v ) 

    {

        $o.= "$k=" . urlencode( $v ). "&" ;

    }

    $post_data = substr($o,0,-1);



    $res = request_post($url, $post_data);//调用获取access_token值函数



    var_dump($res);



?>

返回的数据如下，红框内的就是我们所要的access_token值

2、图片上传及识别

2.1、在项目的根目录下创建一个upload文件夹，用于存放上传的图片

2.2、创建一个index.html文件，用于上传图片及数据渲染

代码如下：

<!DOCTYPE html>  

<html>  

<head>  

<meta charset="utf-8">   

<title>使用百度 API 实现图像识别</title>   

<style type="text/css">  

  .spanstyle{  

    display:inline-block;  

    width:500px;  

    height:500px;  

    position: relative;  

  }  

</style>  

<script src="https://cdn.bootcss.com/jquery/1.10.2/jquery.min.js"></script>  

  

<script>  

  

  function imageUpload(imgFile) {  

  

    var uploadfile= imgFile.files[0]  //获取图片文件流  

  

    var formData = new FormData();    //创建一个FormData对象  

  

    formData.append('file',uploadfile);  

    //将图片放入FormData对象对象中（由于图片属于文件格式，不能直接将文件流直接通过ajax传递到后台，需要放入FormData对象中。在传递）  

  

    $("#loading").css("opacity",1);  

  

  

     $.ajax({  

          type: "POST",       //POST请求  

          url: "upload.php",  //接收图片的地址（同目录下的php文件）  

          data:formData,      //传递的数据  

          dataType:"json",    //声明成功使用json数据类型回调  

  

          //如果传递的是FormData数据类型，那么下来的三个参数是必须的，否则会报错  

          cache:false,  //默认是true，但是一般不做缓存  

          processData:false, //用于对data参数进行序列化处理，这里必须false；如果是true，就会将FormData转换为String类型  

          contentType:false,  //一些文件上传http协议的关系，自行百度，如果上传的有文件，那么只能设置为false  

  

         success: function(msg){  //请求成功后的回调函数  

  

  

              console.log(msg.result)  

  

              //预览上传的图片  

              var filereader = new FileReader();  

              filereader.onload = function (event) {  

                  var srcpath = event.target.result;  

                  $("#loading").css("opacity",0);  

                  $("#PreviewImg").attr("src",srcpath);  

                };  

              filereader.readAsDataURL(uploadfile);  

  

  

                //将后台返回的数据进行进一步处理  

                var data=  '<li style="margin:2% 0"><span>物品名称：'+msg.result[0].keyword+';</span> <span style="padding: 0 2%">识别度：'+msg.result[0].score*100+'%'+';</span><span>所属类目：'+msg.result[0].root+';</span></li>'  

  

                data=data+  '<li style="margin:2% 0"><span>物品名称：'+msg.result[1].keyword+';</span> <span style="padding: 0 2%">识别度：'+msg.result[1].score*100+'%'+';</span><span>所属类目：'+msg.result[1].root+';</span></li>'  

  

                data=data+  '<li style="margin:2% 0"><span>物品名称：'+msg.result[2].keyword+';</span> <span style="padding: 0 2%">识别度：'+msg.result[2].score*100+'%'+';</span><span>所属类目：'+msg.result[2].root+';</span></li>'  

  

                data=data+  '<li style="margin:2% 0"><span>物品名称：'+msg.result[3].keyword+';</span> <span style="padding: 0 2%">识别度：'+msg.result[3].score*100+'%'+';</span><span>所属类目：'+msg.result[3].root+';</span></li>'  

  

  

                data=data+  '<li style="margin:2% 0"><span>物品名称：'+msg.result[4].keyword+';</span> <span style="padding: 0 2%">识别度：'+msg.result[4].score*100+'%'+';</span><span>所属类目：'+msg.result[4].root+';</span></li>'  

  

  

  

                //将识别的数据在页面渲染出来  

               $("#content").html(data);  

  

  

        }  

  });  

  

  

   }  

  

  

  

</script>  

</head>  

<body>  

  

  <fieldset>  

     <input type="file"  onchange="imageUpload(this)" >  

     <legend>图片上传</legend>  

  </fieldset>  

  

  

  

<div style="margin-top:2%">  

    <span class="spanstyle">  

      <img id="PreviewImg" src="default.jpg" style="width:100%;max-height:100%"  >  

      <img id="loading" style="width:100px;height:100px;top: 36%;left: 39%;position: absolute;opacity: 0;" src="loading.gif" >  

    </span>  

  

  

    <span class="spanstyle" style="vertical-align: top;border: 1px dashed #ccc;background-color: #4ea8ef;color: white;">  

        <h4 style="padding-left:2%">识别结果：</h4>  

        <ol style="padding-right: 20px;" id="content">  

  

        </ol>  

    </span>  

  

</div>  

  

  

  

</body>  

</html>

2.3、创建一个upload.php文件，用于接收图片及调用图像识别API

备注：百度图像识别API接口有多种，这里使用的是【通用物体和场景识别高级版】 ；该接口支持识别10万个常见物体及场景，接口返回大类及细分类的名称结果，且支持获取图片识别结果对应的百科信息

该接口调用的方法也有多种，这里使用PHP来调用接口，更多有关通用物体和场景识别高级版调用的方法以及说明可查看官方文档：

ai.baidu.com/docs#/Image…

PHP请求代码示例：

<?php  

  

        //图像识别请求函数      

        function request_post($url = '', $param = ''){  

  

            if (empty($url) || empty($param)) {  

                return false;  

            }  

  

            $postUrl = $url;  

            $curlPost = $param;  

            // 初始化curl  

            $curl = curl_init();  

            curl_setopt($curl, CURLOPT_URL, $postUrl);  

            curl_setopt($curl, CURLOPT_HEADER, 0);  

            // 要求结果为字符串且输出到屏幕上  

            curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);  

            curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);  

            // post提交方式  

            curl_setopt($curl, CURLOPT_POST, 1);  

            curl_setopt($curl, CURLOPT_POSTFIELDS, $curlPost);  

            // 运行curl  

            $data = curl_exec($curl);  

            curl_close($curl);  

  

            return $data;  

        }  

  

        $temp = explode(".", $_FILES["file"]["name"]);  

        $extension = end($temp);     // 获取图片文件后缀名  

  

  

        $_FILES["file"]["name"]=time().'.'.$extension;//图片重命名（以时间戳来命名）  

  

        //将图片文件存在项目根目录下的upload文件夹下  

        move_uploaded_file($_FILES["file"]["tmp_name"], "upload/" . $_FILES["file"]["name"]);  

  

  

        $token = '调用鉴权接口获取的token';//将获取的access_token值放进去  

        $url = 'https://aip.baidubce.com/rest/2.0/image-classify/v2/advanced_general?access_token=' . $token;  

        $img = file_get_contents("upload/" . $_FILES["file"]["name"]);//本地文件路径（存入后的图片文件路径）  

        $img = base64_encode($img);//文件进行base64编码加密  

  

        //请求所需要的参数  

        $bodys = array(  

            'image' => $img,//Base64编码字符串  

            'baike_num'=>5  //返回百科信息的结果数 5条  

        );  

        $res = request_post($url, $bodys);//调用请求函数  

  

        echo $res;  //将识别的数据输出到前端  

  

  

?>

结语补充

在实际开发过程中，获取access_token值并不是单独写成一个页面文件，而是写在项目系统的配置中；由于access_token值有效期为30天，可通过判断是否失效，来重新请求acc

今天我来解释一下什么样的代码才是优雅的代码设计。当然我们的代码根据实际的应用场景也分了很多维度，有偏向于底层系统的，有偏向于中间件的，也有偏向上层业务的，还有偏向于前端展示的。今天我主要来跟大家分析一下我对于业务代码的理解以及什么样才是我认为的优雅的业务代码设计。

大家吐槽非常多的是，我们这边的业务代码会存在着大量的不断地持续的变化，导致我们的程序员对于业务代码设计得就比较随意。往往为了快速上线随意堆叠，不加深入思考，或者是怕影响到原来的流程，而不断在原来的代码上增加分支流程。

这种思想进一步使得代码腐化，使得大量的程序员更失去了“好代码”的标准。

那么如果代码优雅，那么要有哪些特征呢？或者说我们做哪些事情才会使得代码变得更加优雅呢？

结构化

结构化定义是指对某一概念或事物进行系统化、规范化的分析和定义，包括定义的范围、对象的属性、关系等方面，旨在准确地描述和定义所要表达的概念或事物。

我觉得首要的是代码，要一个骨架。就跟我们所说的思维结构是一样，我们对一个事物的判断，一般都是综合、立体和全面的，否则就会成为了盲人摸象，只见一斑。因此对于一个事物的判断，要综合、结构和全面。对于一段代码来说也是一样的标准，首先就是结构化。结构化是对一段代码最基本的要求，一个有良好结构的代码才可能称得上是好代码，如果只是想到哪里就写到哪里，一定成不了最优质的代码。

代码的结构化，能够让维护的人一眼就能看出主次结构、看出分层结构，能够快速掌握一段代码或者一段模块要完成的核心事情。

精简

代码跟我们抽象现实的物体一样，也要非常地精简。其实精简我觉得不仅在代码，在所有艺术品里面都是一样的，包括电影。电影虽然可能长达一个小时，两个小时，但你会发现优雅的电影它没有一帧是多余的，每出现的一个画面、一个细节，都是电影里要表达的某个情绪有关联。我们所说的文章也是一样，没有任何一个伏笔是多余的。代码也是一样，严格来说代码没有一个字符、函数、变量是多余的，每个代码都有它应该有的用处。就跟“奥卡姆剃刀”原理一样，每块代码都有它存在的价值包括注释。

但正如我们的创作一样，要完成一个功能，我们把代码写得复杂是简单的，但我们把它写得简单是非常难的。代码是思维结构的一种体现，而往往抽象能力是最为关键的，也是最难的。合适的抽象以及合理的抽象才能够让代码浓缩到最少的代码函数。

大部分情况来说，代码行数越少，则运行效率会越高。当然也不要成为极端的反面例子，不要一味追求极度少量的代码。代码的优雅一定是精要的，该有的有，不该有的一定是没有的。所以在完成一个业务逻辑的时候，一定要多问自己这个代码是不是必须有的，能不能以一种简要的方式来表达。

善用最佳实践

俗话说太阳底下没有新鲜事儿，一般来说，没有一个业务场景所需要用到的编码方式是需要你独创发明的。你所写的代码功能大概率都有人遇到过，因此对于大部分常用的编码模式，也都大家被抽象出来了一些最佳实践。那么最经典的就是23种设计模式，基本上可以涵盖90%以上的业务场景了。

以下是23种设计模式的部分简单介绍：

1. 单例模式（Singleton Pattern）：确保类只有一个实例，并提供全局访问点。
2. 工厂模式（Factory Pattern）：定义一个用于创建对象的接口，并让子类决定实例化哪个对象。
3. 模板方法模式（Template Method Pattern）：提供一种动态的创建对象的方法，通过使用不同的模板来创建对象。
4. 装饰器模式（Decorator Pattern）：将对象包装成另一个对象，从而改变原有对象的行为。
5. 适配器模式（Adapter Pattern）：将一个类的接口转换成客户希望的另一个接口，以使其能够与不同的对象交互。
6. 外观模式（Facade Pattern）：将对象的不同方面组合成一个单一的接口，从而使客户端只需访问该接口即可使用整个对象。

我们所说的设计模式就是一种对常用代码结构的一种抽象或者说套路。并不是说我们一定要用设计模式来实现功能，而是说我们要有一种最高效，最通常的方式去实现。这种方式带来了好处就是高效，而且别人理解起来也相对来说比较容易。

我们也不大推荐对于一些常见功能用一些花里胡哨的方式来实现，这样往往可能导致过度设计，但实际用处可能反而会带来其他问题。我觉得要用一些新型的代码，新型的思维方式应该是在一些比较新的场景里面去使用，去验证，而不应该在我们已有最佳实践的方式上去造额外的轮子。

这个就比如我们如果要设计一辆汽车，我们应该采用当前最新最成熟的发动机方案，而不应该从零开始自己再造一套新的发动机。但是如果这个发动机是在土星使用，要面对极端的环境，可能就需要基于当前的方案研制一套全新的发动机系统，但是大部分人是没有机会碰到土星这种业务环境的。所以通常情况下，还是不要在不需要创新的地方去创新。

除了善用最佳实践模式之快，我们还应该采用更高层的一些最佳实践框架的解决方案。比如我们在面对非常抽象，非常灵活变动的一些规则的管理上，我们可以使用大量的规则引擎工具。比如针对于流程式的业务模型上面，我们可以引入一些工作流的引擎。在需要RPC框架的时候，我们可以根据业务情况去调研使用HTTP还是DUBBO，可以集百家之所长。

持续重构

好代码往往不是一蹴而就的，而是需要我们持续打磨。有很多时候由于业务的变化以及我们思维的局限性，我们没有办法一次性就能够设计出最优的代码质量，往往需要我们后续持续的优化。所以除了初始化的设计以外，我们还应该在业务持续的发展过程中动态地去对代码进行重构。

但是往往程序员由于业务繁忙或者自身的懒惰，在业务代码上线正常运行后，就打死不愿意再动原来的代码。第一个是觉得跑得没有问题了何必去改，第二个就是改动了反而可能引起故障。这就是一种完全错误的思维，一来是给自己写不好的线上代码的一个借口，二来是没有让自己持续进步的机会。

代码重构的原则有很多，这里我就不再细讲。但是始终我觉得对线上第一个要敬畏，第二个也要花时间持续续治理。往往我们在很多时候初始化的架构是比较优雅的，是经过充分设计的，但是也是由于业务发展的迭代的原因，我们持续在存量代码上添加新功能。

有时候有一些不同的同学水平不一样，能力也不一样，所以导致后面写上的代码会非常地随意，导致整个系统就会变得越来越累赘，到了最后就不敢有新同学上去改，或者是稍微一改可能就引起未知的故障。

所以在这种情况下，如果还在追求优质的代码，就需要持续不断地重构。重构需要持续改善，并且最好每次借业务变更时，做小幅度的修改以降低风险。长此以往，整体的代码结构就得以大幅度的修改，真正达到集腋成裘的目的。下面是一些常见的重构原则：

1. 单一职责原则：每个类或模块应该只负责一个单一的任务。这有助于降低代码的复杂度和维护成本。
2. 开闭原则：软件实体（类、模块等）应该对扩展开放，对修改关闭。这样可以保证代码的灵活性和可维护性。
3. 里氏替换原则：任何基类都可以被其子类替换。这可以减少代码的耦合度，提高代码的可扩展性。
4. 接口隔离原则：不同的接口应该是相互独立的，它们只依赖于自己需要的实现，而不是其他接口。
5. 依赖倒置原则：高层模块不应该依赖低层模块，而是依赖应用程序的功能。这可以降低代码的复杂度和耦合度。
6. 高内聚低耦合原则：尽可能使模块内部的耦合度低，而模块之间的耦合度高。这可以提高代码的可维护性和可扩展性。
7. 抽象工厂原则：使用抽象工厂来创建对象，这样可以减少代码的复杂度和耦合度。
8. 单一视图原则：每个页面只应该有一个视图，这可以提高代码的可读性和可维护性。
9. 依赖追踪原则：对代码中的所有依赖关系进行跟踪，并在必要时进行修复或重构。
10. 测试驱动开发原则：在编写代码之前编写测试用例，并在开发过程中持续编写和运行测试用例，以确保代码的质量和稳定性。

综合

综上所述，代码要有结构化、可扩展、用最佳实践和持续重构。追求卓越的优质代码应该是每一位工程师的基本追求和基本要求，只有这样，才能不断地使得自己成为一名卓越的工程师。

提到实事求是，大家第一时间会想到什么？我想大部分是客观，事实，脚踏实地？这么一想，大家都会觉得，自己挺实事求是的呀，没毛病。但是，我会经常在工作中感受到不是那么实事求是的行为，比如张嘴就来，不带思考，做事全靠猜的行为，真太多了。

随着我这两年的学习和总结，我越发觉得实事求是非常重要，并把它视为我做事情和成长的基石。对于实事求是，我主要有以下 3 层理解。

首先，尊重客观事实，探寻真理。我们要承认事实，即使这个事实有多么的难以置信，但存在即是合理，我们首先要尊重它，承认它。然后我们还要积极主动地面对它，探寻事实背后的真理，获得真知，这样才能真正的成长，并有可能寻得机会。当某个事情的进展超出自己预期的时候，我们正确的态度应该是思考为什么会这样，而不是去想对错得失。

其次，数据说话，数据驱动。事实如何去量化？答案是数据。使用数据去表达事实，是我们程序员应该有的技能。工作的本质就是解决问题，之前的文章有讲解，问题就是理想状态和现实状态之间的差别，因此，我们在工作当中做的每一项决策的依据、制定的每一个目标，都应该用数据说话。我们应该使用数据表达现状，并使用数据衡量目标，驱动自己去工作。一些沟通的细节就能够体现出他是不是在实事求是地工作，比如“这个页面加载太慢了，需要优化”。那这个页面加载到底有多慢？业界标准或者竞品的加载耗时是多少？优化的目标值是多少？

最后，从客观事实中获取反馈，不断迭代。工作中想要获得成功和成长，最核心的一个环节是反馈。很多人没有意识到这点。更多的人没有意识到的是，获取反馈其实很简单，随处都是。敏捷开发、精益创业、增长黑客，这些理论的底层核心都是基于事实和数据的反馈，不断迭代改进自己的产品，从而获得成功。对于个人成长来说也是一样的，我们要从客观事实中获取反馈，思考总结，不断迭代自己的能力。

总结一下，实事求是地工作有 3 个层次，首先，要正视事实，并主动探究真理；然后我们慢慢地开始用数据驱动自己的工作；最后让数据驱动变成循环，不断迭代，并把这种循环融入到各个方面，包括工作和个人成长，让它成为自己下意识的动作。

我在努力学习和践行实事求是地工作，我也希望我的团队可以用实事求是的态度来工作，以此文共勉！

什么是 HTTP 长轮询？

Web 应用程序最初是围绕客户端/服务器模型开发的，其中 Web 客户端始终是事务的发起者，向服务器请求数据。因此，没有任何机制可以让服务器在没有客户端先发出请求的情况下独立地向客户端发送或推送数据。

为了克服这个缺陷，Web 应用程序开发人员可以实施一种称为 HTTP长轮询的技术，其中客户端轮询服务器以请求新信息。服务器保持请求打开，直到有新数据可用。一旦可用，服务器就会响应并发送新信息。客户端收到新信息后，立即发送另一个请求，重复上述操作。

什么是 HTTP 长轮询？

那么，什么是长轮询？HTTP 长轮询是标准轮询的一种变体，它模拟服务器有效地将消息推送到客户端（或浏览器）。

长轮询是最早开发的允许服务器将数据“推送”到客户端的技术之一，并且由于其寿命长，它在所有浏览器和 Web 技术中几乎无处不在。即使在一个专门为持久双向通信设计的协议（例如 WebSockets）的时代，长轮询的能力仍然作为一种无处不在的回退机制占有一席之地。

HTTP 长轮询如何工作？

要了解长轮询，首先要考虑使用 HTTP 的标准轮询。

“标准”HTTP 轮询

HTTP 轮询由客户端（例如 Web 浏览器）组成，不断向服务器请求更新。

一个用例是想要关注快速发展的新闻报道的用户。在用户的浏览器中，他们已经加载了网页，并希望该网页随着新闻报道的展开而更新。实现这一点的一种方法是浏览器反复询问新闻服务器“内容是否有任何更新”，然后服务器将以更新作为响应，或者如果没有更新则给出空响应。浏览器请求更新的速率决定了新闻页面更新的频率——更新之间的时间过长意味着重要的更新被延迟。更新之间的时间太短意味着会有很多“无更新”响应，从而导致资源浪费和效率低下。

上图：Web 浏览器和服务器之间的 HTTP 轮询。服务器向立即响应的服务器发出重复请求。

这种“标准”HTTP 轮询有缺点：

• 更新请求之间没有完美的时间间隔。请求总是要么太频繁（效率低下）要么太慢（更新时间比要求的要长）。


• 随着规模的扩大和客户端数量的增加，对服务器的请求数量也会增加。由于资源被无目的使用，这可能会变得低效和浪费。

HTTP 长轮询解决了使用 HTTP 进行轮询的缺点

1. 请求从浏览器发送到服务器，就像以前一样


2. 服务器不会关闭连接，而是保持连接打开，直到有数据供服务器发送


3. 客户端等待服务器的响应。


4. 当数据可用时，服务器将其发送给客户端


5. 客户端立即向服务器发出另一个 HTTP 长轮询请求

上图：客户端和服务器之间的 HTTP 长轮询。请注意，请求和响应之间有很长的时间，因为服务器会等待直到有数据要发送。

这比常规轮询更有效率。

• 浏览器将始终在可用时接收最新更新


• 服务器不会被永远无法满足的请求所搞垮。

长轮询有多长时间？

在现实世界中，任何与服务器的客户端连接最终都会超时。服务器在响应之前保持连接打开的时间取决于几个因素：服务器协议实现、服务器体系结构、客户端标头和实现（特别是 HTTP Keep-Alive 标头）以及用于启动的任何库并保持连接。

当然，许多外部因素也会影响连接，例如，移动浏览器在 WiFi 和蜂窝连接之间切换时更有可能暂时断开连接。

通常，除非您可以控制整个架构堆栈，否则没有单一的轮询持续时间。

使用长轮询时的注意事项

在您的应用程序中使用 HTTP 长轮询构建实时交互时，需要考虑几件事情，无论是在开发方面还是在操作/扩展方面。

• 随着使用量的增长，您将如何编排实时后端？


• 当移动设备在WiFi和蜂窝网络之间快速切换或失去连接，IP地址发生变化时，长轮询会自动重新建立连接吗？


• 通过长轮询，您能否管理消息队列并如何处理丢失的消息？


• 长轮询是否提供跨多个服务器的负载平衡或故障转移支持？

在为服务器推送构建具有 HTTP 长轮询的实时应用程序时，您必须开发自己的通信管理系统。这意味着您将负责更新、维护和扩展您的后端基础设施。

服务器性能和扩展

使用您的解决方案的每个客户端将至少每 5 分钟启动一次与您的服务器的连接，并且您的服务器将需要分配资源来管理该连接，直到它准备好满足客户端的请求。一旦完成，客户端将立即重新启动连接，这意味着实际上，服务器将需要能够永久分配其资源的一部分来为该客户端提供服务。当您的解决方案超出单个服务器的能力并且引入负载平衡时，您需要考虑会话状态——如何在服务器之间共享客户端状态？您如何应对连接不同 IP 地址的移动客户端？您如何处理潜在的拒绝服务攻击？

这些扩展挑战都不是 HTTP 长轮询独有的，但协议的设计可能会加剧这些挑战——例如，您如何区分多个客户端发出多个真正的连续请求和拒绝服务攻击？

消息排序和排队

在服务器向客户端发送数据和客户端发起轮询请求之间总会有一小段时间，数据可能会丢失。

服务器在此期间要发送给客户端的任何数据都需要缓存起来，并在下一次请求时传递给客户端。

然后出现几个明显的问题：

• 服务器应该将数据缓存或排队多长时间？


• 应该如何处理失败的客户端连接？


• 服务器如何知道同一个客户端正在重新连接，而不是新客户端？


• 如果重新连接花费了很长时间，客户端如何请求落在缓存窗口之外的数据？

所有这些问题都需要 HTTP 长轮询解决方案来回答。

设备和网络支持

如前所述，由于 HTTP 长轮询已经存在了很长时间，它在浏览器、服务器和其他网络基础设施（交换机、路由器、代理、防火墙）中几乎得到了无处不在的支持。这种级别的支持意味着长轮询是一种很好的后备机制，即使对于依赖更现代协议（如 WebSockets )的解决方案也是如此。

众所周知，WebSocket 实现，尤其是早期实现，在双重 NAT 和某些 HTTP 长轮询运行良

在这篇博客中，我们将分享 10+ 个实用的一行 JavaScript 代码，这些代码可以帮助你提高编码效率和代码简洁度。这些代码片段将涵盖各种用途，从操作数组和字符串，到更高级的概念，如异步编程和面向对象编程。

获取数组中的随机元素

使用 Math.random() 函数和数组长度可以轻松获取数组中的随机元素：

const arr = [1, 2, 3, 4, 5];

const randomElement = arr[Math.floor(Math.random() * arr.length)];

console.log(randomElement);

数组扁平化

使用 reduce() 函数和 concat() 函数可以轻松实现数组扁平化：

const arr = [[1, 2], [3, 4], [5, 6]];

const flattenedArr = arr.reduce((acc, cur) => acc.concat(cur), []);

console.log(flattenedArr); // [1, 2, 3, 4, 5, 6]

对象数组根据某个属性值进行排序

const sortedArray = array.sort((a, b) => (a.property > b.property ? 1 : -1));

从数组中删除特定元素

const removedArray = array.filter((item) => item !== elementToRemove);

检查数组中是否存在重复项

const hasDuplicates = (array) => new Set(array).size !== array.length;

判断数组是否包含某个值

const hasValue = arr.includes(value);

首字母大写

const capitalized = str.charAt(0).toUpperCase() + str.slice(1);

获取随机整数

const randomInt = Math.floor(Math.random() * (max - min + 1)) + min;

获取随机字符串

const randomStr = Math.random().toString(36).substring(2, length);

使用解构和 rest 运算符交换变量的值：

let a = 1, b = 2

[b, a] = [a, b]

console.log(a, b) // 2, 1

将字符串转换为小驼峰式命名：

const str = 'hello world'

const camelCase = str.replace(/\s(.)/g, ($1) => $1.toUpperCase()).replace(/\s/g, '').replace(/^(.)/, ($1) => $1.toLowerCase())

console.log(camelCase) // "helloWorld"

计算两个日期之间的间隔

const diffInDays = (dateA, dateB) => Math.floor((dateB - dateA) / (1000 * 60 * 60 * 24));

查找日期位于一年中的第几天

const dayOfYear = (date) => Math.floor((date - new Date(date.getFullYear(), 0, 0)) / 1000 / 60 / 60 / 24);

复制内容到剪切板

const copyToClipboard = (text) => navigator.clipboard.writeText(text);



copyToClipboard("Hello World");

获取变量的类型

const getType = (variable) => Object.prototype.toString.call(variable).slice(8, -1).toLowerCase();



getType('');     // string

getType(0);      // number

getType();       // undefined

getType(null);   // null

getType({});     // object

getType([]);     // array

getType(0);      // number

getType(() => {});  // function

检测对象是否为空

const isEmptyObject = (obj) => Object.keys(obj).length === 0 && obj.constructor === Object;

作者：shichuan

来源：juejin.cn/post/7230810119122190397

前言

最近有不少前端和测试转Go的朋友在私信我：如何做好表结构设计？

大家关心的问题阳哥必须整理出来，希望对大家有帮助。

先说结论

这篇文章介绍了设计数据库表结构应该考虑的4个方面，还有优雅设计的6个原则，举了一个例子分享了我的设计思路，为了提高性能我们也要从多方面考虑缓存问题。

收获最大的还是和大家的交流讨论，总结一下：

1. 首先，一定要先搞清楚业务需求。比如我的例子中，如果不需要灵活设置，完全可以写到配置文件中，并不需要单独设计外键。主表中直接保存各种筛选标签名称（注意维护的问题，要考虑到数据一致性）
2. 数据库表结构设计一定考虑数据量和并发量，我的例子中如果数据量小，可以适当做冗余设计，降低业务复杂度。

4个方面

设计数据库表结构需要考虑到以下4个方面：

1. 数据库范式：通常情况下，我们希望表的数据符合某种范式，这可以保证数据的完整性和一致性。例如，第一范式要求表的每个属性都是原子性的，第二范式要求每个非主键属性完全依赖于主键，第三范式要求每个非主键属性不依赖于其他非主键属性。
2. 实体关系模型（ER模型）：我们需要先根据实际情况画出实体关系模型，然后再将其转化为数据库表结构。实体关系模型通常包括实体、属性、关系等要素，我们需要将它们转化为表的形式。
   
3. 数据库性能：我们需要考虑到数据库的性能问题，包括表的大小、索引的使用、查询语句的优化等。
   
4. 数据库安全：我们需要考虑到数据库的安全问题，包括表的权限、用户角色的设置等。
   

设计原则

在设计数据库表结构时，可以参考以下几个优雅的设计原则：

1. 简单明了：表结构应该简单明了，避免过度复杂化。
2. 一致性：表结构应该保持一致性，例如命名规范、数据类型等。
   
3. 规范化：尽可能将表规范化，避免数据冗余和不一致性。
   
4. 性能：表结构应该考虑到性能问题，例如使用适当的索引、避免全表扫描等。
   
5. 安全：表结构应该考虑到安全问题，例如合理设置权限、避免SQL注入等。
   
6. 扩展性：表结构应该具有一定的扩展性，例如预留字段、可扩展的关系等。
   

最后，需要提醒的是，优雅的数据库表结构需要在实践中不断迭代和优化，不断满足实际需求和新的挑战。

下面举个示例让大家更好的理解如何设计表结构，如何引入内存，有哪些优化思路：

问题描述

如上图所示，红框中的视频筛选标签，应该怎么设计数据库表结构？除了前台筛选，还想支持在管理后台灵活配置这些筛选标签。

这是一个很好的应用场景，大家可以先自己想一下。不要着急看我的方案。

需求分析

设计思路

表结构设计

视频表

其他和视频直接相关的字段（比如名称）我就省略不写了

类型表

地区表

年份表

原以为年份字段不需要排序，要么是年份正序排列，要么是年份倒序排列，所以不需要sort字段。

仔细看了看需求，还有“10年代”还是需要灵活配置的呀~

演员表

表结构设计完了，别忘了缓存

缓存策略

首先这些不会频繁更新的筛选条件建议使用缓存：

1. 比较常用的就是redis缓存
2. 再进阶一点，如果你使用docker，可以把这些配置信息写入docker容器所在物理机的内存中，而不用请求其他节点的redis，进一步降低网络传输带来的耗时损耗
3. 筛选条件这类配置信息，客户端和服务端可以约定一个更新缓存的机制，客户端直接缓存配置信息，进一步提高性能

列表数据自动缓存

目前很多框架都是支持自动缓存处理的，比如goframe和go-zero

goframe

可以使用ORM链式操作-查询缓存

示例代码：

package main



import (

	"time"



	"github.com/gogf/gf/v2/database/gdb"

	"github.com/gogf/gf/v2/frame/g"

	"github.com/gogf/gf/v2/os/gctx"

)



func main() {

	var (

		db  = g.DB()

		ctx = gctx.New()

	)



	// 开启调试模式，以便于记录所有执行的SQL

	db.SetDebug(true)



	// 写入测试数据

	_, err := g.Model("user").Ctx(ctx).Data(g.Map{

		"name": "xxx",

		"site": "https://xxx.org",

	}).Insert()



	// 执行2次查询并将查询结果缓存1小时，并可执行缓存名称(可选)

	for i := 0; i < 2; i++ {

		r, _ := g.Model("user").Ctx(ctx).Cache(gdb.CacheOption{

			Duration: time.Hour,

			Name:     "vip-user",

			Force:    false,

		}).Where("uid", 1).One()

		g.Log().Debug(ctx, r.Map())

	}



	// 执行更新操作，并清理指定名称的查询缓存

	_, err = g.Model("user").Ctx(ctx).Cache(gdb.CacheOption{

		Duration: -1,

		Name:     "vip-user",

		Force:    false,

	}).Data(gdb.Map{"name": "smith"}).Where("uid", 1).Update()

	if err != nil {

		g.Log().Fatal(ctx, err)

	}



	// 再次执行查询，启用查询缓存特性

	r, _ := g.Model("user").Ctx(ctx).Cache(gdb.CacheOption{

		Duration: time.Hour,

		Name:     "vip-user",

		Force:    false,

	}).Where("uid", 1).One()

	g.Log().Debug(ctx, r.Map())

}

go-zero

官方都做了详细的介绍，不作为本文的重点。

讨论

我的方案也在我的技术交流群里引起了大家的讨论，也和大家分享一下：

Q1 冗余设计和一致性问题

提问： 一个表里做了这么多外键，如果我要查各自的名称，势必要关联4张表，对于这种存在多外键关联的这种表，要不要做冗余呢(直接在主表里冗余各自的名称字段)？要是保证一致性的话，就势必会影响性能，如果做冗余的话，又无法保证一致性

回答：

你看文章的上下文应该知道，文章想解决的是视频列表筛选问题。

你提到的这个场景是在视频详情信息中，如果要展示这些外键的名称怎么设计更好。

我的建议是这样的：

1. 根据需求可以做适当冗余，比如你的主表信息量不大，配置信息修改后同步修改冗余字段的成本并不高。
2. 或者像我文章中写的不做冗余设计，但是会把外键信息缓存，业务查询从缓存中取值。
3. 或者将视频详情的查询结果整体进行缓存

还是看具体需求，如果这些筛选信息不变化或者不需要手工管理，甚至不需要设计表，直接写死在代码的配置文件中也可以。进一步降低DB压力，提高性能。

Q2 why设计外键？

提问：为什么要设计外键关联？直接写到视频表中不就行了？这么设计的意义在哪里？

回答：

总结

这篇文章介绍了设计数据库表结构应该考虑的4个方面，还有优雅设计的6个原则，举了一个例子分享了我的设计思路，为了提高性能我们也要从多方面考虑缓存问题。

收获最大的还是和大家的交流讨论，总结一下：

1. 首先，一定要先搞清楚业务需求。比如我的例子中，如果不需要灵活设置，完全可以写到配置文件中，并不需要单独设计外键。主表中直接保存各种筛选标签名称（注意维护的问题，要考虑到数据一致性）
2. 数据库表结构设计一定考虑数据量和并发量，我的例子中如果数据量小，可以适当做冗余设计，降低业务复杂度

前言

现在好多人说程序员的红利时代已经过去

• 裁员的企业比比皆是


• 简历投出去基本没人理，2,3个月能找到工作就不错了，而且还是降薪


• 有重点学校毕业的也只能找到外包的工作


• 千万别学计算机相关专业，无异于50年加入国军


• 车贷，房贷都要还，降薪我也接受

等等上面现象都是我或听说或看到的，或亲身经历的。

现在行业不景气，也不知道是否有恢复生机的一天，或者也许一直会走下坡路，也触动着你我的神经。

真实经历

去年年底的时候我为我们公司面试员工，通过率变得很低，所以面试难度要相对加大，有一次面试一个女生，她技术我觉得一般，感觉没怎么准备，八股文也没有背熟，所以我给了她一些建议，然后我问了一下她从上一个公司的离职原因，她说是被裁掉了，然后说现在找工作很困难，已经找了很长时间了，上家公司工资16，现在要12,13好多公司都还在压价，她说主要现在有车贷，房贷，还有小孩，所以迫不得已得赶紧找到下一家，所以薪资她一降再降，只希望能快点找到工作，等等，说了很多。

非常同情她的遭遇，但是遇到现在行业不景气，而且技术也一般，所以这就很难受，感觉她的焦虑要比平常人大很多，因为还有车贷，房贷，小孩的原因在里面。说到这里屏幕前的你是否有些焦虑呢？

焦虑由来

如果我们踏入程序员这一行业，那么就意味着终生学习。如果平时喜欢躺平，喜欢摸鱼，那么随着年龄的增大，或者行业不景气，焦虑就会不断找上你。用大多数的人来说，'这个行业就是吃青春饭的'，可能在行情好的时候，有些人感觉不出来，觉得自己没有问题的，能干到40岁，但是行情下滑，失业率加大的时候，可能这个问题又会被放大。但是焦虑一定就是坏事么？

什么是焦虑？

引用百度百科里的解释：

焦虑是人对现实或未来事物的价值特性出现严重恶化趋势所产生的情感反映 。与之相反的情感形式是企盼，即企盼是人对现实或未来事物的价值特性出现明显利好趋势所产生的情感反映。

焦虑是指个人对即将来临的、可能会造成的危险或威胁所产生的紧张、不安、忧虑、烦恼等不愉快的复杂情绪状态。

所以我的意思还是希望大家能够主动拥抱变化，主动改变自己，行动起来，那么问题又来了，我们努力的方向在哪里？努力是有方法的，努力要选择好努力的方向，否则辛苦付出了，收获并不会很大。所以说到这里你是否又开始迷茫了？

你是否有这种迷茫？

在技术的学习中大家应该有过下面这种现象，有的同学感觉付出了很多努力，但是收获很少。尤其进阶阶段，研究源码阶段，精通阶段等等，付出了大量时间，但是收效甚微，有时候我们就会产生这样的想法，我选择的这条道路对么？为什么感觉自己还是很菜？我花这么多时间研究源码干什么？

于是这个时候你开始变得焦虑，迷茫？想想工作1，2年的程序员2周就能学会vue并上手了，而你花了相同的时间看了《javascript高级程序设计》这本书还不到20页, oh my god, 这样下去会不会下一个被裁的就是我

这个时候在我脑子里浮现了一个问题'你说工作7,8年的程序员相对于工作两三年的程序员优势在哪里呢？'

如何选择好以后的道路

针对程序员该如何选择自己的道路，我采访过一些工作比较久的程序员。

我的问题是这样的

'你说工作7,8年的程序员相对于工作2,3年的程序员优势在哪里呢？'

下面是一些回答

有的人觉得优势是经验，包括成本预估、架构策略、性能评估、风险评估等, 但是除了这些也不得不承认其他基本都是劣势

有的人觉得工作5年的程序员应该达到技术的至高点，根据统计学规律，程序员以后主要往两条路发展，一种是系统架构师，一种是业务负责人，要早做规划

还有的人说找准目标，缺啥补啥，当然目前是根据环境动态调整的，先把自己能把控好的事做好，大环境不好就降低目标，也能把更多精力放到其他上面

还有的人给出了更加详细的解答

    1、更多关注全局架构的精力超过专注细节的精力

    工作早期，接到的任务大多是单点的功能模块和系统，更多关注编码、技术实现问题。

    工作7、8年会，会逐渐承担整块的业务，进而会从业务的整体角度来思考系统的架构，目标从“实现某个功能”转变到“支撑某个业务”，把业务当作整体来看，视角逐渐从“语言、框架、数据库”转换到“通信、架构、安全合规、网络、数据”。



    2、意识到对技术的表达能力很重要

    这不是指为人处事的沟通表达能力，而是对技术的表达能力；

    例如更加关注流程图、架构图，不再排斥ppt、文档，会更多思考怎么更加准确、简洁的描述出你的系统架构、业务流程，能够让合作方、上下游更加准确的理解你的思路和设计，更加高效的合作，避免出现理解偏差。

    例如编码，早起很喜欢炫技，喜欢各种高大上的编码风格，例如各种函数式语法，工作久了就不再喜欢追求这些，更加看重你的代码是否能够很容易理解，是否足够健壮，能够被测试到，特殊逻辑能否充分注释；



    3、不再纠结于单点的性能提升

    新人很容易陷入性能崇拜，过分关注有限的性能优化，为了有限的性能提升，直接在db层面写复杂的sql直接处理，导致代码可读性变差。

    后来会更加关注有限在符合基础性能的前提下，优先满足业务的诉求，再根据业务的特性、预判一段时间内的发展，适当的在性能和可读性、可复用性上做一定的取舍。



    4、更加追求简单的架构、代码

    好的代码、架构一定是简洁的，如果一段代码、设计很多人不容易理解，那么这样的设计迟早会出问题。

    给你的上下游以简洁、清晰的接口、文档和功能，避免给到用户各种条件选择，避免过度原子化拆分，在可拓展性、易用性方面需要做取舍，

在这里非常感谢以上各位的回答，相信上面的回答能帮助大家或多或少的解决努力方向的问题

just do it

首先说明一点，没有人不迷茫的，大家都第一次做人，怎么会知道接下来每一步该怎么走呢？

有一个人十分崇拜杨绛。高中快毕业的时候，他给杨绛写了一封长信，表达了自己对他的仰慕之情以及自己的一些人生困惑。

杨绛回信了，淡黄色的竖排红格信纸，毛笔字。除了寒暄和一些鼓励晚辈的句子外，杨绛的信里其实只写了一句话，诚恳而不客气：

“你的问题主要在于读书不多而想得太多”。

参考

• 冴羽答读者问：怎么才能不焦虑？<
  
  作者：为了摸鱼而战
  来源：juejin.cn/post/7239633419784405047
  /a>

在当今数字化的时代，前端开发已成为构建出色用户体验的重要领域。然而，传统的前端开发过程往往需要耗费大量时间和精力，对于那些没有技术背景或时间有限的人来说，这无疑是一个巨大的挑战。然而，随着技术的不断进步，低代码开发正迅速崛起，为我们提供了一种简化开发流程的全新方法。

终端概念

终端 = 前端 + 客户端

在讲低代码之前，我们先来聊一聊终端概念，这个终端不是指敲命令行的小窗口，而是 终端 = 前端 + 客户端。乍一听，这个不是和大前端的概念类似吗？为什么又提出一个重复的名词，实际上它俩还是有很大区别的，在大前端里面，岗位是有不同区分的，比如前端开发工程师、客户端开发工程师，每个岗位的分工是不一样的，但是你可以把终端看成一个岗位。

下面是阿里巴巴终端开发工程师招聘的 JD，因为内容较长，我将他分成了三张图片，我们从上到下依次看。

第一张图片：
2024届实习生的招聘，招聘岗位为终端开发工程师

第二张图片：
这是他们对终端开发工程师的描述，大家主要看标了特殊颜色的字体就行

它包括原有的“前端工程师”和“移动端工程师” 相较过去，我们强调面向最终的用户进行交付，不局限于“前端〞、“移动端〞，这将显著拓宽工程师的职责、 能力边界。

第三张图片：
这是他们对终端开发工程师的岗位要求，可以从要求的第1、2、3项看到，这个岗位更侧重于基础技术、终端界面，而不是在于要求你会使用某某框架。

阿里巴巴公众号改名史

这个公众号可能会有一些朋友之前关注过，它会发布前端和客户端相关的文章，但是之前的名字并不叫阿里巴巴终端技术。

我们来看看他的改名史：

• 2019年05月10日注册 "Alibaba FED"（FED：Front-end Developer 前端开发者）


• 2019年06月12日 "Alibaba FED" 认证 Alibaba F2E"（F2E：Front-end Engineer 前端工程师）


• 2022年07月08日 "Alibaba F2E" 帐号迁移改名"阿里巴巴终端技术"

所以是从此又多了一个终端开发工程师的岗位吗，显然不是的，终端开发工程师最终是要取代前端开发工程师和客户端开发工程师的，最终的目的是达到降本增效。

那如何让前端开发工程师和客户端开发工程师过渡成为终端开发工程师。

终端走向荧幕

在阿里 2022 年举办的第 17 届 D2 终端技术大会上，当然他们是这一届将大会名字改成了终端，其中有一篇卓越工程的主题简介如下：

在过去十年，不管是前端的工具链还是客户端的版本交付效能等都在快速演进，面向未来，我们升级工程体系走向终端工程一体化，覆盖前端及客户端工程师从研发交付到运维的全生命周期，利用低代码、极速构建、全链路运维、Serverless 等新型的工程技术，在卓越工程标准推动下引领终端工程师走向卓越。

可以看到，低代码是可以作为实践终端的一种技术方案，并且将其放在了第一位，那么什么是低代码，低代码能做什么事情，为什么使用低代码可以让终端开发工程师变的更加卓越？低代码对我们普通的一线开发又能带来什么改变或者赋能？
好，接下来，我们就来聊一聊低代码。

什么是低代码

Low-Code

低代码来源于英语翻译——Low-Code，当然，此“Low”非彼“Low”，它意指一种快速开发的方式，使用最少的代码、以最快的速度来交付应用程序。

低代码的定义是什么

虽然低代码已经是个老生常谈的话题了，但关于它的定义我觉得还是有必要描述一遍（来自ChatGPT）：

低代码是一种软件开发方法，旨在通过最小化手动编码的工作量，利用可视化工具和组件来快速构建应用程序。它提供了一个图形化的界面，使开发者能够以图形化方式设计和创建应用程序的用户界面、业务逻辑和数据模型，而无需编写大量的传统代码。

低代码它作为一种软件的开发方法，他不仅仅可以作为终端的解决方案，也可以在后端、IOT、大数据等领域上进行使用，并且这些领域也都有现成的低代码开源工具或者平台。

传统前端开发 VS 低代码开发

传统的前端开发方式，我们需要使用 HTML + CSS 描绘出页面的骨架，再使用 JAVASCRIPT 完成页面的功能逻辑。

可以看到图片上，我们定义了三个 div 元素，并且给每个 div 元素加上了背景颜色，并且加上了点击事件。每一块的元素，都需要我们使用相应的代码去描述。页面越复杂，描述的代码量就会越多。页面的代码量越多，相应的维护的成本就会越高。

我们在来看下如何使用低代码进行开发：

左侧物料区，中间画布区，右侧物料配置区，这种区域划分也是比较常见的低代码平台布局。选择物料以后，将物料拖进画布区，接下来我们就可以对物料进行属性配置。

相较于故枯燥难懂的代码，直观的拖拉拽显得更加简单，也更加容易理解。

背后的原理是什么

通过简单的托拉拽后我们可以看到一份表格页面，那么页面实际上是如何生成的呢？

背后实际对应的一份 Schema 描述，主要由物料描述和布局描述组成。

我们从左到右依次看，componentsMap 记录了我们当前页面使用的组件，可以看到我们使用了Form.Item、Input、Table，以及这些组件来自的 package 包信息。

componentsTree 里面记录了整个页面布局的信息，最外层由Page组件包裹，然后依次是 Form.Item组件，label 标签为姓名，里面还有一个 input 作为子元素，后面还有两个 Form.Item，为年龄和地址，最后的元素是 Table 组件，通过这些信息，我们就可以布局出一份简单的表格页面。

componentsMap 描述了我们当前页面所需的物料，componentsTree 描述了我们当前页面的布局顺序，将这两份数据组合，通过特定的解析器，就可以得到一份页面。低代码的页面渲染是通过我们事先约定好的数据结构进行生成的。

Schema ⇒ 页面，会不会使我的页面加载变慢

可能会有一些同学心中会有疑问，通过 Schema 生成页面，应该是需要一层 runtime 层吧，通过一段运行时的代码，将 Schema 转换为页面。

那在将 Schema 的内容转换为页面的时候，难免会产生性能上的损耗吧？

性能 VS 可维护性

这里就涉及到了性能 和 可维护性的取舍了，平台的意义在于为你掩盖底层代码的操作。让你用更直观的方式来描述你的目的，其实这里可以牵扯出另外一个相似的话题。

真实DOM VS 虚拟DOM

现代化的前端框架都会使用虚拟 DOM，那大家觉得真实DOM更快还是虚拟DOM更快？

框架的意义在于为你掩盖底层的 DOM 操作，让你用更声明式的方式来描述你的目的，从而让你的代码更容易维护。

没有任何框架可以比纯手动的优化 DOM 操作更快，因为框架的 DOM 操作层需要应对任何上层 API 可能产生的操作，它的实现必须是普适的。

针对任何一处基准，我都可以写出比任何框架更快的手动优化，但是那有什么意义呢？在构建一个实际应用的时候，你难道为每一个地方都去做手动优化吗？出于可维护性的考虑，这显然不可能。框架给你的保证是，你在不需要手动优化的情况下，我依然可以给你提供过得去的性能。

你会发现低代码的 Schema 和 虚拟 DOM 是比较相似的，都是通过对象的形式去描述 DOM 节点，
虚拟 DOM 的另外一个优势，是在于实现跨端，将底层对 DOM 操作的 API 更换为对 Android 或者 IOS 的 UI 操作。同理低代码的 Schema 也可以比较好的实现跨端，思路基本是一致的，Schema 只是一份组件 + 页面的描述，你可以根据不同的场景，进行不同平台的组件的渲染。

有没有办法可以优化页面渲染的性能吗？

那么有没有解决方案呢？

是有的，我们可以通过 Schema 的方式对页面进行出码，出码后是一套完整的应用工程，基于应用工程在去对应用进行一次构建，将这部分负担转移到编译时去完成。

生成的应用工程和我们平常开发的应用工程基本相似：

什么是低代码？

如果之前你没有听过低代码，到这里你还是没有明白低代码是什么。没关系，你可以暂时的把他理解一个可视化编辑器，通过拖拽元素就能生成页面，页面背后实际对应的是一串 Schema JSON 数据。到最后，我们会重新对低代码进行一个定义。

低代码发展趋势

低代码发展时间线

我们来看下低代码发展的时间线：

• 1980年代：出现了第四代编程语言（ABAP, Unix Shell, SQL, PL/SQL, Oracle Reports, R）第四代编程语言指的是非过程的高级规范语言，包括支持数据库管理、报告生成、数学优化、图形用户界面(GUI)开发和 web 开发。


• 2000年：出现了 VPL 语言（即 visual programming language 可视化变成语言）


• 2014年：提出了低代码 / 零代码概念


• 2016年：国内独立的低代码开发平台开始相继发布


• 2021年：中国市场逐渐形成完整的低代码、无代码生态体系

发展趋势

这是 OSS Insight 上关于低代码的一组统计数据，他们分析了50亿的 Github event数据，得出了这些报告，我从里面摘选了和低代码相关的部分。

首先，在2022年热门话题的开源存储库活跃度，LowCode 以76.3%活跃度位居第一，其次是Web3、Github Actions、Database、AI，可见大部分低代码开源仓库都处于一个开发或者维护的状态。

我们在来看下，低代码发展的趋势图，从2016年到2020年，低代码整体处于上升趋势，并且新增仓库在2020年达到最高点，新增低代码相关的仓库高达了300%以上。

在2020年野蛮生长后，2021年的新增仓库趋近于0，但是在2021低代码相关仓库的start数量将近增长了200%，2022年的数据开始趋于平缓，并且新增仓库数量减少，标志着低代码技术沉淀趋于平稳，百花齐放的时代已经过去。

没有规矩，不成方圆

百花齐放下其实是关于低代码标准的缺失，每套低代码平台都有自己的行为标准，各个平台之间的物料是有隔阂的，无法通用的。就有点像现在百花齐放的小程序，比如微信小程序、支付宝小程序、百度小程序等等，从一定程度上来讲，标准的缺失，会给用户和开发者带来了一定的困扰。

如果有行业组织或者技术社区可以积极推动低代码标准化的倡议，制定统一的行为标准和规范，标准物料的
定义，那么对于低代码的未来发展是一件非常有利的事情。

低代码产品矩阵

我们看来下国外的低代码产品矩阵，种类和平台还是非常多的。

可以看到关于低代码的落地场景其实有非常多，并且已经有了大量成熟应用流入市场，所以低代码作为一种开发软件的方法，可以将其灵活运用在各个场景。

而且每个场景的低代码，在其下还可以细分领域，比如 Web 应用程序开发，可以细分为中后台管理搭建、活动推广页面、图表大盘页面等。

一款低代码平台，通常都会有它自己的定位，是为了解决某种特定领域下的特定业务而生。所以一个公司内部有十几个低代码平台是很正常的，他们在细分下的业务场景有不同的分工。

我们正在做什么

这一章节分为三个小块来讲，为什么要做低代码、怎么去做低代码、现在做的怎么样了

为什么要做低代码

我们为什么要做低代码，低代码其实能解决的问题和场景有非常多，那么低代码能帮我们研发团队解决哪些问题？

1.由繁去简

通常一个需求下来，

1. 产品会先对需求进行规划，产出一份原型图交付给 UI 设计


2. UI 通过产品提供的原型图，对原型进行美化，产出一份设计稿


3. 前端对照设计稿进行页面开发，交付高保真的页面


4. 最后进行接口联调，将静态的数据更改为接口获取的数据

做程序本质上也是在做交流，假设我们现在是一位前端或者客户端的开发工程师，

1. 我们需要先和产品 battle 原型图


2. 和 UI 讨论设计稿


3. 交付高保真的页面


4. 和后端进行接口联调

可以看到绝大部分的时间都花在了如何去做页面上，在加上关于各个环节对页面的讨论和修改，这中间会产生大量的浸没成本。

如果说，现在有一个工具，可以做到产品交付的就是高保真页面，你会选择用还是不用？

这个是使用低代码后的开发流程，由产品直接生成高保真页面交付给前端，极大提高了开发生产力。那么，这个时候前端可以更加聚焦于业务逻辑，聚焦于工程体系，而不是页面本身。

2. 我不想在去改样式了

好像所有的产品经理都喜欢在项目即将上线前，对页面的样式进行调整，没错，既不是测试阶段，也不是预发阶段，而是即将发布前，改完一个，在改一个，好像总是也改不完。

而使用低代码平台后，将页面生成的权利递到产品经理手中，他们可以随心所欲的修改，尽情的展示自己的创造力，我们也不在需要反复的修改样式，反复的重新构建应用发布，你可以专心的去做其它事情。

3. 真正的所见即所得

真正的所见即所得，相比于黑盒子的代码，低代码平台显得更加直观，操作的是页面，而不是代码，你可以在平台上尽情的组装，就像是搭积木一样。

怎么去做低代码

在能够协调足够多的资源的情况下，选择自研是比较好的一条路，因为一切都是可控的。

但是在资源有限的情况下，选择开源或许是一种最快最便捷的方法了。我们在低代码发展趋势中，可以发现低代码平台和开源技术已经趋于稳定。

使用稳定的开源框架可以更快的帮助我们创建低代码平台，并且有足够多懂低代码底层的人，去帮助我们维护基础设施，站在巨人的肩膀上出发，往往会事半功倍。

我们选择的是阿里开源的 lowcode-engine，在其基础上进行二次开发，选择它的理由有很多：

现在做的怎么样了

下面是平台的真实演示，目前已经支持开发以及发布预览了。

低代码架构图：

平台使用流程的步骤图：

• 第一步是创建应用


• 第二步是创建页面，当然一个应用下面可能会有多个页面，每个页面都会是相互独立的，


• 第三步是布局调整，可以在选中的页面进行拖拽物料进行布局


• 第四步是属性配置，配置物料的属性，配置物料的事件或者样式，提供自定义样式和逻辑的功能支持


• 第五步是保存发布，将当前各个页面的schema进行保存上传，存储到数据库


• 第六步是页面渲染，可以直接通过平台生成的页面地址，打开页面

被误解的低代码

我相信是会有一大部分的程序员从内心抵制低代码的，一方面，作为一个技术工种，对自己的技术是有底气的，有傲骨的，人为写的代码都不怎么样，还指望低代码平台上的代码吗，另一方面，在低代码平台的代码上维护，那简直就是在屎山上维护，维护的成本会更大吧

出码 VS 不出码

这里的痛点是在于需不需要维护低代码产出的代码，前面我们讲到过出码，出码可以用于产物构建。但构建这一块，是平台去做的，用户并不会感知到背后实际的应用工程。

出码同时也可以用于用户的自定义需求，如果平台的物料完全覆盖了你的业务场景，你是不需要去出码的。但是，如果平台的物料无法满足你的业务场景，你需要的组件又具备足够的特殊性，这个时候你可能需要使用出码功能，在出码的应用工程基础下，添加自己的业务代码，那么这个时候，你是需要维护整个应用工程的。

对低代码的分歧往往是这个时候产生的，每个人心中都有自己的标准代码，都会本能的去抵触和自己标准不同的代码。

不出码如何自定义开发需求？

那有没有既不出码，又可以满足自定义开发的需求呢？

因为我们更多的是希望平台去维护工程，而不是通过人为方式去维护。像我们平时开发页面，本质上就是在写组件，通过拼装组件，形成页面。

我们的思想上可以做个转变，既然 80%~90% 的工作平台可以承接，剩余的平台无法实现，可以自己实现自定义组件进行发布，发布的组件可以沉淀到市场，你的其它项目可以使用自己的业务组件，其他同事也可以使用你的组件。

低代码会不会导致前端岗位变少？

其实完全可以将低代码看成提升工作效率的一个工具，低代码解决页面视图，页面逻辑和数据联调需要开发者在平台上进行完成，开发者的关注点更多的聚焦于业务逻辑，聚焦于如何去做好工程化体系。

AI Code 不是更好吗？

那好像 AI Code 也可以做到低代码能做的地步？

在今年3月份 GPT-4 的发布会上，只需要在草稿本上用纸笔画出一个非常粗糙的草图，再拍照告诉GPT-4需要一个这样的网站，AI 就可以在10秒钟左右根据草图，生成一个网站完整的前端 HTML 代码。

GPT-4发布：一张草图，一秒生成网站

这简直就是低代码 plus，回归我第一次使用 GPT 的时候，我确实是被惊讶到，特别是他能衔接上下文关系，给出你想要的答案。

我们开发应用，其实本身就是一个庞大的上下文，版本一直迭代，需求一直新增，通过人本身去记住业务上下文，在一个足够复杂的应用下，他的上下文会足够大，足够的冗余，我们去抽离组件，抽离函数，使用数据结构优化代码，实际上就是在优化上下文，写代码并不难，难的是如何梳理页面的组件和那些难以理解的业务以及那些人与人的沟通。

至少现在看来，GPT 无法做到承接复杂应用的上下文，现在的他只能帮助你快速产出一个 demo 应用，前提你需要做到甄别代码的能力，以及还需要面临后续版本迭代更新的窘境问题。

或者说，如果 AI 真的能做到独立开发复杂应用，程序员就真的会被取代吗，做程序本身就是一个相对复杂的活，需要持续学习，持续精进。如果AI真的能做到独立开发这一步，那我觉得离真正的无人驾驶也不远了，出租车司机全部都得失业，因为做一个程序相比于驾驶车辆，会难上不少，当然还包括其它行业，80% 以上的职业都极有可能面临下岗危机。

这个是政客、政府不允许的，虽然科技进步是好事，但是 AI 并没有带来实际的增量工作岗位，反而导致失业率变高，失业率若变高，整体社会的稳定性结构就会变差。
所以，我们更多的将 AI 看成工具，关注点在于，如何用 AI 去做成更多的事情。

什么是低代码？

讲到这里，基本上今天的分享就已经进入尾声了，最后我们在来确定下什么是低代码？

低代码是一种软件开发方法，旨在通过最小化手动编码的工作量，利用可视化工具和组件来快速构建应用程序。它提供了一个图形化的界面，使开发者能够以图形化方式设计和创建应用程序的用户界面、业务逻辑和数据模型，而无需编写大量的传统代码。

一千个人眼中，有一千个哈姆雷特，每个人对低代码的理解都会有些许不同，首先低代码是一种软件开发的方法，这套方法可以用在很多场景。如果一个平台提供了可视化的工具和组件并且又提供部分手动编码的能力，它就可以是一个低代码平台。

在前端低代码的方案中，并不是不再使用 HTML、CSS、JAVASCRIPT 进行开发，而是大大减少他们的使用频率，通过少量的代码，就可以完成一个页面的开发。

参考

• 这个暑假来实习，阿里巴巴终端开发工程师等你加入！


• 第十七届D2终端技术大会


• 网上都说操作真实 DOM 慢，但测试结果却比 React 更快，为什么？尤雨溪回答


• Trends and Insights from GitHub 2022


• The Low-Code / No-Code Ecosystem


• lowcode-engine 官网<
  
  作者：BARM
  来源：juejin.cn/post/7241125859728392248
  /a>

这是一个全新的平台。熟悉的框架和工具。请准备好为 Apple vision Pro 设计和构建全新的应用程序和游戏世界。

沉浸的光谱。

Apple vision Pro 提供无限的空间画布供您探索、试验和玩耍，让您自由地完全重新思考您的 3D 体验。人们可以在与周围环境保持联系的同时与您的应用互动，或者完全沉浸在您创造的世界中。您的体验可以是流畅的：从一个窗口开始，引入 3D 内容，过渡到完全身临其境的场景，然后马上回来。

选择权在您手中，这一切都始于 visionOS 上的空间计算构建块。

窗口（Windows）

您可以在 visionOS 应用程序中创建一个或多个窗口。它们使用 SwiftUI 构建，包含传统视图和控件，您可以通过添加 3D 内容来增加体验的深度。

体积（Volumes）

使用 3D 体积为您的应用添加深度。 Volumes 是一种 SwiftUI 场景，可以使用 RealityKit 或 Unity 展示 3D 内容，从而创建可从共享空间或应用程序的完整空间中的任何角度观看的体验。

空间（Space）

默认情况下，应用程序启动到共享空间，在那里它们并排存在——很像 Mac 桌面上的多个应用程序。应用程序可以使用窗口和音量来显示内容，用户可以将这些元素重新放置在他们喜欢的任何位置。为了获得更身临其境的体验，应用程序可以打开一个专用的完整空间，其中只会显示该应用程序的内容。在完整空间内，应用程序可以使用窗口和体积、创建无限的 3D 内容、​​打开通往不同世界的门户，甚至可以让某人完全沉浸在某个环境中。

Apple 框架 - 扩展空间计算

SwiftUI

无论您是要创建窗口、体积还是空间体验，SwiftUI 都是构建新的 visionOS 应用程序或将现有 iPadOS 或 iOS 应用程序引入该平台的最佳方式。凭借全新的 3D 功能以及对深度、手势、效果和沉浸式场景类型的支持，SwiftUI 可以帮助您为 Vision Pro 构建精美且引人入胜的应用程序。 RealityKit 还与 SwiftUI 深度集成，以帮助您构建清晰、响应迅速且立体的界面。 SwiftUI 还可以与 UIKit 无缝协作，帮助您构建适用于 visionOS 的应用程序。

RealityKit

使用 Apple 的 3D 渲染引擎 RealityKit 在您的应用程序中呈现 3D 内容、​​动画和视觉效果。 RealityKit 可以自动调整物理光照条件并投射阴影、打开通往不同世界的门户、构建令人惊叹的视觉效果等等。为了创作您的材料，RealityKit 采用了 MaterialX，这是一种用于指定表面和几何着色器的开放标准，由领先的电影、视觉效果、娱乐和游戏公司使用。

ARKit

在 vision Pro 上，ARKit 可以完全了解一个人的周围环境，为您的应用提供与周围空间交互的新方式。默认情况下，ARKit 支持内核系统功能，您的应用程序在共享空间中时会自动受益于这些功能——但是当您的应用程序移动到完整空间并请求许可时，您可以利用强大的 ARKit API，例如平面估计、场景重建、图像锚点、世界轨道和骨骼手部轨道。所以在墙上泼水。从地板上弹起一个球。通过将现实世界与您的内容融合在一起，打造令人惊叹的体验。

Accessibility

visionOS 的设计考虑了可访问性，适用于希望完全通过眼睛、声音或两者的组合与设备交互的人。对于喜欢以不同方式导航内容的人，Pointer Control 允许他们选择食指、手腕或头部作为替代指针。您可以使用已在其他 Apple 平台上使用的相同技术和工具为 visionOS 创建易于访问的应用程序，并帮助使 vision Pro 成为每个人的绝佳体验。

您需要的所有工具。

Xcode

visionOS 的开发从 Xcode 开始，其中包括 visionOS SDK。将 visionOS 目标添加到您现有的项目或构建一个全新的应用程序。在 Xcode 预览中迭代您的应用程序。在全新的 visionOS Simulator 中与您的应用程序交互，探索各种房间布局和照明条件。创建测试和可视化以探索空间内容的碰撞、遮挡和场景理解。

reality composer Pro

探索全新的 reality composer Pro，旨在让您轻松预览和准备 visionOS 应用程序的 3D 内容。随 Xcode 一起提供的 reality composer Pro 可以帮助您导入和组织资产，例如 3D 模型、材料和声音。最重要的是，它与 Xcode 构建过程紧密集成以预览和优化您的 visionOS 资产。

Unity

现在，您可以使用 Unity 强大、熟悉的创作工具来创建新的应用程序和游戏，或者为 visionOS 重新构想现有的 Unity 创建的项目。除了熟悉的 Unity 功能（如 AR foundation）之外，您的应用程序还可以获得 visionOS 的所有优势，例如直通和动态注视点渲染。通过将 Unity 的创作和模拟功能与 RealityKit 管理的应用程序渲染相结合，使用 Unity 创建的内容在 visionOS 上看起来和感觉起来就像在家里一样。

您的 visionOS 之旅从这里开始。

visionOS SDK 本月晚些时候与 Xcode、visionOS 模拟器、reality composer Pro、文档、示例代码、设计指南等一起发布。

为 visionOS 做准备

无论您已经在 App Store 上拥有应用程序，还是这是您第一次为 Apple 平台开发应用程序，您现在都可以做很多事情来为 visionOS SDK 的到来做好准备。了解如何更新您的应用程序并探索现有框架，让您更轻松地开始使用 visionOS。

Prepare for visionOS

了解 visionOS

visionOS 拥有一流的框架和工具，是帮助您创造令人难以置信的空间体验的完美平台。无论您是在构想游戏、构建媒体体验、设计与 SharePlay 的连接和协作时刻、创建业务应用程序，还是更新您的网站以支持 visionOS，我们都有会议和信息来帮助您制定计划。为第 46 场 WWDC23 会议准备好 visionOS SDK，以帮助您了解平台开发、空间体验设计以及测试和工具。

Learn about visionOS

与苹果合作

在为 visionOS 开发应用程序和游戏时，获得 Apple 的直接支持。了解即将举行的活动、测试机会和其他计划，以支持您为此平台创造令人难以置信的体验。

Learn about working with Apple

#visionOS #苹果MR #苹果VR #苹果AR