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

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

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

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

结构化

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

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

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

精简

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

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

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

善用最佳实践

俗话说太阳底下没有新鲜事儿，一般来说，没有一个业务场景所需要用到的编码方式是需要你独创发明的。你所写的代码功能大概率都有人遇到过，因此对于大部分常用的编码模式，也都大家被抽象出来了一些最佳实践。那么最经典的就是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

不知不觉回到哈尔滨工作三年了，经历了两家公司，最近又燃起了换工作的心思。都说人挪活、树挪死，所以，我还想要活着，甚至获得更好一点，只能选择挪一挪，说句不好听的，这就有种矮子里拔大个的感觉。

概述

稍微熟悉哈尔滨的人都应该知道，哈尔滨是座没有互联网的城市。回溯过去的十几甚至二十年，哈尔滨整体的软件行业基本处于停滞的状态。每年的各种互联网公司排行，独角兽公司排行甚至从没有出现过哈尔滨这三个字眼。被人们所熟知的BJTA等互联网巨头，他们甚至没有在哈尔滨这座城市扎根的丝毫想法。当然，我指的是研发团队，毕竟研发才是整个互联网公司的核心，他们支撑着公司各条业务线的运转。

你可能会说，没有大厂的城市多了去了。确实如此，但是哈尔滨作为最北方的省会城市，有着美丽的称号东方小巴黎，作为二线城市中排名靠前的城市，软件行业的发展确实是没有进步。最近几年，同为二线城市的成都、武汉、西安等城市的发展可谓是突飞猛进，一跃成为新一线城市，工作机会与工资水平大大提升。然而作为共和国长子中的省会城市，却在原地踏步，夸张点说，甚至是在退步！

城市表现

随着2022年全国城市商业魅力排名的发布，我们清晰的看到，全国共有4个一线城市，15个新一线城市，而哈尔滨不出意外的出现在二线城市当中，且排名二线城市的第9位。更夸张的是，东北竟然无一城市入选新一线，去年杀入榜单的沈阳今年也铩羽而归了。

2020年时，全国千万级人口城市有18个，其中就有哈尔滨，到了2021年，哈尔滨居然跌出了这份榜单，全是常驻人口为988.5万，且全是人口增长率为-2%。那么你不禁要问，人口去哪了？为何会越来越少？

我愿意用恶劣这两个字来形容如今哈尔滨年轻人的工作环境。2022年哈尔滨工资全国排名第38位，7160元，乍一看，这个水平不低了，确实，但是你真正了解就会发现，工资区间在3k~5k的人大有人在，他们同样是大学毕业，活力满满的年轻人，但是却没有机会获得一份高薪水的工作，甚至五险一金都是奢望。高收入人群虽然是少数，但是他们的工资却达到普通人的几倍，甚至十几倍。你会说，低收入的人还是没有能力，然而真的如此吗？

对比其他新一线城市，哈尔滨还是差了太多，我指的工作的机会。人确实有优秀的人，也有相对差一些的人，但是他们的层次也不至于相差十几倍这么夸张。但是在哈尔滨恰恰就是这样一种体现，年轻人甚至没有机会去展示自己的能力。

绝大多数的企业，高层都是在公司深耕多年的老人，他们的存在注定年轻人没有取代他们的机会，这并不是一个完全靠能力就能上位的城市。公司内部没有明确的晋升机制，没有规范的涨薪条例，更没有给你预留以后的位置。

软件行业的工资水平，远远低于行业的平均值。3~5年的程序员工资水平大约在7k-9k，5-10年的大约水平在11-15k左右。这种水平在一线甚至其他新一线城市已经是低薪了。毫不夸张的说，这还是不错的那些程序员能够拿到的薪水。

技术水平

既然咱们是程序员，那就来聊聊哈尔滨的程序员水平如何。

2019年我刚回到哈尔滨，面试过几家公司，对于技术层面的面试基本都是皮毛，仅限于是否使用过哪些工具？用过哪些方法？如何写一个sql？

是否觉得现在面试还有如此不卷的公司？有，而且在哈尔滨90%都是这样的。虽说整体面试难度看起来不大，也很好通过，但是你觉得仅凭如此，能获得不菲的薪水？当然，基于这种环境，你就不可能获得高薪水。因为你的面试官根本也不懂更深层面的内容。如果一个饱受面试摧残的程序员来到哈尔滨面试，我相信你会发现一个新大陆。当你面试入职后，你甚至会不屑于与他们讨论技术原理性问题，因为他们根本不懂。

我作为一个后端开发，竟然遇到这样一个面试题：会用div画三角形吗？你能相信这是一个哈工大博士生，且工作10余年的java程序员能问出来的问题？

在目前的微服务发展形势下，当然也有不少公司开始使用这些技术，然而他们不是基于业务去拆分，而是基于功能，你能想象到的是，原本没有多少功能的系统，生生拆出十几甚至二十个服务，上线后每天的用户量，用一个手指就可以数的过来。当然，有部分程序员还是有理智的，不会认同你们leader的这种恶劣行为，但是你的反对不会有效果。

