1. 前言 我们统一每周周二开项目进度会议，每个项目的情况都不一样，有些问题就是需要讨论很久，所以时间是无法评估的。 我们不可能要求什么时间内一定要开完项目进度会议，只能说项目负责人需要知道项目进度会议的流程，并且逐渐按照流程执行。 一般情况下，每周开一次项目进度会议，任务通常不会太多，通常一次会议所需时间应该不会太长，但是我们把项目会议流程梳理之后就会发现，时间是大大超出我们预期的，如下所示： 项目进度情况（20 分钟） 问题反馈讨论（20 分钟） 任务验收 功能演示（20 分钟） 代码抽查（20 分钟） 文档查看（10 分钟） Bug 修复情况（10 分钟） 后续工作安排 任务安排（20 分钟） 加班情况（10 分钟） 项目人较多时，就需要 2 个小时左右；项目人较少时，也需要 1 个小时左右。我觉得项目会议时间在 1 - 2 个小时之内是可以接受的，但是开到 3 个小时以上就有点问题了。 要解决问题，最终还是要回到问题本身。项目进度会议时间过长，你的诉求到底是什么？最要解决的本质问题是什么？难道真的是项目时间过长吗？ 那我直接规定每次开会不能超过某个时长就好了，没必要在这里纠结那么多。 所以说，本质的问题不在项目会议时间过长，而在于这个项目进度会议的时间是否产生了价值，是否有必要。 那我们要清楚，到底是哪些问题，容易导致项目进度会议时间拉长呢？ 我想了一下，可能是这三种情况。 2. 没有在会前准备解决方案 有些问题没有在会前自己捋一遍，然后根据自己研究的结果，给出多个解决方案，并整理到文档中，然后发到项目讨论群里，而是自己闷头在研究，简单在脑里想了下，觉得想明白了，等到项目进度会议上再深入沟通。 在项目进度会议上，没有什么文档，大家就一起参与讨论了，只是口头沟通，然后七嘴八舌的，说什么都有，这样行不行，那样行不行？ 讨论没有任何依据，只是凭感觉，反正你一句我一句，再加上一些闲话，最终浪费了很多时间。 正确的做法应该是，在会前要把自己研究或者想到的解决方案，整理到文档中，要列举至少两三个方案，并把每个方案的优说明缺点清楚，最后在总结一栏，把自己推荐的方案标明清楚，并说明你选择该方案的原因。 当然你可能会说，有些难题是在会上反馈出来的，哪有时间去准备解决方案文档，很多都是靠沟通交流得出的。 如果是这种情况，那么可以简单沟通一下，然后回去整理好解决方案文档，发到项目讨论群里，然后叫上相关人员在座位上过一下，然后把最终结论补上文档即可。 3. 无关话题太多以及范围过大 有时在项目进度例会上，很多时候沟通是没有依据的，也就是没有围绕项目当前的情况进行，总是一连串旁枝末节的话题，一个接一个没完没了。 你说这些话题有必要讨论吗？ 当然有的，但是要看当前项目的情况和时机。比如有些规划是大半年以后的，有些甚至是几年后都不一定要做的，这些话题进行深入沟通可以增长个人的知识面，但是在当前没有什么意义，完全可以在私底下去了解。 如果觉得很有用处，可以在了解之后，叫上几个人在座位上探讨一番，而不是在项目进度会议上。 比如讨论 App 的功能，说着说着，又说到 Flutter 最近好像不太平，Flutter 组又裁员了，然后还在 GitHub 上面搞了一个社区的分支，单独维护，然后说不计划合并到 Google 的主分支上了，然后又讨论 Flutter 是不是要完蛋了？那我们后续开发 App 要换不要技术方案？那老项目要怎么维护？Android、iOS、鸿蒙、微信小程序这些跨平台要怎么解决等等。 完全没完没了，这些讨论当然有意义，但是，在项目进度例会上进行讨论，真的太不划算了。 ...

