Open Geekhyt opened 2 years ago
你好，我是童欧巴。欢迎来到前端食堂的第 27 期技术周刊。从本期周刊开始，决定加入一个新的版块【随便聊聊】，聊聊技术以外的东西，可能是书单推荐，也可能是最近提升的认知，或者又养成了什么新习惯，让周刊更加丰富一些。
MDN 终于“买新皮肤了”，并由社区投票选出了新的 Logo。
在其 16 年的历史中经历了很多变化，从早期的 wiki 开始，到最近迁移到一个由 GitHub 支持的静态站点，共拥有超过 45000 名贡献者，它们还即将推出 MDN Plus 高级订阅服务，可以期待一下。
Interop 2022 是一个基准(benchmark),由三个主要浏览器实现的代表商定，并通过公开提名和审查过程开发，并得到了 Apple、Bocoup、Google、Igalia、Microsoft 和 Mozilla 的支持和意见。
该基准侧重于 15 个领域，开发人员认为在这些领域存在缺失或者跨浏览器存在兼容性问题。浏览器供应商们都同意专注于这些领域，为开发者提供更好的开发体验。包括 Cascade layers(级联层)、Color spaces and CSS color functions(颜色空间和函数) 、New viewport units(新的视口单位)、Scrolling(滚动)、Subgrid(子网格)等等。
自 Beta 版和 RC 版以后的新变化：
删除了编译命令中不必要的参数 react-jsx
编辑器实时获取 JSDoc 参数名称不匹配建议
还进行了一些内部重构
TypeScript 4.7 迭代计划
ECMAScript 规范是所有 JavaScript 实现行为的权威来源。该规范的实用性远远超出了被称为 “JavaScript 引擎开发人员” 的神话物种，对普通的 JavaScript 程序员很有用，只是大多数人都没有意识到。
这个文档为你阅读 ECMAScript 规范扫除了很多障碍，如果你愿意，一天读一点规范，那你的 JavaScript 水平一定也会稳步增进。
以 JavaScript/Node.js 开发人员的角度来学习 Rust 的一本电子书，从 JavaScript 生态映射到对应的 Rust 生态，为你尽可能的减轻学习 Rust 的成本。
Anand Chowdhary 分享了它经常问的一道面试题，打开Twitter.com，查看源代码并解释源码的前十行含义。
你能说出来几个？
产品经理更换后，因为文档不全，需要通过读代码来反推产品逻辑这事儿大家经历过吗？好一点的代码还可以读懂，差的代码很难读懂，导致项目维护成本极高。
探究项目里代码质量和可维护性的持续下降的原因，可能不仅在于时间紧迫、需求变动频繁，开发团队本身也要负主要的责任。
那么什么样的代码算是好的代码？
可以从代码的可扩展性、可维护性、可读性、可测试性等方面衡量，不过这些只是宏观层面。那么具体提升代码质量的方法有哪些呢？
SOLID、设计模式等等，还有本文的 DDD 和 ADT。
本文也是对提高代码质量的一次探索，举几个文中一针见血的例子：
你的代码里是否存在因为业复杂导致的越来越多的 flag 变量？或者各种 if/else 多层嵌套的逻辑？时间久了完全看不懂。
做业务的同学很难有全局的业务视角，面对 PD 的需求没有足够的话语权。哪怕需求设计的不合理，也只能先做，后面再去修正。
如果没有良好的协作流程，那么测试同学的测试范围取决于前端同学的测试范围。很多时候代码改动后会影响很多页面。要么测试同学测试不完整，要么需要测试同学全量回归，浪费了绝大的测试成本。
当有新人参与到项目中时，面对这种项目，也会被折磨的头大，需要花费大量的成本梳理清楚业务与代码的关联。
如何解决这些问题？状态机可能是答案之一。
TypeScript 类型系统：分布式条件类型全解
React Router v6 通关指南
推荐一些最近在读的书。
世界一直都很疯狂，不过如果搞明白了在这疯狂背后永恒的原则，搞清楚世界的运行原理，也许能够更加轻松的应对。推荐阅读《原则：应对变化中的世界秩序》
最近还在读 Daishi Kato 的新书《Micro State Management with React Hooks》，如果你对 React 的状态管理库 Zustand、Jotai、Valtio 的原理感兴趣的话也推荐给你。
关于开源组织掺杂政治这件事儿，尤大的处理方式是最优雅的。作为个人，可以在社交平台表达各自的立场，但请别在开源项目里面，让技术回归纯粹。到今天为止，Node.js 已经回滚了不当的横幅。轰炸 React Issue 的行为属实是没必要，反而会带来反作用。
你好，我是童欧巴。欢迎来到前端食堂的第 27 期技术周刊。从本期周刊开始，决定加入一个新的版块【随便聊聊】，聊聊技术以外的东西，可能是书单推荐，也可能是最近提升的认知，或者又养成了什么新习惯，让周刊更加丰富一些。
技术资讯
MDN 终于“买新皮肤了”，并由社区投票选出了新的 Logo。
在其 16 年的历史中经历了很多变化，从早期的 wiki 开始，到最近迁移到一个由 GitHub 支持的静态站点，共拥有超过 45000 名贡献者，它们还即将推出 MDN Plus 高级订阅服务，可以期待一下。
Interop 2022 是一个基准(benchmark),由三个主要浏览器实现的代表商定，并通过公开提名和审查过程开发，并得到了 Apple、Bocoup、Google、Igalia、Microsoft 和 Mozilla 的支持和意见。
该基准侧重于 15 个领域，开发人员认为在这些领域存在缺失或者跨浏览器存在兼容性问题。浏览器供应商们都同意专注于这些领域，为开发者提供更好的开发体验。包括 Cascade layers(级联层)、Color spaces and CSS color functions(颜色空间和函数) 、New viewport units(新的视口单位)、Scrolling(滚动)、Subgrid(子网格)等等。
自 Beta 版和 RC 版以后的新变化：
删除了编译命令中不必要的参数 react-jsx
编辑器实时获取 JSDoc 参数名称不匹配建议
还进行了一些内部重构
TypeScript 4.7 迭代计划
技术资料
ECMAScript 规范是所有 JavaScript 实现行为的权威来源。该规范的实用性远远超出了被称为 “JavaScript 引擎开发人员” 的神话物种，对普通的 JavaScript 程序员很有用，只是大多数人都没有意识到。
这个文档为你阅读 ECMAScript 规范扫除了很多障碍，如果你愿意，一天读一点规范，那你的 JavaScript 水平一定也会稳步增进。
以 JavaScript/Node.js 开发人员的角度来学习 Rust 的一本电子书，从 JavaScript 生态映射到对应的 Rust 生态，为你尽可能的减轻学习 Rust 的成本。
Anand Chowdhary 分享了它经常问的一道面试题，打开Twitter.com，查看源代码并解释源码的前十行含义。
你能说出来几个？
产品经理更换后，因为文档不全，需要通过读代码来反推产品逻辑这事儿大家经历过吗？好一点的代码还可以读懂，差的代码很难读懂，导致项目维护成本极高。
探究项目里代码质量和可维护性的持续下降的原因，可能不仅在于时间紧迫、需求变动频繁，开发团队本身也要负主要的责任。
那么什么样的代码算是好的代码？
可以从代码的可扩展性、可维护性、可读性、可测试性等方面衡量，不过这些只是宏观层面。那么具体提升代码质量的方法有哪些呢？
SOLID、设计模式等等，还有本文的 DDD 和 ADT。
本文也是对提高代码质量的一次探索，举几个文中一针见血的例子：
你的代码里是否存在因为业复杂导致的越来越多的 flag 变量？或者各种 if/else 多层嵌套的逻辑？时间久了完全看不懂。
做业务的同学很难有全局的业务视角，面对 PD 的需求没有足够的话语权。哪怕需求设计的不合理，也只能先做，后面再去修正。
如果没有良好的协作流程，那么测试同学的测试范围取决于前端同学的测试范围。很多时候代码改动后会影响很多页面。要么测试同学测试不完整，要么需要测试同学全量回归，浪费了绝大的测试成本。
当有新人参与到项目中时，面对这种项目，也会被折磨的头大，需要花费大量的成本梳理清楚业务与代码的关联。
如何解决这些问题？状态机可能是答案之一。
好文推荐
TypeScript 类型系统：分布式条件类型全解
React Router v6 通关指南
随便聊聊
推荐一些最近在读的书。
世界一直都很疯狂，不过如果搞明白了在这疯狂背后永恒的原则，搞清楚世界的运行原理，也许能够更加轻松的应对。推荐阅读《原则：应对变化中的世界秩序》
最近还在读 Daishi Kato 的新书《Micro State Management with React Hooks》，如果你对 React 的状态管理库 Zustand、Jotai、Valtio 的原理感兴趣的话也推荐给你。
关于开源组织掺杂政治这件事儿，尤大的处理方式是最优雅的。作为个人，可以在社交平台表达各自的立场，但请别在开源项目里面，让技术回归纯粹。到今天为止，Node.js 已经回滚了不当的横幅。轰炸 React Issue 的行为属实是没必要，反而会带来反作用。