有一句话，我听得时候很不屑，现在想想，这就是现实！你学这些干啥？学了你也用不上。确实，很多东西学了你也用不上。说个简单的方面，哈尔滨企业的容器化，或者云化的程度微乎其微。且大部分功能在领导看来能用就可以。

长期在哈尔滨的程序员，经过这种环境熏陶，相当于浪费生命，真的好比坐井观天，他们如果出去其他新一线城市，相信必然会感叹程序员居然是这样的？

新的机遇

那么，哈尔滨软件行业到底有没有新的机遇？前一段时间相信哈尔滨人都知道的一个新闻，六大巨头宣布与哈尔滨达成深度合作，其中包含华为,百度,京东,腾旭,中兴,中科。初一听，这好像确实是对哈尔滨的好消息，这几个公司基本都是行业的领头羊，如果他们到来必定能够带来不少的就业岗位，提升一定的经济增长。

但是细细观察你会发现，最高兴的人无异于房地产行业，似乎踩到他们的尾巴一般，各种营销号，短视频不断的四处宣扬。但也不得不说，疫情导致哈尔滨的商业难以开展，所有的行业都停滞了，他们也像找到了救命稻草。

但是我却并不很看好这次机会，从本质来说，这六个企业能来，还是黑龙江政府给到了足够的吸引力，提供了强大的政策支持，不然我不认为会有企业发善心一样的去带动你你们的经济发展。

另外，本次六个企业的到来，至少我不认为是软件从业人员的机遇，研发团队无论从质量，还是数量，相比于其他城市，哈尔滨还是有很大的不足的。即使有，我觉得也只是外包团队，而不会是核心研发团队。

在从目前公布的几个公司的业务方先来看：华为在算力中心、人工智能、人才培养，百度在“一基地、三中心、七平台”，京东在“一店、一基地、一底座、一战略、三平台”，腾讯在数字转型、生物医药、创意设计，中兴在5G产业链，中科在咨询智库、数智制造业等方面提出落地诉求。在我看来特别像是老板在给我们画大饼。

如何找工作

不管以后如何发展，现在还是要找一分稳定的工作。作为程序员，我还是总结一下几个重要的方面：

1、技术方面，即使处于哈尔滨这种躺平的环境，还是要不断的学习的。深度与广度同样重要，可以让你在工作当中得心应手，有更多的解决方案，也就意味着有更多被领导关注的机会。平时的沟通中，能更多的体现你的技术能力，将会使你在领导的印象里增加重量。同时在面试时，你技术能力的体现，还是有助于获得相对高一些的薪水。

2、工作环境。目前很多企业克扣员工较为严重，名义上双休，实际单休；加班、出差严重，且没有加班费，调休等机制；五险一金按照最低工资标准缴纳，设置有些工资没有一金；领导PUA严重，公司氛围沉闷，逢场作戏，拍领导马屁层出不穷。选择的时候慎重考虑。

3、工作距离。目前哈尔滨的地铁建设、覆盖程度不高，虽然公交线路较多，但是堵车较严重。大部分公司聚集在香坊开发区，松北等较远地带，没有地铁，但是部分公司带有通勤车，考虑目前的油价和你的薪水，建议慎重考虑出行方式。

4、薪水提升。在哈尔滨，想要薪水double，基本没有可能，涨个三五千就算不错的，如果有这种机会，且考虑我前面分析的三个方向，基本符合你的设想，别犹豫。虽然有可能是坑，但也是能拿到更多钱的坑。

总结

工作之余，闲聊而已。希望给在哈尔滨的同仁们，和即将回来的同仁们一点参考。虽然咱们哈尔滨环境不好，但是在吃这方面还是顶呱呱的。如果您有幸进入国企，或者拿到公务员的铁饭碗，作为养老城市还是不错的选择。也希望咱们哈尔滨能够越来越好吧，不要让年轻人无奈的离开。

基于 Spring Boot ，如何“优雅”的进行数据校验呢？

引入依赖

首先只需要给项目添加上 spring-boot-starter-web 依赖就够了，它的子依赖包含了我们所需要的东西。

注意：
Spring Boot 2.3 1 之后，spring-boot-starter-validation 已经不包括在了 spring-boot-starter-web 中，需要我们手动加上！

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-validation</artifactId>

</dependency>

验证 Controller 的输入

一定一定不要忘记在类上加上 @ Validated 注解了，这个参数可以告诉 Spring 去校验方法参数。

验证请求体

验证请求体即使验证被 @RequestBody 注解标记的方法参数。

PersonController

我们在需要验证的参数上加上了@Valid注解，如果验证失败，它将抛出MethodArgumentNotValidException。默认情况下，Spring 会将此异常转换为 HTTP Status 400（错误请求）。

@RestController

@RequestMapping("/api/person")

@Validated

public class PersonController {



    @PostMapping

    public ResponseEntity<PersonRequest> save(@RequestBody @Valid PersonRequest personRequest) {

        return ResponseEntity.ok().body(personRequest);

    }

}