这几年项目进度例会的模式，都是按照上篇《18-过进度方式一：项目负责人进行全部功能演示》的方式进行的，其目的也在上篇说明清楚了，都是从项目负责人的能力提升方面考虑的，其会议流程是这样的： 第一步，项目负责人把当前项目情况进行汇报，然后重点问题说一下。 第二步，每个项目成员在自己的座位上，说一下上周做的事情，下周计划做什么，遇到什么问题。 第三步，散会。 但是，不同的阶段关注的重点不一样。 在项目进度例会中，对当前所做的工作进行验收，是很重要的一环，这些也在《16-项目的任务质量如何保证》中，把前因后果也说明清楚了。 本篇主要是探讨让项目负责人把全部功能进行演示和让项目成员依次汇报任务进度和演示，这两种方式不同之处在哪里？ 首先，我们要知道，参加会议的人，什么样的心态都有。有的人现在遇到了很多问题，亟需在会议上反馈出来，然后帮助他解决这些问题；有的人觉得我现在忙得很，又天天开会，真烦，能不能少开一点、少说一点，让我赶紧忙完，要不然就得加班了；有的人觉得真好啊，最好开一整天，又可以摸鱼了，等等。在这些心态之下，各人的反应也会不一样。但更深层的一点是，多一事不如少一事，你要让他主动去说，那太难了，你问了才会说，不问就不说，甚至你问了，也可能因为性格等各方面的原因，都不太愿意说太多。加上大部分人都在会上刷手机，不会有心思听那么多的。 在这样的情况之下，让项目负责人把全部任务进度进行汇报并演示可验收的功能，很难覆盖到其他项目成员。他们本身不会觉得和这个会议有什么太大的关系，反正就是听一听，看一看手机，到了时间散会就完事儿。也许有些人可能有问题要反馈，但是他不会主动去提。 所以，项目进度例会的整体流程就要进行调整： 第一步，项目负责人要对项目当前的情况进行汇报，比如延期风险高不高？有什么重点问题？说一下，同步下信息，以及后续要注意哪些方面，等等。 第二步，就是要项目成员依次到前面来，而不是在自己座位上。把自己上周完成了哪些任务说一下，哪些任务进度怎么样也说一下，然后是演示一下自己开发的功能或者一些技术文档，最后就是遇到了哪些问题？需要现在就讨论和解决，然后就是下周计划做什么？把这些信息都记录在会议记录文档上面。一方面可以减少项目负责人需要全面深入细节的工作；另一方面，可以侧面给项目成员一点压力。因为每次项目进度例会都要说一下工作内容，你如果上周完全都不用心，那么工作自然没什么产出，这样你总不能胡编乱造吧。冥冥之中，不需要谁整天盯着你工作，你自己清楚，无形之中，就会有约束力，也减少了项目负责人的管理工作。 第三步，项目负责人把项目成员过进度中反馈的待解决问题，都记录到会议记录文档里面。下次项目进度例会，会看下待解决的问题是否已经解决。 第四步，项目负责人要根据当前项目进度情况，再次强调要重点关注的点，然后评估下是否需要加班。如有需要，进行加班安排。 第五步，散会。 相信按上面这个流程，可以有效解决项目成员在会议上没有深入参与的问题，并且能起到日常工作的一些约束，加强自我管理的意识，达成期望的工作目标。

1. 前言 在前端开发中，业务组件的封装与管理是一个常见的难题。当多个项目共用同一个业务组件时，如何平衡不同项目的需求差异，同时保持组件的可维护性和可扩展性，成为了一个亟待解决的问题。 2 如何应对多项目需求差异 在业务组件封装过程中，我们常常会遇到这样的问题：项目 A 和项目 B 都使用了某个业务组件，但项目 A 迭代了需求，而这个需求在项目 B 中却用不到。如果这次为了满足项目 A 的需求而修改组件，那么未来项目 B 也可能出现类似但不完全相同的需求，难道每次都要通过特判来解决吗？ 实际上，业务组件的问题并非孤立存在，而是整个前端项目开发流程中的一个环节。我们需要从更高的层次、更宏观的角度去看待，梳理整个前端项目的开发流程，预见可能面临的问题，并逐一讨论解决方案、进行应用和验证，而不仅仅是解决业务组件自身的问题。 3. 期望的应用场景 我们期望构建一个高效、灵活的前端开发流程，具体场景如下： 提供一个基础的项目模板，其中包含常用的业务组件，如登录注册、首页、个人中心、用户管理等。这样，新的项目可以直接基于模板启动，减少重复工作。 通过动态配置主题色等功能，满足客户项目的定制化需求。例如，不同客户可能对界面风格有不同偏好，通过风格配置平台可以快速实现定制。 在菜单管理中配置好路由，从业务组件库中引入所需的业务组件。如果现有组件不满足需求，则可以迭代现有组件或新增组件。 4. 通用性与灵活性 业务组件应具备通用功能，能够满足大部分项目的需求，从而减少重复开发，提高开发效率。当遇到特殊需求时，可以采用组合式函数的方式，将逻辑单独抽离出来复用。同时，提供样式自定义功能，通过增加一个 .vue 文件来实现样式定制，从而复用组合式函数。这种做法既保持了组件的通用性，又提供了足够的灵活性来应对不同项目的需求。 5. 确保质量和稳定性 为了保证业务组件的质量和稳定性，单元测试是必不可少的环节。主要包括以下两个方面： 对组件的逻辑代码进行测试，确保其功能正确无误。 测试组件之间的交互是否符合预期，例如父子组件之间的数据传递、事件触发等。 6. 满足多样化需求 业务组件的风格动态设置是一个关键问题。以当前常见的明亮和暗黑风格为例，问题的根本原因并不在于组件自身，而在于项目。因此，需要设置的不是业务组件的主题，而是项目的主题。而项目是基于我们提供的项目模板开发的，所以项目模板需要提供风格动态设置功能。 最佳的实现方式是通过可视化页面进行配置，然后生成 CSS 文件，将其引入到项目中进行配置。这就需要开发一个可视化主题配置平台，比如 Arco Design Lab 平台（平台使用指南），能够很好地满足这一需求。 7. 总结 通过建立一套完整的开发规范、提供风格动态设置功能，我们可以有效地解决多项目需求差异的问题，提高开发效率和质量。