@Data

@Builder

@AllArgsConstructor

@NoArgsConstructor

public class PersonRequest {



    @NotNull(message = "classId 不能为空")

    private String classId;



    @Size(max = 33)

    @NotNull(message = "name 不能为空")

    private String name;



    @Pattern(regexp = "(^Man$|^Woman$|^UGM$)", message = "sex 值不在可选范围")

    @NotNull(message = "sex 不能为空")

    private String sex;



}

使用 Postman 验证

验证请求参数

验证请求参数（Path Variables 和 Request Parameters）即是验证被 @PathVariable 以及 @RequestParam 标记的方法参数。

PersonController

@RestController

@RequestMapping("/api/persons")

@Validated

public class PersonController {



    @GetMapping("/{id}")

    public ResponseEntity<Integer> getPersonByID(@Valid @PathVariable("id") @Max(value = 5, message = "超过 id 的范围了") Integer id) {

        return ResponseEntity.ok().body(id);

    }



    @PutMapping

    public ResponseEntity<String> getPersonByName(@Valid @RequestParam("name") @Size(max = 6, message = "超过 name 的范围了") String name) {

        return ResponseEntity.ok().body(name);

    }

}

使用 Postman 验证

嵌套校验

在一个校验A对象里另一个B对象里的参数

需要在B对象上加上@Valid注解

常用校验注解总结

JSR303 定义了 Bean Validation（校验）的标准 validation-api，并没有提供实现。Hibernate Validation是对这个规范/规范的实现 hibernate-validator，并且增加了 @Email、@Length、@Range 等注解。Spring Validation 底层依赖的就是Hibernate Validation。

JSR 提供的校验注解:

• @Null 被注释的元素必须为 null


• @NotNull 被注释的元素必须不为 null


• @AssertTrue 被注释的元素必须为 true


• @AssertFalse 被注释的元素必须为 false


• @Min(value) 被注释的元素必须是一个数字，其值必须大于等于指定的最小值


• @Max(value) 被注释的元素必须是一个数字，其值必须小于等于指定的最大值


• @DecimalMin(value) 被注释的元素必须是一个数字，其值必须大于等于指定的最小值


• @DecimalMax(value) 被注释的元素必须是一个数字，其值必须小于等于指定的最大值


• @Size(max=, min=) 被注释的元素的大小必须在指定的范围内


• @Digits (integer, fraction) 被注释的元素必须是一个数字，其值必须在可接受的范围内


• @Past 被注释的元素必须是一个过去的日期


• @Future 被注释的元素必须是一个将来的日期


• @Pattern(regex=,flag=) 被注释的元素必须符合指定的正则表达式

Hibernate Validator 提供的校验注解：

• @NotBlank(message =) 验证字符串非 null，且长度必须大于 0


• @Email 被注释的元素必须是电子邮箱地址


• @Length(min=,max=) 被注释的字符串的大小必须在指定的范围内


• @NotEmpty 被注释的字符串的必须非空


• @Range(min=,max=,message=) 被注释的元素必须在合适的范围内

@JsonFormat与@DateTimeFormat注解的使用

@JsonFormat用于后端传给前端的时间格式转换，@DateTimeFormat用于前端传给后端的时间格式转换

JsonFormat

1、使用maven引入@JsonFormat所需要的jar包

        <dependency>

            <groupId>com.fasterxml.jackson.core</groupId>

            <artifactId>jackson-annotations</artifactId>

            <version>2.8.8</version>

        </dependency>



        <dependency>

            <groupId>com.fasterxml.jackson.core</groupId>

            <artifactId>jackson-databind</artifactId>

            <version>2.8.8</version>

        </dependency>



        <dependency>

            <groupId>org.codehaus.jackson</groupId>

            <artifactId>jackson-mapper-asl</artifactId>

            <version>1.9.13</version>

         </dependency>

2、在需要查询时间的数据库字段对应的实体类的属性上添加@JsonFormat

   @JsonFormat(timezone = "GMT+8", pattern = "yyyy-MM-dd HH:mm:ss")

   private LocalDateTime updateDate;

注： timezone：是时间设置为东八区，避免时间在转换中有误差，pattern：是时间转换格式

DataTimeFormat

1、添加依赖

       <dependency>

           <groupId>joda-time</groupId>

           <artifactId>joda-time</artifactId>

           <version>2.3</version>

      </dependency>

2、我们在对应的接收前台数据的对象的属性上加@DateTimeFormat

@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")

private LocalDateTime acquireDate;

3.这样我们就可以将前端获取的时间转换为一个符合自定义格式的时间格式存储到数据库了
全局异常统一处理：拦截并处理校验出错的返回数据
写一个全局异常处理类

@ControllerAdvice



public class GlobalExceptionHandler{

        /**

     *  处理参数校验异常

     */

    @ExceptionHandler({MethodArgumentNotValidException.class})

    @ResponseBody

    public ErrorResponseData validateException(MethodArgumentNotValidException e) {

        log.error("参数异常"+e.getBindingResult().getFieldError().getDefaultMessage(),e);

        return new ErrorResponseData(10001,e.getBindingResult().getFieldError().getDefaultMessage());

    }



    /**

     *  处理json转换异常(比如 @DateTimeFormat注解转换日期格式时)

     */

    @ExceptionHandler({HttpMessageNotReadableException.class})

    @ResponseBody

    public ErrorResponseData jsonParseException(HttpMessageNotReadableException e) {

        log.error("参数异常"+e.getLocalizedMessage(),e);

        return new ErrorResponseData(10001,e.getCause().getMessage());

    }



}

标题又名：简单弹窗、多弹窗、复杂弹窗怎么做代码和状态的解耦。

关键字：react / modal

问题

实际业务中，不乏弹窗组件中包含大量复杂的业务逻辑。如：

function Order() {

    // 省略上百行方法状态

    const [visible,setVisible] = useState(false)

    const withModalState = useState<any>()

    

    return (

        <Modal>

            <Input/>

            <Input/>

            <Select/>

            <Checkbox/>

        </Modal>

    ) 

}

甚至还有多弹窗的情形。如：

function Order() {

    // 省略上百行方法状态

    const [visible1,setVisible1] = useState(false)

    const [visible2,setVisible2] = useState(false)

    const [visible3,setVisible3] = useState(false)

    

    const withModalState1 = useState<any>()

    const withModalState2 = useState<any>()

    const withModalState3 = useState<any>()

    

    // 省略 不懂多少 handlexx

    return (

        <main>

            ...

            <Modal1></* 省略很多代码 */></Modal1>

            <Modal2></* 省略很多代码 */></Modal3>

            <Modal3></* 省略很多代码 */></Modal3>

        </main>

    ) 

}

​

非常的痛：

1. 如果弹窗在处理完内部流程后，又还有返回值，这有又会有一大通的处理函数。


2. 如果这些代码都写在一个文件中还是不太容易维护的。

而且随着业务的断增长，每次都这么写还是很烦的。

期望的使用方式

因此有没有一种更贴近业务实际的方案。

让弹窗只专注于自己的内部事务，同时又能将控制权交给调用方呢。

或者说我就是不喜欢 Modal 代码堆在一起……

如下：

// Modal1.tsx

export function Modal1(props) return <Modal></* ... */></Modal>



// 甚至可以将MOdal中的逻辑做的更聚合。通过2次封再导出给各方使用

export const function Check_XXX_Window() {/* */ return open(Modal1)}

export const function Check_XXX_By_Id_Window() { return open(Modal1)}

export const function Check_XXX_Of_Ohter_Window() { return open(Modal1)}



// Order.tsx

function Order() {



    function xxHndanle { 

        const expect = Check_XXX_Window(Modal1,args) // 调用方法，传入参数，获得预期值 ，完成1个流程

    }

    return (

        <main>

            ...

            // 不实际挂载 Modal 组件

        </main>

    ) 

}

像这样分离两者的代码，这样处理起来肯定是清爽很多的。

实现思路

实现的思路都是一致的。

1. 创建占位符组件，放到应用的某处。


2. 将相关状态集管理，并与Modal做好关联。


3. 暴露控制权。

因此基于不同的状态管理方案，实现是多种多样的。相信很多大佬都自己内部封装过不少了。

但是在此基础上，我还想要3点。

1. API使用简单，但也允许一定配置。


2. 返回值类型推导，除了帮我管理 close 和 open 还要让我用起来带提示的。


3. 无入侵性，不依赖框架以外的东西。

ez-modal-react

emm......苦于市面上找不到这类产品（感觉同类并不多……讨论的也不多？）

于是我自己开源了一个。回应上文实现思路，可以点击看代码，几百行而已。

并不是突发奇想而来，其实相关特性早就在企业内部是使用多年了。我也是受前辈和社区启发。

基本特性

1. 基于Promise封装


2. 返回值类型推导


3. 没有入侵性，体积小。

使用画面

import EasyModal, { InnerModalProps } from 'ez-modal-react';



+ interface IProps extends InnerModalProps<'fybe?'> /*传入返回值类型*/ {

+   age: number;

+   name: string;

+ }



export const InfoModal = EasyModal.create(

+ (props: Props) => {

  return (

    <Modal

      title="Hello"

      open={props.visible}

      onOk={() => {

+       props.hide(); // warn 应有 1 个参数，但获得 0 个。 (property) hide: (result: "fybe?") => void ts(2554)

      }}

      onCancel={() => {

       props.hide(null); //safe hide 接受 null 作为参数。它兼具 hide resolve 两种功能。

      }}

    >

      <h1>{props.age}</h1>

    </Modal>

  );

});



+ // warn 类型 "{ name: string; }" 中缺少属性 "age"，但类型 "ModalProps<Props, "fybe?">" 中需要该属性。

EasyModal.show(InfoModal, { name: 'foo' }).then((resolve) => {

  console.log(resolve);

+ //输出 "fybe?" 

});