前言 本项目旨在开发一个展厅3D展示系统，主要功能为监控大屏与3D城市沙盘显示。项目涉及两台电脑屏幕，分别标记为A和B。A屏幕用于展示3D城市沙盘，用户点击沙盘中的特定区域时，B屏幕将显示与该区域相关的效果视频。因此，项目的核心在于如何构建3D城市沙盘以及实现两台电脑之间的通信功能。 解决方案 最初计划使用Three.js来开发3D城市沙盘，并通过Electron开发两个独立的应用程序，分别部署在A和B电脑上以实现通信功能。然而，在项目推进过程中，我们发现3D城市沙盘可以通过视频形式实现，仅需由UI设计团队制作一个3D城市沙盘视频即可。对于沙盘大屏的左右旋转功能，可以通过捕获手势事件来控制视频播放器的快进和后退操作，从而避免了使用Three.js开发3D沙盘的复杂工作。 电脑间通信验证 基于electron-vite-vue和ws框架，我们开发了两个应用程序：客户端和服务端。客户端部署在主屏（A电脑），服务端部署在副屏（B电脑）。当系统启动时，服务端将在本地创建一个WebSocket服务器，监听8080端口。客户端则创建一个WebSocket客户端实例，连接至该服务器，从而实现两台电脑之间的通信功能。 electron-vite-vue ws 假设B电脑的IP地址为192.168.28.112，我们首先在B电脑上创建一个WebSocket服务器，监听8080端口： const WebSocket = require('ws'); const wss = new WebSocket.Server({ port: 8080 }); wss.on('connection', function connection(ws) { ws.on('message', function incoming(message) { console.log('received: %s', message); }); ws.send('something'); ws.on('close', function clear() { console.log('client disconnected'); }); }); 接下来，在A电脑上创建一个新的WebSocket客户端实例，连接到B电脑的WebSocket服务器，用于发送消息： const WebSocket = require('ws'); // 本地调试 // const ws = new WebSocket('ws://localhost:8080'); // 连接`B`电脑的 `WebSocket` 服务器 const ws = new WebSocket('ws://192.168.28.112:8080'); ws.on('open', function open() { console.log('connected'); setInterval(() => { ws.send('Hello Server!' + Math.random()); }, 3000) }); ws.on('message', function incoming(data) { console.log(data); }); ws.on('close', function clear() { console.log('disconnected'); }); ws.on('error', function error(err) { console.error('WebSocket Error: ', err); }); 通过上述实现，A和B电脑之间的通信效果如下：

Algorithm 本周的算法题为 3280. 将日期转换为二进制表示 给你一个字符串 date，它的格式为 yyyy-mm-dd，表示一个公历日期。 date 可以重写为二进制表示，只需要将年、月、日分别转换为对应的二进制表示（不带前导零）并遵循 year-month-day 的格式。 返回 date 的 二进制 表示。 示例 1： 输入： date = "2080-02-29" 输出： "100000100000-10-11101" 解释： 100000100000, 10 和 11101 分别是 2080, 02 和 29 的二进制表示。 实现代码如下： const convertDateToBinary = function(date) { const [year, month, day] = date.split('-') const yearBinary = parseInt(year).toString(2) const monthBinary = parseInt(month).toString(2) const dayBinary = parseInt(day).toString(2) return `${yearBinary}-${monthBinary}-${dayBinary}` }; 解题思路： 将日期格式的字符串拆分为年、月、日三个部分。 利用 Number.prototype.toString() 方法中基数的特性，将数字转换为二进制字符串。 Review Scientists discover new water purification microbes - Breaking News English Lesson 科学家们在我们脚下的地球中发现了一种以前未知的微生物。密歇根州立大学的研究人员一直在探索地球表面下方和上方的一个区域，称为临界区。这个区域对于提供维持生命的条件至关重要。研究人员将这些微生物称为 CSP1-3。微生物可能是净化水过程的关键部分。微生物学家 James Tiedje 说，虽然土壤层负责雨水的大部分过滤，但 CSP1-3 也是必不可少的。他说：“CSP1-3 是清理土壤表层的清道夫。他们的工作是净化我们的饮用水。 Tiedje 博士和他的团队专注于生活在我们脚下 200 米深处土壤中的微生物。他说，CSP1-3 微生物可以去除供水中的有害污染物和碎屑。他现在想在他的实验室中培养 CSP1-3，以了解更多关于它们的特性。他认为它们可以用来清理土壤中的污染。他说：“我们不知道它们代谢顽固污染物的能力，如果我们能了解这一点，我们就可以帮助解决地球上最紧迫的问题之一。scitechdaily.com 网站称：“了解这个新发现的群体可以促进保护工作并帮助应对气候变化。 Tip 在平时写邮件和使用 typora 软件写日记的时候，特别苦恼怎么能快速插入日期，比如写日记，每次都要复制昨天的日记文档，然后修改时间，很是繁琐，所以就研究了一下，结果发现使用搜狗输入法就很快实现了。 使用搜狗输入法，在中文模式下，输入 rq ，则会自动显示日期格式 年月日 ，如下所示： ...