也支持用 hook

import EasyModal, { useModal, InnerModalProps } from 'ez-modal-react';



interface IProps extends InnerModalProps<'苏振华'>/* 指定返回值类型 */ {

  age: number;

  name: string;

}



export const Info = EasyModal.create((props: Props) => {

  const modal = useModal<Props>(); 



  function handleOk(){

      modal.hide(); // ts(2554) (property) hide: (result: "苏振华") => void ts(2554)

  } 



  return  <Modal open={modal.visible} onOk={handleOk} onCancel={modal.hide}></Modal>

});





EasyModal.show(Info,{age:18,}) // 缺少属性 "age"

还有一些特性如支持配置 hide 弹窗时的默认行为。（我认为大多数情况下可能用不上）

export const Info = EasyModal.create((props: Props) => {

  const modal = useModal<Props>(); 



  function handleOk(){

      modal.hide(); 

+     modal.resolve('苏振华') // 需要手动抛出成功

+     modal.remove() // 需要手动注销组件。可用于反复打开弹窗，但是不希望状态被清除的场景。

  } 



  return  <Modal open={modal.visible} onOk={handleOk} onCancel={modal.hide}></Modal>



// Ohter.tsx

EasyModal.open(Info, {},

+  config:{

+    resolveOnHide:false, // 默认为 true

+    removeOnHide:false,  // 默认为 true

+  }

);

当然以上是针对弹窗内有复杂业务场景的状况。

大部分场景都是调用方只在乎 open或close ，仅仅解耦代码这一项好处，就可以让代码变得清爽。

如常用的有展示类，设置类的弹窗，TS类型都用不上。

仓库

其他就不一一介绍了，主要的已经说完了，想了解更多，可以看看仓库。github

🎮 Codesandbox Demo

Codesandbox是一个线上集成环境，可以直接打开玩玩。点击 Demo Link 前往

初衷

让弹窗使用更轻松。

包名 ez 开头，是因为我DOTA在东南亚打多了，觉得该词特别贴切。

授之于鱼叉

GitHub仓库地址
：ez-modal-react

觉得有用帮我点个星~~~ 感恩，有啥问题可以提出，看到会回复。如果有需要会持续维护该项目。

下列诸神，望您不吝赐教

PNPM是什么？

在日常工作里面，总是有同事让我将npm替换成pnpm，理由是这玩意速度更快，效率更高。那到底pnpm是什么呢？他为什么比npm/yarn有着更大的优势？
首先，毫不疑问，pnpm是作为一个前端包管理器工具被提出的，作者的初衷是为了能够开发出一款能够有效节省磁盘空间，提高安装速度的包管理工具。
其次，npm和yarn存在的诸多问题，也让开发者诟病已久，pnpm也是在这样的背景下被开发出来并广受欢迎的。

PNPM解决了什么样的问题？

在讨论pnpm解决了什么样的问题之前，我们可以先看看npm和yarn这些传统包管理工具到底存在什么样的问题。

NPM 2

在Npm2.x里面，当你观察node_modules时，你会发现对于不同包之间的依赖关系，npm2.x采用的是层层嵌套的方式去管理这些依赖包。

对于依赖关系来说，嵌套的管理方式虽然让不同包之间的依赖关系一目了然，但是却存在着诸多的问题。

• 公共的依赖无法重复利用。不同的包里难免会存在相同的依赖，但是在npm2.x里面，这些公共依赖会被复制很多次，存在于不同的包的嵌套node_modules里，这样会导致下载速度的下降以及浪费了许多磁盘空间。


• **嵌套关系过深时，路径名过长。**在window下，有很多程序无法处理超过260个字符的文件路径名，如果嵌套关系过深时，就有可能会超出这个限制，导致windows下存在无法解析的现象。

NPM 3 & YARN

针对上述Npm 2存在的两个典型的问题，Yarn和Npm3采用了扁平化的依赖管理方式，所有的依赖不再层层嵌套，而是全部都在同一层，这样就同时解决了重复依赖多次复制和路径名过长的问题了。

可以看到使用npm3安装的express使，大部分的包都不会有二层的node_modules的，当然，如果同时存在多个版本的包时，则还是会出现部分嵌套node_modules的情况。
另外，Yarn和Npm 3都采用了lock文件，借此来保证每次拉取同一个项目的依赖时，使用的是同一个版本，避免不同版本之间的差异性导致的项目Bug。
但是，问题又来了，难道使用了扁平化的依赖管理方式就是完美的吗，这种管理方式会不会产生新的问题？答案否定的，扁平化的管理方式会导致两个最主要的问题

• 幽灵依赖


• 磁盘空间问题没有完全解决

幽灵依赖

幽灵依赖是指你的项目明明没有在package.json文件里声明的依赖，但是在代码里面却可以使用到。导致这个问题的最主要的原因就是，依赖扁平化了，当你的项目寻找依赖的时候，可以找到所有node_modules里的最外层依赖。
显然，幽灵依赖是会带来隐患的，当你依赖的包A有一天不再需要包B了， 你对B的幽灵依赖就会导致错误，从而发生问题。

磁盘问题

当同一个项目依赖了某个包的多个版本时，Npm3和Yarn只会提升其中的一个，而其余版本的包还是不能避免复制多次的问题 。

PNPM是如何解决这些问题的？

在讨论Pnpm的机制之前，我们需要先学习下一些操作系统相关的知识。

链接

链接实际上是一种文件共享的方式。在Linux的文件系统中，除了文件名和文件内容，还有一个很重要的概念，就是inode，inode类似于C语言的指针，它指向了物理硬盘的一个区块，只有有文件指向这个区块，他就不会从硬盘中消失。而硬链接和软连接最大的区别，则是inode的与原文件的关系。

硬链接

一般来说，inode与文件名、文件数据是一对一的关系，但我们可以通过shell命令让多个文件名指向同一个inode，这种就是硬链接（hard link）。由于硬链接文件和源文件使用同一个inode，并指向同一块文件数据，除文件名之外的所有信息都是一样的。所以这两个文件是等价的，可以说是互为硬链接文件。修改任意一个文件，可以看到另外一个文件的内容也会同步变化。
也正是因为有多个相同的inode指向同一个区块，所以硬链接的源文件即使被删除，也不会对链接文件有任何影响。

软链接

软连接又称符号链接，与硬链接共用一个inode不同的是，软链接会创建一个新的inode，存放着源文件的绝对路径信息，并指向源文件。当用户访问软链接时，系统会自动将其替换为该软链接所指向的源文件的文件路径，然后访问源文件。
而PNPM则是利用了以上链接的机制，来解决Npm和Yarn存在的问题。
当你使用Pnpm安装依赖时，Pnpm会在全局的仓库里保存一份npm包的内容，然后再利用链接的方式，从全局仓库里链接到你项目里的虚拟仓库，也就是node_modules里的是.pnpm。

你所安装的依赖，都会单独存放在node_modules下，而依赖所依赖的npm包都会通过软链接的方式，链接.pnpm里的虚拟仓库里的包，而.pnpm里的包，则是通过硬链接从全局Store里链接过来的。

通过软硬链接结合的方式，Pnpm可以很有效的解决了Npm和yarn遗留的问题：
1、抛弃了扁平化的管理方式，避免了幽灵依赖。
2、Npm包的存储方式都是放在全局，使用到的时候只会建立一个硬链接，硬链接和源文件共享同一份内存空间，不会造成重复依赖的空间浪费。另外，当依赖了同一个包的不同版本时，只对变更的文件进行更新，不需要重复下载没有变更的部分。
3、下载速度，当存在已经使用过的npm包时，只会建立链接，而不会重新下载，大大提升包安装的速度。

PNPM天生支持Monorepo？

monorepo 是在一个项目中管理多个包的项目组织形式。
它能解决很多问题：工程化配置重复、link 麻烦、执行命令麻烦、版本更新麻烦等。
而利用Pnpm的workSpace配合changesets，就可以很简单的完成一个Monorepo项目的搭建，所以说Pnpm天生就是Mo

在现代 Web 开发中，前端自动化已经成为了必不可少的一部分。随着项目规模的增加和开发人员的增多，手动部署已经无法满足需求，因为手动部署容易出错，而且需要大量的时间和精力。因此，自动化部署已经成为了前端开发的趋势。在本文中，我们将介绍前端自动化部署的基本原理和实现方式，并提供一些示例代码来说明。

前端自动化部署的基本原理

前端自动化部署的基本原理是将人工操作转换为自动化脚本。这些脚本可以执行一系列操作，例如构建、测试和部署应用程序。自动化部署可以帮助开发人员节省时间和精力，并提高应用程序的质量和可靠性。

自动化部署通常包括以下步骤：

1. 构建应用程序：使用构建工具（例如 webpack、gulp 或 grunt）构建应用程序的代码和资源文件。


2. 运行测试：使用测试工具（例如 Jest、Mocha 或 Karma）运行应用程序的单元测试、集成测试和端到端测试。


3. 部署应用程序：使用部署工具（例如 Jenkins、Travis CI 或 CircleCI）将应用程序部署到生产服务器或云平台上。

实现前端自动化部署的方式

实现前端自动化部署的方式有很多种，以下是其中的一些：

1. 使用自动化部署工具

自动化部署工具可以帮助我们自动化构建、测试和部署应用程序。这些工具通常具有以下功能：

• 与版本控制系统集成，例如 Git 或 SVN。


• 与构建工具集成，例如 webpack、gulp 或 grunt。


• 与测试工具集成，例如 Jest、Mocha 或 Karma。


• 与部署平台集成，例如 AWS、Azure 或 Heroku。

自动化部署工具可以帮助我们节省时间和精力，并提高应用程序的质量和可靠性。

以下是一个使用 Jenkins 自动化部署前端应用程序的示例：

pipeline {

  agent any

  stages {

    stage('Build') {

      steps {

        sh 'npm install'

        sh 'npm run build'

      }

    }

    stage('Test') {

      steps {

        sh 'npm run test'

      }

    }

    stage('Deploy') {

      steps {

        sh 'npm run deploy'

      }

    }

  }

}

在这个示例中，我们使用 Jenkins 构建、测试和部署前端应用程序。我们将应用程序的代码和资源文件打包到一个 Docker 容器中，并将容器部署到生产服务器上。

2. 使用自动化构建工具

自动化构建工具可以帮助我们自动化构建应用程序的代码和资源文件。这些工具通常具有以下功能：

• 支持多种语言和框架，例如 JavaScript、React 和 Vue。


• 支持多种模块化方案，例如 CommonJS 和 ES6 模块。


• 支持多种打包方式，例如单文件和多文件打包。


• 支持多种优化方式，例如代码压缩和文件合并。

以下是一个使用 webpack 自动化构建前端应用程序的示例：

const path = require('path');



module.exports = {

  entry: './src/index.js',

  output: {

    filename: 'bundle.js',

    path: path.resolve(__dirname, 'dist'),

  },

  module: {

    rules: [

      {

        test: /.js$/,

        exclude: /node_modules/,

        use: {

          loader: 'babel-loader',

        },

      },

      {

        test: /.css$/,

        use: ['style-loader', 'css-loader'],

      },

    ],

  },

};

在这个示例中，我们使用 webpack 构建前端应用程序的代码和资源文件。我们将应用程序的入口文件设置为 src/index.js，将输出文件设置为 dist/bundle.js，并使用 Babel 转换 JavaScript 代码和使用 CSS Loader 加载 CSS 文件。

3. 使用自动化测试工具

自动化测试工具可以帮助我们自动化运行应用程序的单元测试、集成测试和端到端测试。这些工具通常具有以下功能：

• 支持多种测试框架，例如 Jest、Mocha 和 Jasmine。


• 支持多种测试类型，例如单元测试、集成测试和端到端测试。


• 支持多种测试覆盖率工具，例如 Istanbul 和 nyc。


• 支持多种测试报告工具，例如 JUnit 和 HTML。

以下是一个使用 Jest 自动化测试前端应用程序的示例：

test('adds 1 + 2 to equal 3', () => {

  expect(sum(1, 2)).toBe(3);

});

在这个示例中，我们使用 Jest 运行一个简单的单元测试。我们将 sum 函数的输入设置为 1 和 2，并将期望输出设置为 3。如果测试通过，Jest 将输出 PASS，否则将输出 FAIL。

结论

前端自动化部署已经成为了现代 Web 开发的趋势。通过使用自动化部署工具、自动化构建工具和自动化测试工具，我们可以节省时间和精力，并提高应用程序的质量和可靠性。在未来，前端自动化部署将会变得更加普遍和重要，因此我们需要不断学习和掌

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

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

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

2. 掌控情绪

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

3. 管理焦虑和压力

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

4. 培养自律习惯

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

5. 自我反思和反馈

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

6. 持续学习和自我发展

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

结论

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

“啊！” 我今天居然被通知裁员了！！！

虽然之前一直盛传我们这边要裁员，但是我想着，应该一时半会轮不到我这边，我感觉我们项目还是相对挣点钱的。但是呢，心里也是挺忐忑的。

今天，我正在那全心全意的敲代码，敲的正起劲呢。我突然看到我们项目经理被叫走了。啊？我一想啥情况？要开会的话怎么只叫我们项目经理，怎么不叫我呀。

难道是要裁员？！难道真的是要裁员？！然后我就看着我们项目经理和我们的上级领导他们一起坐在小屋里聊了半天，啊，我的小心脏呀，我心里就祈祷呀：“千万不要裁员啊！千万不要裁员呀！千万不要裁员呀！！！”

等我们项目经理出来之后，他走到了我这边，然后 “啪” 拍了一下我的肩膀，然后 “哎” 叹了口气。他说：“我们这个项目要被裁掉了。”

我说心里特别失落，但还故作镇定的说：“为啥？我们的项目不是还挣钱呢吗？”

项目经理说：“哎，挣钱也不行。我们现在不需要这么多人了。我们现在的项目，没有一个大的发展了啊！你先等一会吧，等一会他们还得找你谈。”。他走的时候，又拍了拍我肩膀。

哎，当时我就感觉我心里呀那种失落感呀，没法说的那种感觉。果然，没一会，我们经理就来了。他过来之后跟我说：“走，请你到小屋里喝点水。”

我苦笑着跟他说：“经理，我能不去吗？我现在不渴。”

然后我们经理说：“哎，不行呀，我都已经给你倒好了，走吧走吧，歇会去。”

然后我就默默的跟他去了。进去之后呢，我们俩都坐下了。经理跟我笑着说：“恭喜你呀，脱离苦海了。”

哎，我当时心情比较低落，我说：“是呀，脱离苦海了，但又上了刀山了呀。哈哈哈。。。”

然后他说：“哎，确实是，没办法，现在，哎，公司也不容易。现在有一些项目确实得收缩。”

我说：“哎，这也没啥，这都很正常。咱公司还算不错的，最起码还让过了个节。很多公司什么都不管，就这样让走了呀。哎！”

后面我们就谈了一些所谓的那种离职补偿啊，等等一些列的东西**。**

反正当时感觉着吧，就是，嗯，聊完之后呢就准备出去嘛。然后走路的时候呀，就感觉这个腿上啊就跟绑了铅块一样。

当时我感觉，哎，裁员这玩意怎么说呢，都没法回去和亲人说呀，弄的一下午这个心里慌慌的。怎么跟家人交代呢？人至中年居然混成这样，哎！！！

郑重声明，本文不是为了制造焦虑，发文的原因有两个：

1. 我今年 33 了，一方面给大家展现下一个普通程序员 35 岁后能咋样？是送外卖还是跑滴滴？难道真的就找不到工作了吗？


2. 感觉我并没有走好自己的人生路，把自己的经历写出来发到网上，让年轻人以我为鉴，能更好的走好自己的人
   
   作者：程序员黑黑
   来源：juejin.cn/post/7110887208953282590
   生路。

前端开发，刚开始学的时候，我感觉自己就像个孩子，一脸懵懂。当时，我非常迷茫，不知道该从何开始学习。但是，我并没有放弃，因为我对前端开发充满了热情和兴趣。

刚开始学习时，我觉得 HTML、CSS 和 JavaScript 这些基础知识就已经够难了，但是当我开始接触一些流行的框架和库时，我才发现自己真正的水平有多菜。当时，我就像一只踩在滑板上的小猪，不断地摔倒，但是我并没有放弃，我一直在努力地学习和实践。

在学习的过程中，我遇到了许多困难和挑战，但是也有很多有趣的体验和经历。有一次，我在编写一个简单的网页时，花了一整天的时间，结果发现自己的代码有一个很小的错误，导致整个网页无法正常显示。当时我感觉自己就像一个猴子在敲打键盘，非常无助和懊恼。但是，通过不断地调试和修改，我最终找到了错误，并且成功地将网页显示出来。当时，我感觉自己就像一只成功攀爬上树的小猴子，非常自豪和兴奋。

除了遇到困难和挑战，我在学习前端开发过程中也经历了许多有趣的体验。有一次，我在编写一个小型的应用程序时，发现我的代码出现了一个非常有趣的小 bug。当用户在页面上进行操作时，页面上的一些元素会突然出现在屏幕的右侧，然后又突然消失不见。当时我还担心这个 bug 会影响用户的正常使用，但是后来发现这个 bug 其实很有趣，而且还能给用户带来一些意外的乐趣。于是我就把这个 bug 留了下来，并且在用户操作时添加了一些特效，让这个小 bug 变成了一个有趣的亮点。

总结一波：
第一点，学习前端开发需要有耐心。前端开发不是一个短时间内可以学会的技能，它需要大量的时间和精力。尤其是在学习的早期，你可能会觉得有些技术和概念非常难以理解。但是，只要你有耐心，坚持不懈地学习，最终你一定会掌握这些技能。

第二点，建立一个良好的学习计划非常重要。前端开发有很多不同的技术和概念，你需要有一个清晰的学习计划来帮助你系统地学习和掌握这些知识。首先，你需要了解 HTML、CSS 和 JavaScript 这三大基本技术。其次，你可以学习一些流行的框架和库，如 React、Vue、jQuery 等，这些技术可以帮助你更快捷地构建网站和应用程序。

第三点，实践是学习前端开发的关键。你可以通过练习编写代码来更好地理解前端开发的技术和概念。在学习的过程中，你可以尝试编写一些小项目，比如一个简单的网页或者一个小型的应用程序。通过实践，你可以更深入地了解前端开发的各个方面，并且提高你的编程技能。

第四点，不要害怕向他人寻求帮助。前端开发是一个非常开放和社交的领域，你可以通过参加社区活动、参与在线讨论、向他人寻求帮助等方式来更好地学习和成长。有时候，你可能会遇到一些困难，或者对某些概念不是很理解，这时候向他人寻求帮助是非常重要的。你可以参加一些线上或线下的前端开发社区，与其他开发者交流经验和技巧，也可以在 GitHub 等平台上查看其他人的代码，从中学习和借鉴。

第五点，不断更新自己的知识和技能。前端开发是一个不断发展和变化的领域，新技术和新概念层出不穷。因此，你需要不断地更新自己的知识和技能，跟上前端开发的最新动态。你可以通过阅读博客、参加培训课程、观看技术视频等方式来学习新的技术和概念。

总之，学习前端开发需要有耐心、建立一个良好的学习计划、实践、寻求帮助和不断更新自己的知识和技能。这些都是非常重要的，也是我在学习前端开发过程中得到的宝贵经验。通过不断地学习和实践，相信你我可以成为一名优