Kafka 和 RabbitMQ 都是流行的开源消息系统，它们可以在分布式系统中实现数据的可靠传输和处理。Kafka 和 RabbitMQ 有各自的优势和特点，它们适用于不同的场景和需求。本文将比较 Kafka 和 RabbitMQ 的主要区别，并分析何时使用 Kafka 而不是 RabbitMQ。

推荐博主开源的H5商城项目waynboot-mall，这是一套全部开源的微商城项目，包含一个运营后台、h5商城和后台接口。 实现了一个商城所需的首页展示、商品分类、商品详情、sku详情、商品搜索、加入购物车、结算下单、订单状态流转、商品评论等一系列功能。 技术上基于最新得Springboot3.0、jdk17，整合了Redis、RabbitMQ、ElasticSearch等常用中间件， 贴近生产环境实际经验开发而来不断完善、优化、改进中。

github地址：github.com/wayn111/way…

影响因素

1. 可扩展性：Kafka 旨在处理大容量、高吞吐量和实时数据流。它每秒能够处理数百万个事件，并且可以处理大量数据。另一方面，RabbitMQ 的设计更加灵活，可以处理广泛的用例，但可能不太适合大容量、实时数据流。
2. 耐用性：Kafka 通过将所有数据写入磁盘来提供高度的耐用性，这对于任务关键型应用程序非常重要。 RabbitMQ 还提供基于磁盘的持久性，但这可能不如 Kafka 提供的那么强大。
3. 延迟：RabbitMQ 设计为低延迟，这对于实时数据处理和分析非常重要。Kafka 延迟相比 RabbitMQ 会高一点。
4. 数据流：Kafka 使用无界的数据流，即数据持续地流入到指定的主题（topic）中，不会被删除或过期，除非达到了预设的保留期限或容量限制。RabbitMQ 使用有界的数据流，即数据被生产者（producer）创建并发送到消费者（consumer），一旦被消费或者达到了过期时间，就会从队列（queue）中删除。
5. 数据使用：Kafka 支持多个消费者同时订阅同一个主题，并且可以根据自己的进度来消费数据，不会影响其他消费者。这意味着 Kafka 可以支持多种用途和场景，比如实时分析、日志聚合、事件驱动等。RabbitMQ 的消费者从一个队列中消费数据，一旦被消费，就不会再被该队列其他消费者看到。这意味着 RabbitMQ 更适合一对一的通信或任务分发。
6. 数据顺序：Kafka 保证了同一个分区（partition）内的数据是有序的，即按照生产者发送的顺序来存储和消费。但是不同分区之间的数据是无序的，即不能保证跨分区的数据按照全局顺序来处理。 RabbitMQ 保证了同一个队列内的数据是有序的，即按照先进先出（FIFO）的原则来存储和消费。但是不同队列之间的数据是无序的，即不能保证跨队列的数据按照全局顺序来处理。
7. 数据可靠性：Kafka 通过副本（replica）机制来保证数据的可靠性，即每个主题可以有多个副本分布在不同的节点（broker）上，如果某个节点发生故障，可以自动切换到其他节点继续提供服务。 RabbitMQ 通过镜像（mirror）机制来保证数据的可靠性，即每个队列可以有多个镜像分布在不同的节点上，如果某个节点发生故障，可以自动切换到其他节点继续提供服务。
8. 数据持久性：Kafka 将数据持久化到磁盘中，并且支持数据压缩和批量传输，以提高性能和节省空间。Kafka 可以支持TB级别甚至PB级别的数据存储，并且可以快速地重放历史数据。RabbitMQ 将数据缓存在内存中，并且支持消息确认和事务机制，以提高可靠性和一致性。RabbitMQ 也可以将数据持久化到磁盘中，但是会降低性能和吞吐量。RabbitMQ 更适合处理小规模且实时性较高的数据。
9. 数据扩展性：Kafka 通过分区机制来实现水平扩展，即每个主题可以划分为多个分区，并且可以动态地增加或减少分区数量
10. 复杂性：与 RabbitMQ 相比，Apache Kafka 具有更复杂的架构，并且可能需要更多的设置和配置，因此它的复杂性也允许更高级的功能和定制。另一方面，RabbitMQ 更容易设置和使用。

应用场景

Kafka 适用场景和需求

• 跟踪高吞吐量的活动，如网站点击、应用日志、传感器数据等。
• 事件溯源，Kafka 保存着所有历史消息，可以用于事件回溯和审计。
• 流式处理，如实时分析、实时推荐、实时报警等。
• 日志聚合，如收集不同来源的日志并统一存储和分析。

RabbitMQ 适用场景和需求

• 中小项目，项目消息量小、吞吐量不高、对延时敏感。
• 遗留应用，如需要与旧系统或第三方系统进行集成或通信。
• 复杂路由，如需要根据不同的规则或条件来分发或过滤消息。
• 任务分发，如需要将任务均匀地分配给多个工作进程或消费者。

总结

在公司项目中，一般消息量都不大的情况下，博主推荐大家可以使用 RabbitMQ。消息量起来了可以考虑切换到 Kafka，但是也要根据公司内部对两种 MQ 的熟悉程度来进行选择，避免 MQ 出现问题时无法及时处理。

大家好，我是 方圆。最近在接口联调时发生了数据并发修改问题，我想把这个问题讲解一下，并把当时提出的解决方案进行实现，希望它能在大家以后在遇到同样的问题时提供一些借鉴和思考的方向。原文还是收录在我的 Github: enthusiasm 中，欢迎Star和获取原文。

1. 问题背景

问题发生在快递分拣的流程中，我尽可能将业务背景简化，让大家只关注并发问题本身。

分拣业务针对每个快递包裹都会生成一个任务，我们称它为 task。task 中有两个字段需要关注，一个是分拣中发生的 异常（exp_type），另一个是分拣任务的 状态（status）。另外，需要关注 分拣状态上报接口，通过它来记录分拣过程中的异常和状态变更。

一般情况下，分拣机在分拣异常发生时会及时调用接口上报，在分拣完成时调用接口来标记为完成状态，两次接口调用的时间间隔较长，不会发生并发问题。

但是有一种特殊的分拣机，它不会在异常发生时及时上报，而是在分拣完成时将分拣过程中发生的异常和分拣结果一起上报，那么此时分拣状态上报接口在同一时间内就会有两次调用，这时便发生了预期外的并发问题。

我们先看下分拣状态上报接口的执行流程：

1. 先查询到该分拣任务 task，默认情况下 exp_type 和 status 均为默认值0

2. 分拣异常修改 task 中的 exp_type，分拣完成修改 status 字段信息

3. 修改完成将 task 写入

数据库初始值为 1, 0, 0，分拣异常和分拣完成几乎同时上报，它们都读取到该值。分拣异常动作将 exp_type 修改为9，写入数据库，此时数据库值为 1, 9, 0；分拣完成动作将 status 修改为1，写入数据库，使得数据库最终值为 1, 0, 1，它将异常字段的值覆盖掉了。正常情况下，最终值应该为 1, 9, 1，分拣完成动作应该读取到分拣异常完成后的值 1, 9, 0 后再进行修改才对。

2. 解决方案

发生这个问题的原因很容易就能发现：两个事务同时执行 读取-修改-写入 序列，其中一个写操作在没有合并另一个写操作变更的情况下，直接覆盖了另一个写操作的结果，所以导致了数据的丢失。

这种问题是比较典型的 丢失更新 问题，可以通过对数据库读操作加锁或者改变数据库的隔离级别为可串行化使事务串行执行的方式进行避免。下面我会将大家在讨论避免丢失更新问题时提出的方案进行介绍，并尽可能的用代码来表现它们。

2.1 数据库读操作加锁和可串行化隔离级别

我们可以考虑：如果对每条Task数据修改的事务都是在当前事务完成之后才允许后续事务进行修改，使事务串行执行，那么我们就能够避免这种情况。比较直接的实现是通过显式加锁来实现，如下

select exp_type, status

from task

where id = 1

for update;

先查询该行数据的事务会获取到该行数据的 排他锁，后续针对该数据的所有读写请求都会被阻塞，直到先前事务执行完将锁释放。

这样通过加锁的方式实现了事务的串行执行。但是，在为SQL添加加锁语句时，需要确定是不是为该行数据加锁而不是锁住了整个表，如果是后者，那么可能会造成系统性能严重下降，而且还需要关注有哪些业务场景使用到了该SQL，是否存在长时间执行的只读事务使用，如果存在的话可能会出现因加锁导致延迟和系统性能下降，所以需要谨慎的评估。

此外，可串行化的数据库隔离级别也能保证事务的串行执行，不过它针对的是所有事务。一般情况下为了保证性能，我们不会采用这种方案（默认使用MySQL可重复读隔离级别）。

MySQL的InnoDB引擎实现可串行化隔离级别采用的是2PL机制：在第一阶段事务执行时获取锁，第二阶段事务执行完成释放锁。

2.2 针对业务只修改必要字段

如果异常状态请求仅修改 exp_type 字段，分拣完成仅修改 status 字段的话，那么我们可以梳理一下业务逻辑，仅将必要修改的字段写入数据库，这样就不会发生丢失更新的异常，如下代码所示：

// 处理异常状态请求，封装修改数据的对象

Task task = new Task();

tast.setId(id);

task.setExpType(expType);



// 更改数据

taskService.updateById(task);

在执行修改数据前，创建一个新的修改对象，并只为其必要修改字段赋值。但是还需要考虑的是：如果这个业务流程处理已经很复杂了，很可能不清楚该为哪些字段赋值而导致再发生新的异常，所以采用这种方法需要对业务足够熟悉，并且在修改完后进行充分的测试。

2.3 分布式锁

分布式锁的方法与方法一类似，都是通过加锁的方式来保证同时只有一个事务执行，区别是方法一的锁加在了数据库层，而分布式锁是借助Redis来实现。

这种实现方式的好处是锁的粒度小，发生锁争抢仅限于单个包裹，无需像数据库加锁一样去考虑锁的粒度和对相关业务的影响。伪代码如下所示：

// 分布式锁KEY

String distributedKey = String.format(DISTRIBUTED_KEY_PREFIX, packageNo);

try {

    // 分布式锁阻塞同一包裹号的修改

    lock(distributedKey);

    // 处理业务逻辑

    handler();

} finally {

    // 执行完解锁

    redissonDistributedLocker.unlock(distributedKey);

}

需要注意，lock() 加锁方法要保证加锁失败或发生其他异常情况不影响业务逻辑的执行，并设定好锁持有时间和等待锁的阻塞时间，此外解锁方法务必添加到 finally 代码块中保证锁的释放。

2.4 CAS

CAS是乐观的解决方案，它一般通过在数据库中增加时间戳列来记录上次数据更改的时间，当新的事务执行时，需要比对读取时该行数据的时间戳和数据库中保存的时间戳是否一致，以此来判断事务执行期间是否有其他事务修改过该行数据，只有在没有发生改变的情况下才允许更新，否则需要重试这个事务。样例SQL如下所示：

update task 

set exp_type = #{expType}, status = #{status}, ts = #{currentTs}

where id = #{id} and ts = #{readTs}

它的原理不难理解，但是实现起来可能会存在困难，因为需要考虑在执行失败后该如何重试，重试的方式和重试的次数需要根据业务去判断。

今天来跟大家讨论一下技术主管需要什么样段位的技术？

首先我要说明的一点，技术主管前提一定是技术出身。对于那些完全不懂技术，但是又身兼技术主管或者总监的同学，我这里就不再赘述，毕竟这个已经超出我目前理解力的范围。比如阿里云的王坚博士，基本上不懂技术细节，但是依然是阿里云的CTO，一手缔造了阿里云。

那我们这里再详细讨论一下，作为一名技术主管，到底应该有什么样的一个技术的段位？或者换句话来说，你的主管的技术水平需要到达什么样的一个水位？

先说结论，作为一名技术主管，一定是整个团队的技术架构师。像其他的一些大家所讨论的条件我觉得都是次要的，比如说写代码的多少，对于技术深度的钻研多少，带的团队人数多少等等，最核心的是技术主管一定要把控整个团队整个业务技术发展的骨架。

为什么说掌控团队技术架构是最重要的？因为对于一个团队来说无非就两点，第一点就是业务价值，第二点就是技术价值。

对于业务价值来说，有各种各样的同学都可以去负责业务上面的一些导向和推进，比如说产品经理，比如说运营同学。技术主管可以在一定程度上去帮助业务成功，甚至是助力业务成功，但是一定要明白技术同学一定要有自己的主轴，就是你对于整个技术的把握。因为业务上的决策说到底技术主管是只能去影响而非去决策，否则就是你们整体业务同学太过拉胯，无法形成战术合力的目的。

对于一线开发同学来说，你只要完成一个接一个的技术项目即可。但是对于技术主管来说，你就要把握整体的技术发展脉络。要清晰的明白什么样的技术架构是和当前的业务匹配的，同时又具备未来业务发展的可扩展性。

那为什么不能把整个技术架构的设计交给某一个核心的骨干研发同学呢？

所以这里就要明白，对于名技术主管来说，未必一定要深刻的钻研技术本身，一定要把技术在业务上的价值发挥到最大。所以在一定程度上来说，可以让适当的同学参与或者主导整个技术架构的设计，但是作为主管必须要了解到所谓的技术投入的产出比是什么。但是如果不对技术架构有一个彻底的理解，如何能决定ROI？

也就是在技术方案的选型里面一定要有一个平衡，能够用最小的技术投入获取到最大的技术利益，而非深究于技术本身的实习方式。如果一名技术主管不了解技术的框架或者某一些主干流程，那么就根本谈不上怎么样去评估这投入的技术产出比。一旦一名技术主管无法衡量整个技术团队的投入产出比，那就意味着整个团队的管理都是在抓虾和浑水摸鱼的状态，这时候就看你团队同学是否自觉了。

出现了这种情况下的团队，可能换一头猪在主管的位置上，业务依然运行良好。如果在业务发展好的时候，可能一直能够顺利推动，你只要坐享其成就可以了，但是一旦到了要突破困难的时期，或者在业务走下行的时候，这个时候你技术上面的优势就一点就没有了。而且在这种情况下，如果你跳槽到其他公司，作为一名技术主管，对方的公司对你的要求也是非常高的，所以这个时候你如果都说不出来你的技术价值对于业务上面的贡献是什么那想当然，你可能大概率就凉凉了。

那问题又回到了什么样的水平才能到达架构师这个话题，可以出来另一篇文章来描述，但是整体上来说，架构的本质首先一定要明白，为的就是业务的增长。

其次，架构的设计其实就是建造一个软件体系的结构，使得具备清晰度，可维护性和可扩展性。另外要想做好架构，基本的基础知识也必不可少，比如说数据库选型、分布式缓存、分库分表、幂等、分布式锁、消息架构、异步架构等等。所以本身来说做好架构师本身难度就非常大，需要长期的积累，实现厚积而薄发。如何成为一名优秀的架构师可以看我的公众号的其他文章，这里就不再详细的介绍了。

第二点是技术主管需要对于技术细节有敏感度。很多人在问一名主管到底应该具备什么样的综合能力，能不能用一种更加形象的方式来概括，我认为就有一句话就可以概括了。技术主管应该是向战略轰炸机在平常的时候一直遨游在大气的最上层能够掌控整个全局，当到了必须要战斗的时候，可以快速的补充下去，定点打击。

我参加过一次TL培训课程，讲师是阿里云智能交付技术部总经理张瑞，他说他最喜欢的一句管理概括，就是“心有猛虎，细嗅蔷薇”，也就是技术主管在平常的时候会关注于更大的宏观战略或策略，也就是注重思考全局，但是在关键的时候一定要关注和落地实际的细节。

换句更加通俗的话来说，就是管理要像战略轰炸机，平常的时候飞在万丈高空巡视，当发生了战斗的时候，立即能够实现定点轰炸。

所以如果说架构上面的设计就是对于整个团队业务和技术骨架的把握，那么对于细节的敏感度就是对于解决问题的落地能力。

那怎么样能够保证你自己有一个技术细节的敏感度？

我认为必要的代码量是需要的，也就是说对于一个主管来说，不必要写太多低代码，但一定要保证一定的代码量，让自己能够最好的，最快的，最贴近实际的理解实际的业务项目。自己写一些代码，其实好处非常多，一方面能够去巩固和加深自己对技术的理解，另外一方面也能够通过代码去更加理解业务。

当然贴近技术的方式有很多种，不一定要全部靠写代码来完成，比如说做code review的方式来完成，做技术方案的评审来完成，这都是可以的。对我来说，我就会强迫自己在每一个迭代会写上一个需求，需求会涉及到各方各面的业务点。有前端的，有后端的，也有数据库设计的。

自己亲自参与写代码或者code review，会让自己更加贴近同学，能够感知到同学的痛点，而不至于只是在空谈说教。

总结

所以对于一个技术主管来说，我认为首要的就是具备架构设计的能力，其次就是要有代码细节的敏感度，对全局和对细节都要有很强大的把控能力。

当然再总结一下，这一套理论只是适用于基础的管理者，而非高层的CTO等，毕竟不同的层级要求的能力和影响力都是不一样的。

引言

2023年，前端开发作为IT行业中备受关注的领域之一，正在经历着巨大的挑战和变革。然而，在当前行业不景气、失业率居高不下以及裁员潮席卷而来的情况下，许多人开始质疑前端开发的未来前景以及学习它是否依然有意义。本文将探讨这个问题并试图给出一些启示。

第一部分：前端的价值

前端开发作为网页和移动应用程序开发的重要组成部分，扮演着连接用户与产品的桥梁。前端技术的发展不仅推动了用户体验的提升，也对整个互联网行业产生了深远的影响。随着移动互联网的普及和技术的进步，前端在用户与产品之间的交互变得越来越重要。

对于企业而言，拥有优秀的前端开发团队意味着能够提供更好的用户体验、增强品牌形象、吸引更多用户和扩大市场份额。因此，前端开发的技能依然是企业争相追求的核心能力之一。

第二部分：行业不景气的背后

然而，正如每个行业都经历高低起伏一样，前端开发也面临着行业不景气带来的挑战。2023年，全球经济增长乏力、市场竞争激烈以及萧条的就业市场等因素，使得许多公司紧缩预算、停止招聘，并导致了失业率的上升和裁员的潮水。

在这种情况下，前端开发者需要重新审视自己的技能和市场需求。他们需要具备综合能力，包括对最新前端技术的深入了解、与其他团队成员的良好沟通合作能力以及持续学习和适应变化的能力。

第三部分：自我调整与进阶

面对市场变化和就业压力，前端开发者需要主动调整自己的发展路径。以下是一些建议：

1. 多元化技能：学习并精通多种前端框架和库，如React、Vue.js和Angular等。同时，了解后端开发和数据库知识，拥有全栈开发的能力，将会让你在就业市场上更具竞争力。
2. 学习与实践并重：不仅仅是学习新知识，还要将所学应用于实际项目中。积累项目经验，并在GitHub等平台分享你的作品，以展示自己的能力和潜力。同时，参加行业内的比赛、活动和社区，与他人交流并学习他们的经验。
3. 持续学习：前端技术发展日新月异，不断学习是必需的。关注行业的最新趋势和技术，参加培训、研讨会或在线课程，保持对新知识的敏感度和学习能力。

第四部分：面对就业市场的挑战

在面对行业不景气和裁员的情况下，重新进入就业市场变得更加具有挑战性。以下是一些建议：

1. 提升个人竞争力：通过获得认证、实习或自主开发项目等方式，提升自己在简历中的竞争力。扩展自己的专业网络，与其他开发者和雇主建立联系。
2. 寻找新兴领域：探索新兴的技术领域，如大数据、人工智能和物联网等，这些领域对前端开发者的需求逐渐增加，可能为你提供新的机会。
3. 转型或深耕细分领域：如果市场需求不断减少，可以考虑转型到与前端相关的领域，如UI设计、交互设计或用户体验设计等。或者在前端领域深耕细分领域，在特定行业或特定技术方向上寻找就业机会。

结论

 虽然当前的行业环境确实严峻，但前端开发作为连接用户与产品的重要纽带，在未来依然有着广阔的发展空间。关键在于前端开发者要不断自我调整与进阶，持续学习并适应市场需求。通过多元化技能、学习实践、提升个人竞争力以及面对市场挑战，前端开发者依然可以在这个变革时代中谋得一席之地。

前言

1、人情世故

如果做得好就会说是情商高，做不好会说是世故，这是冯仑老师一段话，然后怎么做不世故呢，也很难评判。

借着这个聊聊人情世故，在我看来它也是做事规则的一部分，我们发展很长一段历史，从不同的立场、不同的利益分出了派别，又从血缘关系分出了宗族，这些都是为了利益最大化的一个产物。

反观博主本人，典型理工男，执着技术研究，所以这块一直是弱项，不太会讲话，但是我人缘一直比较好的。当然有利也有弊，弊端的话比较明显的，当一个人说话很厉害的时候，会给人自信，给人觉得靠谱，当一个人说话不咋样的时候，其实也有好处，就是藏锋，你不说出来个人想法大家是不知道你心里的小九九的，所以保全了你自身。（当一个人份量足的时候，说话会引发很大的影响，所以你可以发现如果一个人在公开场合大发演讲，要么是初出茅庐要么就是有靠山）

2、人生的发展需要平台

王立群老师：人生发展往往需要平台，秦国李斯这么一个故事，他发现仓鼠跟厕鼠待遇很不一样，同样是一个物种，但是一个光明正大的吃着粮食，一个过街老鼠人人喊打，所以他悟到了一个道理，人生好的发展需要借助平台的。

我们今天讲的人物：曹操，我们还是从几个学习角度去看，一个是做事的方法，另一个我们从他的事迹里面看出成事的借力的这么一回事。

曹操

出身

他祖父是一个大太监，伺候皇后还有皇上，古代有三股力量，两股都是因为比较亲近产生的，一个是外戚，另一个太监，还有一股力量是文官，这个是人数最多的。那么他祖父权利很大的，然后收了一个义子也就是曹操的父亲，然后他本身属于夏侯家族，所以他带的资源是曹家还有夏侯家非常有实力。

他并没有说直接躺平，而是想着有所作为，接下来我们再看看他的做事方面

做事手段

1、许劭风评

古代有个一个规则，靠着这些有能力、有品德的人来进行推荐人才，曹操想出来做事，他找到许劭，一开始是不肯的，因为前面讲过三股力量，文官是很鄙视太监的，后面曹操使了点手段最终让许劭给他做了风评，然后他听完大笑而去。

idea：从这件事看做什么事都是有个窍门，这个方式是别人建议曹操这么干，所以做事要恰到好处。另外里面提到曹操使了点手段，哈哈透出了一个狠，有点东西。

2、傍大腿

曹操曾经在袁绍下面干活，然后好几次都把自己的精锐干没了，袁绍作为盟主，慷慨的给予兵马才得以恢复元气。

idea：我们看曹操的出身，这么牛逼的背景，他也需要大腿的支持，更何况普普通通的我们。

3、挟天子以令诸侯

这个是非常著名的历史典故，也是因为这个跟袁绍闹掰了，当汉献帝去了洛阳的时候，他马上去迎接，然后用这个发号施令讨伐别人。

idea：曹操的眼光十分毒辣，他看出潜在的价值，不愧是曹老板。

4、善用人才

像官渡之战，像迎接汉献帝，都是底下这批谋士给的主意，曹操手下文官是人才济济的，另外这个老板是善于听从这些好的计谋，这是非常重要的。

官渡之战，袁绍没有听从谋士的重兵把守粮草，导致给了曹操抓住了机会，乌巢一把火烧光了粮草。

个人看法

a、平台是重要的，借力也是需要的

从曹操的发迹来看，他站在一个大平台上面，不像刘备四处投奔。人并不是说能力很强就能表现出来，需要有平台，有这么伯乐去发现你，然后有这么一股力量在你困难的时候拉你一把，这是重要的。

b、曹操做事狠

这里的狠，不是残暴，而是毒辣，眼光毒辣、做事方式到位，我们从善用人才，许劭风评，挟天子以令诸侯，这些做的都很到位。举个例子，比如说我们要煮开一壶水，需要火柴、木头、可能需要鼓风工具，这都是关键那些点。

这个我们前面也提到了，做事一定要有所研究，事情的关键点是什么，当然有这么一群得力助手也很重要，发现关键突破点。所以古代对英雄标准是：腹有良策，有大气概。

c、驾驭人

司马家起来是在曹操去世后几代的事情，可以说在曹操在的时候，这些有心机的人没有动作的，侧面看出曹操的厉害之处，懂人心。在资治通鉴里面也有一个例子，就是桓温，他也是古代一个权臣，后面几代就不行了压不住这批人。

学历史，学读懂人心

历史里面基本都是那个朝代的精英，他们的事迹，做事方法，当然我们看到很多东西，包括抱负、无奈、遗憾；我们学的不仅仅是做事方法，避开权谋的陷阱，还有就是学习读懂人心、人性。当我们谈到这个，大家第一印象就是坏的人性，其实它是一种自然的表现，就像饿了就要吃饭。

《百家讲坛》里面讲了这么一个故事，曹操的下邳之战生擒了吕布，原本曹操很爱惜人才的，后面刘备的一句话：吕布对以往老板不好，而曹操生性多疑，最终嘎了吕布。王立群老师：人们往往看重结果，以结果说话，而不是问你这么做的原因。

是啊，我们在故事背后，看到整件事情人心的博弈，刘备被人称为仁义之君，但是他在那会落进下石了，因为他之前跟吕布有些矛盾的，吕布把他从原来的根据地赶走了，当然他说的也是事实。所以我们除了学习历史，还需要去洞察人心，往往这些能决定事情的走向。

我从4月开始离职开始全职做独立开发，算是真正踏进入了这条河流。在过去半年多了我也观察了很多独立开发者。自己目前算是过了新手村（有正常的开发节奏，有3万用户）。看到很多刚起步的独立开发者还是有很多疑问，所以分享一下我在独立开发最初期的一些经验。因为我也不是很成功（没有走的很远），所以只能分享独立开发前100天的经验。

先说一下我认为独立开发起步阶段面临的主要困难：

第一：没有公司的孤独感。如果是一个人全职开发就更寂寞了。即使有一两个合作伙伴，但是大概率也是异地，因此也算是网友性质的社交。人说到底是群居的，所以需要找到一种社交平衡。我想可能这也是很多独立开发白天要在外面地方待着的原因，也许一个人一直在家待着有点闷。

第二：无法建立产品的健康开发节奏。以前在公司的时候自己是流程里的一环，只关心自己分工的完成情况。做了独立开发以后，所有事情都需要自己决策。太多自由的结果就是没了方向。什么都想做，好像什么都可以做，又感觉什么都不好做。

第三：没有收入。产品从开始建造到有足够健康收入中间有一段过程。这还有一个前提要是一个真正有用户价值的产品。如果你起步的时候自己没有一个优势产品方向，又没有个人社区号召力，就算你的产品是好的，也需要一段时间（可长可短）才能获得有效收入。一上线就火的概率太小了。高强度投入一件事情，如果长期没有收入，家人会有很多质疑，可能最后自己也很怀疑自己。

我把这三点结合起来，编一个故事大家可能比较有画面了：

一个人做独立开发已经半年多了，产品设计都是自己做，也没有什么人可以讨论，不知道下一步该做什么。目前每天只有零星的新增。做了这么久，总共只有两三千的收入。看来做产品还得会营销**，打算最近开始学习一下运营**。最近也打算做一下AI产品，感觉这个赛道很火。老婆说如果不行就早点回去上班好了，总不能一直这样。家人们，你们说我应该坚持吗。

家人们会说你的产品很棒，会说你做的比他们强，会说下次一定，会说你未来会成功。但是家人们不会为你掏一分钱。

也许我们不知道如何成功，但是我们可以知道什么是失败。你知道的失败方式越多，你成功的概率就越大。总的来说，产品的成功就两个要点：有用户价值，能赚钱。注意，这两点是或的关系，不是且的关系。一个产品可以能赚钱，但是没有用。一个产品也可以有用，但是不赚钱。失败就是你做的产品：既没用，又不赚钱。

基于前面提到的三个困难，我得出的前100天最重要的事是：找到一个可行的产品迭代方向。和团队经过磨合，互相能有有效、信任的协作。找到一百个种子用户。你越早解决这三个困难，你越快走上轨道。

确认产品方向

如果你真的做过产品，你就知道最终正确的产品路径不是通过脑中的某刻灵光乍现得到的。所以不是那种大脑飞速运算解题的方式。这里有两件事情需要确认：大的产品方向，产品的路径。

比如阿里巴巴，马云不是一开始就做的淘宝网。他只是觉得互联网普及以后，电子商务会有需求。最开始做的是黄页，并不是淘宝网。但是他没有在第一个项目失败以后，去做门户网站。产品路径的例子是特斯拉。特斯拉很早就确定了先出高性能的跑车，高性能轿车（model s），有了前面的技术积累以后，最后通过推出平价的轿车赢得市场（model 3）。特斯拉在 model 3 大规模量产前都是亏损的。

所以最重要的是确认产品方向。这个方向要结合自身的情况进行设定，就是我在前面帖子里提到的要是你想做的，能做的。也许想达到的产品方向有很多工作量，这个时候就要有同步的产品路径。比如小米手机的创业，他们一开始就想造手机。但是直接启动手机的制造市场、技术都有很大的困难。于是他们先通过做 MIUI 入局。

这里面首先要有个大的方向判断，对于独立开发来说，我觉得张宁在《创作者》里提到的两个维度的方向挺有意思：大众、小众；高频、低频。这里面两两结合各有什么特点我这里就不展开了，大家可以自行体会。

但是可以明确的是，独立开发者做不了又大众又高频的应用。大众又高频，就不可能小而美。大众又高频，最后赢家除了产品能力，要有运营优势，要有资源优势。独立开发者通常没有运营优势和资源优势。另外一点，如果是小众低频，就一定要高忠诚，高付费转化。可以往大众低频或者小众高频的方向多想想。

产品方向选择还有一个建议就是要有秘密。成功的业务后面一定有秘密。秘密也回答了一个问题：如果这个需求真的存在，为什么用户选择了你的产品。

最初级的秘密就是信息差，你知道别人不知道，所以你可以，更早做，可以更低的成本，更高效，有更高的获客率。

更高级的秘密就是大家都能看到，但是大家知道了，但是大家不信（脑中想到了拼多多的砍一刀）。

最高级的秘密就是所有人都知道，但是他们做不到。

总结起来，你应该找到一个你有优势的细分方向。信息优势，洞察优势也是优势。

没有一发即中的银弹，最平凡的方式想很多方向，用最低成本进行最快速的验证。在反馈中渐渐明晰产品路径。如果你三个月不管反馈闷头做，只做出了一个产品方向。你失败的概率是很大的。所以我看到很多产品1.0 的时候就做会员，做社区，做跨平台我是很不理解的。其实这些功能在早期性价比很低。

我的方式是脑海中有10个想法，挑出3个想法做初步设计，选出一个或者两个想法做产品验证。可能是原型，数据是模拟的，没有设计，如果产品真的解决了痛点的话，用户会愿意用，然后他会给你反馈他想要更好的体验，他愿意付钱得到这些改进。这里的效率优势是，你能在更短的时间验证产品方向是不是对的。总比走了3个月才发现是一条死胡同要好。

开发者很容易因为想到一个想法很兴奋，觉得这个很有用，就闷头做了一个月。有可能的问题是，这个想法虽然是个痛点，但是这个痛点频次很低，场景很少，所以虽然有用，但是没人会愿意买单。所以尽量跳出自己的思维，从用户的角度来进行验证是很必要的。

团队协作

独立开发的开发方式和传统公司不同。需要建立一个全新的工作流程。在初期大家都是空白，所以需要通过产品迭代中，形成高效的开发默契。大家松散做东西，工作习惯，工作职责都需要有共识才行。

比如我合作的设计师早期喜欢一次做一大板块的整体设计，大概一周的工作量。初期我觉得我们对产品有激情，大家都应该有自由的发挥空间。但是做了一周的设计图和产品脑海中的产品行进方向不一致怎么办。在工作时间上，我合作的设计师因为目前还是兼职，他只能在下班后设计。然而我全职只在6点前工作。这又是一个要协调的地方。

如果你是一个产品，需要协调研发和设计，三个人协调就又更复杂了。要找到一个大家都舒服，高效的协作方式。

100个种子用户

独立开发最核心的一环就是找到一个健康的商业模式。产品方向和团队协作的目标都是为了未来可以达成一个健康的商业模式。我觉得太多独立开发者上来就把目标（野心）定的太高。一口吃不成胖子。独立开发早期的商业目标只有一个：尽快达成团队最低维持标准。一鸟在手胜过二鸟在林。不要在团队只有几个人的时候用几十个人的方式管理。

初期就要估算出产品（团队）能够持续运转的最低收入。这个成本越低，团队就越容易跑起来。当收入足够覆盖团队的成本后，你的心态就会得到极大的自由，可以尝试很多奇奇怪怪有趣的想法。所以早期不要想有多高的天花板，如何建立壁垒，就关心如何达成产品的及格生命线。谁会想做一个注定失败的产品呢。

早期在没有运营优势的情况下，最重要的指标就是用户满意度了。用户满意度，就暗示了这个产品有没有解决切实的用户问题，用户愿不愿意为你宣传。其实很多人都搞错了重点，在产品没有让100个种子用户满意前，新增的流量是没有意义的。因为再多的用户都会流失。竹篮打水一场空。如果你把产品的用户目标定在100个种子用户，你也就没了运营压力，可以关注在如何打造正确的产品上。在产品基本盘没有问题后，再思考后面的才有意义。

总结

总结起来三点就是：做什么（产品方向），怎么做（团队协作），为谁做（验证用户）。以上就是我全职独立开发3个多月以来肤浅的经验分享，希望对你有帮助。

你是否曾经有过类似的疑惑？

• 我尝试过好几次健身，但都坚持不下来，我是不是一个没有耐心，没有毅力的人？
• 领导反馈说我需要提升沟通能力(开发效率、主动性)，可是我要怎么提升呢？
• 我知道该怎么做，但就是做不到呀。

在我们的个人成长中，出现这些疑惑是很正常的，它们可以归纳为以下两个原因：

• 不知道方法
• 知道方法但不知道该怎样坚持

如果你经常被这两个问题困扰，长此以往，就会陷入自我怀疑的状态。这时，MORS 法则可以帮到你。

MORS 法则，又叫做具体性原则。MORS 法则认为，我们的行为只有符合Measured（可测评）、Observable（可观察）、Reliable（可信赖）、Specific（明确化） 这 4 个要素，才是一个具体的、可执行的行为。

针对上面说到的问题，我们不要光喊口号，而需要给出具体的、可执行的方案，然后行动起来！

也就是说，当你碰到一个很复杂的目标时，要尽量拆解目标，制定一系列符合 MORS 法则的行动计划，然后开始行动，这样就能达成目标。

让我用一个栗子来解释 MORS 法则，假想一下，你今年给自己立了一个 flag：“今年要跑半马(21公里)”。要是只有这样一个目标，你能做到吗？大概率是不能的，即使你知道要每天坚持跑步，也很难坚持下来。你有可能会被临时的一些事情耽搁了几天就放弃了；你有可能在坚持了一段时间之后发现自己“根本做不到”就放弃了。

想要达成这个大目标，你可以尝试先拆解目标。假设第一次开始跑步，你可以跑 1 公里，希望 10 个月后能跑 21 公里，那就是每个月要多跑 2 公里；然后再拆到每周要多跑 0.5 公里；然后再拆解到每 2 天多跑 0.07 公里左右。这样分拆之后，就可以罗列出每天的跑步行动计划，比如：xx月xx日，跑 1.14 公里；xx月xx+1日，跑 1.21 公里... 这些行动是符合 MORS 法则的：

• Measured：这些行动是可以被测量和评估的，你可以明确知道今天计划跑多少公里，最终有没有完成这个行动也可以很清楚地衡量和评估。
• Observable：这些行动是可见的，你要跑起来，可能需要一些跑步装备和资源（比如准备水），这些都是实实在在的行动，不是 YY。
• Reliable：这些行动是可以完成的，它不会太难，每天多跑 0.07 公里远远比多跑 20 公里要简单太多了，肯定能做到吧？
• Specific：这些行动是非常明确的，就是跑步，不会有什么歧义。

当然，肯定有更好的、更加符合运动理论的跑步计划，比如是不是每天跑，还是一周休息 2 天、是应该每天突破，还是隔一天突破等等。这里只是举例，就简单一点了。不过不管是什么跑步计划，原理是不变的。

当你制定了符合 MORS 法则的行动计划之后，就能够更加容易地达成目标，也更加容易坚持下来了。因为：

• 行动计划是具体的，明确的，可行的。相比原来的假大空的目标，它更容易做到！而且，按照这个行动计划来行动，就能达成目标。
• 能够不断地感受到成果，这会帮助你更容易坚持下来。在这个栗子中，就是每天都多跑了一些，感受到自己每天都在进步，这是强大的正反馈，会给予你力量。

注意不要跟 SMART 原则搞混了哈。SMART 原则是制定目标时使用的，MORS 法则是制定行动计划的时候使用的。它们有一些相同的点，比如 Measured 和 Specific，那是因为每一个行动本身也是带有目的性的，所以 MORS 法则和 SMART 原则会有重叠的地方。

好了，MORS 法则的介绍就到这里了，它的内容非常简单，但是 MORS 法则对于我们的个人成长来说，作用是非常大的，希望你们可以多加实践啦。

除了在个人成长上面有帮助之外，MORS 法则对于管理者指导下属也非常有用，后面有机会我再介绍吧。

加油，让我们从行动开始！

1. passive event listeners

passive event listeners 是一种新兴的web标准，Chrome 51中提供的新功能为滚动性能提供了巨大的潜在提升。Chrome Release Notes.

背景：所有的现代浏览器都有一个滚动功能的线程，可以保证即使在运行耗时的js代码时滚动也能够平滑进行，但这种优化部分因需要等待任何touchstart 和 touchmove处理程序的结果而失败，因为这些交互可能会通过调用preventDefault() 事件来完全阻止滚动。

于是有了 {passive: true}

通过将touch或wheel事件监听标记为 passive，开发人员承诺处理程序不会调用 preventDefault来禁用滚动。这使浏览器可以立即响应滚动，而无需等待js的执行，从而确保为用户提供可靠流畅的滚动体验。

2. 关于系统设计

   • 关于分层

分层一般是基于模块功能来分层，有时候分层不清晰可能是有哪些模块，各模块间的功能，整个功能流程不是很清楚。

有时候两个模块间的交互复杂度增加，可以考虑构建一个中间层。 这样可以保持两个模块不会杂糅相关度不是很高的处理逻辑，功能逻辑更纯粹，保持边界清晰，降低模块本身的复杂度。

3. 关于编程思维

仔细想来，虽然从事开发工作很久了，但是编程上还是很没有章法，架构设计能力较弱，多年来都是凭借以前热血和几分小聪明存活。

今日份反思：

拿到一个需求，分析该需求需要支持那些场景，为了支持这些场景它需要具备哪些功能，思考怎样实现这些功能，根据功能做模块划分，对这些模块进行分析，做逻辑抽象（也就是分层），然后整个需求实现的大致框架就心中有数了，开始产出技术方案。 技术方案产出后，按照技术方案的设想去实施，实施过程中可能会遇到没考虑到的场景，或者发现之前的设计不能很好的cover，调整设计，增加分层或者调整已有的分层，然后修改技术方案。 不断的经历上述过程，会慢慢的沉淀出一些业务通用的设计思路，这样下次再做技术方案的时候就不会很迷茫。脑子理清楚，而后出设计，实践后总结。

4. ShadowRealm API

一个进入 statge3 的新的 JavaScript 提案,用于创建一个独立的JavaScript运行环境，里面有独立的变量作用域。

数据结构：

declare class ShadowRealm {

  constructor();

  // 同步执行字符串，类似eval()

  evaluate(sourceText: string): PrimitiveValueOrCallable;

  // 返回一个Promise对象，异步执行代码字符串

  importValue(specifier: string, bindingName: string): Promise<PrimitiveValueOrCallable>;

}

使用场景：

• 在Web IDE 或 Web绘图应用程序中运行插件等第三方代码； 这种方式比iframe的实现更简单、灵活度更高，占用内存更少、代码的安全性更高。
• 用 ShadowRealms 中创建编程环境，运行用户代码，如codepen，codesandbox；
• 服务器可以在 ShadowRealms 运行第三方代码，防止第三方代码出错打挂主环境；
• 网页抓取和网页应用测试可以在ShadowRealms中运行；

补充：Node.js的vm模块与ShadowRealm API类似，但具有更多功能，缓存Javascript 引擎，拦截import() 等等。

5. 关于状态管理

做状态管理的核心就是监听数据的变化，监听数据的变化有两种方式：

• 提供api来修改，内部做联动处理（React的setState）
• 对对象做一层代理，set的时候做联动处理，同时get时收集所有依赖。（vue，mobx的响应式数据）

6. 需求/调研

关于需求调研，我还是很急躁，急急忙忙开始技术方案评审、开发、排期的话，就会导致整个开发过程很被动。

比较好的方式，前期对于自己做的需求，以及需求的各个功能依赖有比较充分的了解（不过这在很多功能依赖方都没有文档的情况下很难做到），然后写一个符合需求的简版的demo，对可能出现的阻塞点和解决方案心里有一个预期，把图纸画好，照着图纸开发，从而更好的掌控整个开发进度。

7. 功能/需求拆解

对功能需求的有效拆解，功能模块详细具体，粒度合适，不会太过细化，也不会忽略一些关键点，才能够更好的把控整个开发进度，评估可能出现的风险点。

8. 工具方法收敛思路

收敛-内部集中分发给各个具体的util处理，保证对外暴露的接口的统一，降低该方法使用的心智负担。

9. 关于「自顶向下」和「自底向上」

自顶向下：

程序设计时，先考虑整体，后考虑细节。先考虑全局目标，后考虑局部目标。不要一开始就过多追求总多的细节，先从最上层总目标开始设计，逐步使问题具体化。

模块化设计：一个复杂的问题，肯定是有若干稍简单的问题构成。模块化是把程序要解决的总目标拆解为子目标，再进一步细化分解为具体的小目标，把每一个小目标称为一个模块。

自底向上：

自底向上的设计简单来说就是先完成细节功能，每个细节功能抽象成一个运算符，然后将这些完成的细节功能组装到整体的架构中。

自动化的设计是不是就应该采用自底向上的设计思路，把每个需要的细节功能做抽象，使得配置规则的人可以任意组装，对于不支持的功能制造新的抽象？

10. eval 和 new Function的区别

eval 和 new Function都可以解析执行一段传入的字符串。但有以下不同的地方：

• eval中的代码是当前作用域，它可以访问当前函数中的局部变量和全局变量。new Function中的代码执行的作用域是全局作用域，不论它在哪个地方被调用，可访问的都是全局变量；
• eval接收函数作为字符串时需要“（”和“）”作为前缀和后缀，new Function不需要，new Function可以接收N个参数，最后一个参数作为函数体；
• eval不容易调试，用chromeDev等调试工具无法打断点调试；
• 性能问题，eval通常比其他替代方法更慢，因为他必须调用js解释器，而其他结构则可被现代js引擎优化；
• eval存在安全问题，因为可访问局部作用域的变量，其内部逻辑不可预测性很强，可能导致XSS攻击；

11. 乐观更新与保守更新

• 乐观更新（Optimistic Update）： 乐观更新：如果有编辑等改动，先更新前端页面，再像服务端发送请求，如果请求成功则结束操作，无需额外处理，若请求失败，则页面回滚到先前状态； 这样更新方式的优点是响应及时，缺点就是低概率的请求失败回滚的体验不太好。
• 保守更新（Perssimistic Update）： 保守更新：如果有编辑等改动，向服务端发送请求，等收到回复请求后再响应用户操作，在此之前用户都需要处于等待状态。 这样做的缺点是会使页面有比较大的延时感，优点是最终呈现的结果是可信赖、稳定可靠的。

12. 正交的概念

编程上的正交，从数学上引进这个词，用于表示相互独立，相互间不可替代，并且可以组合起来实现其他功能。比如if和for语言是正交的，但for和while与句的功能是有重叠的。逻辑运算not、and也是正交的，其他复杂的逻辑运算都可以用这三种基本运算叠加起来。 编程语言经常定义一组正交语法特性，相互间不可替代，组合起来可以实现其他功能。为了更方便使用，在基础特性之上，再添加一些额外特性。这些非基本的额外特性，成为语法糖。语法糖对语言的功能没有太大影响，只是有了，代码写起来更方便些。

13. 引入外部字体，因等待字体文件的加载而产生文字不可见问题的一些解决方案

• 临时显示系统字体：添加font-display: swap;到自定义字体的style中，在自定义字体加载好之前显示系统字体；
• 预加载网页字体：用<link rel="preload" as="font" >更早的获取字体文件。

14. 总结写技术文章的几个步骤，引导自己学习并践行：

• 学习优秀的人写的东西，看看他们的理解；
• 带着自己的疑问，和目前接收到的理解去读源码；
• 读完之后，按照自己最终的理解绘制相关逻辑的流程图；
• 针对关键功能模块做拆解和源码解读；
• 总结相关功能的实现机制，以及给我带来的启发和思考；

15. 关于团队中被高频讨论的去底座；

去底座不是完全失去对底座（数据）的访问能力，而是设计一个标准化的API来支持按需访问底座（数据）的能力。

前言

本文仅简单描述一下kotlin中常用到的scope function，如apply,let,run,with,also等函数的常用方法和选取。即使很多情况下选择不同函数，也同样都能达到最终效果，具体选择哪个函数我们不会严格约束，但如果你是对代码规范要求比较高的，最好建立良好的代码习惯。

一般对比

1. apply 函数接收一个 lambda 表达式作为参数，并返回被调用对象本身。通过 apply，可以在对象创建后立即对其进行链式操作，设置属性值、调用方法等。适合用于链式初始化或配置一些属性。

val person = Person().apply { 

        name = "John" 

        age = 30 

    }

2. also 函数接收一个 lambda 表达式作为参数，lambda 表达式中的 it 引用指向调用 also 的对象。通过 also，可以对对象进行额外的操作，而原对象仍然是函数调用的结果。适合用于在对象操作过程中执行额外的副作用操作。

val modifiedObject = myObject.also {

    // 额外操作 it

}

3. let 函数接收一个 lambda 表达式作为参数，lambda 表达式中的 it 引用指向调用 let 的对象。如果对象不为空，则执行 lambda 表达式内的操作，并返回 lambda 表达式的结果。适合用于安全地操作对象，避免空指针异常。

val result = nullableValue?.let {

    // 操作非空对象 it

}

4. run 函数接收一个 lambda 表达式作为参数，lambda 表达式中的 this 引用指向调用 run 的对象。通过 run，可以便捷地对对象进行多次操作，并返回最后一个表达式的结果。适合用于执行一系列操作并返回最终结果。

val result = myObject.run {

    // 对象操作1

    // 对象操作2

    // ...

    // 返回结果

}

5. with 函数接收一个对象和一个 lambda 表达式作为参数，lambda 表达式中的 this 引用指向传入的对象。通过 with，可以在没有对象接收者的情况下操作对象，并返回最后一个表达式的结果。适合用于对对象进行一系列操作，而无需在乎返回值。

val result = with(myObject) {

    // 对象操作1

    // 对象操作2

    // ...

    // 返回结果

}

小明的故事

故事是这样的

1. 小明今年上一年级
2. 但是家长跟学校说，小明是个天才，现在可以直接跳级到二年级
3. 学校给二年级分配的老师是王老师，是个女教师
4. 半学期后，王老师怀孕了需要休息，于是学校给王老师放假
5. 学校给二年级分配了新的李老师,小明有了新老师

下面是故事的代码：

data class Student(var name: String = "", var grade: String = "", var teacher: Teacher? = null) {

    //插班跳级

    fun needSkippingGrade(insertGrade: String) {

        this.grade = insertGrade

    }

}



data class Teacher(var name: String = "") {

    fun relax() {

        println("$name 休假了！")

    }

}



fun main() {



    //1. **小明**今年上一年级

    val xiaoming = Student()

        .apply {

            name = "小明"

            grade = "一年级"

            println("小明开始前: $this")

        }

        .also {

            //2.现在可以直接跳级到二年级

            it.needSkippingGrade("二年级")

            println("小明插班后: $it")

        }



    //3. 学校给二年级分配的老师是**王老师**，是个女教师

    val ownTeacher = xiaoming.teacher?.let {

        println("小明当前的老师不为NULL,是${it}")

    } ?: Teacher("王老师").also {

        xiaoming.teacher = it

        println("小明有了老师: $xiaoming")

    }

    

    fun changeStudentCurrentTeacher(student: Student): Teacher? {

        return student.run {

            teacher?.relax()

            Teacher("李老师")

        }

    }



    //4. 半学期后，王老师怀孕了需要休息，于是学校给王老师放假

    //5. 学校给二年级分配了新的**李老师**,小明有了新老师

    with(xiaoming) {

        println("开学了！")

        println("半学期后，王老师怀孕了！...")

        val newTeacher = changeStudentCurrentTeacher(this)

        println("新老师是$newTeacher")

        teacher = newTeacher

        println("小明有了新老师$this")

    }



}

输出结果：

小明开始前: Student(name=小明, grade=一年级, teacher=null)

小明插班后: Student(name=小明, grade=二年级, teacher=null)

小明有了老师: Student(name=小明, grade=二年级, teacher=Teacher(name=王老师))

开学了！

半学期后，王老师怀孕了！...

王老师 休假了！

新老师是Teacher(name=李老师)

小明有了新老师Student(name=小明, grade=二年级, teacher=Teacher(name=李老师))

最后

实际过程中，需要根据具体的场景和需求来选择适合的函数。前面这些函数在 Kotlin 中提供了更简洁、可读性更高的方式来处理对象，根据不同的使用场景，你可以选择最适合和更易读的函数来操作对象

什么是广播，简单点广播就是安卓系统本身发出的声音，我们可以通过安卓提供给我们的一系列内容来接收和发出广播，以此来简单快捷地实现一些功能。

在实际开发中也常常用到，而是否熟悉使用，这成为面试官最常问的问题。

当面试官问你：

1.请问BroadcastReciver的静态注册与动态注册的区别？，你在开发中用过吗？

答：

其实广播分为两种基本类型：

在一个程序中，可以发送广播供当前程序的广播接收器收到。首先我们来看下两种方式的发送广播。 在Android系统中，主要有两种基本的广播类型： - 标准广播（Normal Broadcasts） - 有序广播（Ordered Broadcasts）

标准广播：

是一种完全异步执行的广播，在广播发出之后，所有的广播接收器会在同一时刻接收到这条广播，广播无法被中断。

发送广播的方式十分容易的，只需要实例化一个Intent对象，然后调用context的** sendBroadcast() **方法。这样就完成了广播的发送。

        //intent中的参数为action

        Intent intent=new Intent("com.example.dimple.BROADCAST_TEST");

        sendBroadcast(intent);

有序广播：

是一种同步执行的广播，在广播发出之后，优先级高的广播接收器会先接收到这条广播，并可以在优先级较低的广播接收器之前终止发送这条广播。

        //intent中的参数为action

        Intent intent=new Intent("com.example.dimple.BROADCAST_TEST");

        sendOrderBroadcast(intent，null);//第二个参数是与权限相关的字符串。

到此时，如果你的程序中只有一个广播接收器的话，是体现不出有序广播的特点的， 右击包名——New——Other——BroadcastReceiver多创建几个广播接收器。

此时你还是会发现，所有的广播接收器是同时接收到广播消息的。注意上面介绍的时候说到优先级，这个时候我们需要设置优先级，在AndroidManifest文件中的Receiver标签中设置广播接收器的优先级。

        <receiver

            android:name=".MyReceiver"

            android:enabled="true"

            android:exported="true">

            <!--注意此时有一个Priority属性-->

            <intent-filter android:priority="100">

                <action android:name="android.intent.action.BROADCAST_TEST"></action>

            </intent-filter>

        </receiver>

优先级越高的广播接收器优先收到广播，也可以在收到广播的时候调用abortBroadcast() 方法截断广播。优先级低的广播接收器就无法接收到广播了。

面试官，假设我有一个接收者如下：

在Android的广播接收机制中，如果接收到广播，就需要创建广播接收器。而创建广播接收器的方法就是新建一个类（可以是单独新建类，也可以是内部类（public）） 继承自BroadcastReceiver

   class myBroadcastReceiver extends BroadcastReceiver{



        @Override

        public void onReceive(Context context, Intent intent) {

            //接收到广播的处理，注意不能有耗时操作，当此方法长时间未结束，会报错。

            //同时，广播接收器中不能开线程。

        }

    } 

面试官，接下来就是面临注册的问题了，有两种注册方式，一种是动态注册，一种是静态注册。

所谓动态注册是指在代码中注册。步骤如下 ：

• 实例化自定义的广播接收器。
• 创建IntentFilter实例。
• 调用IntentFilter实例的addAction()方法添加监听的广播类型。
• 最后调用Context的registerReceiver(BroadcastReceiver,IntentFilter)动态的注册广播。

这个时候，已经为我们自定义的广播接收器关联了广播，当收到和绑定的广播一直的广播的时候，就会调用广播接收器中的onReceiver方法。

        MyBroadcastReceiver myBroadcastReceiver=new MyBroadcastReceiver();

        IntentFilter intentFilter=new IntentFilter();

        intentFilter.addAction("com.example.dimple.MY_BROADCAST");

        registerReceiver(myBroadcastReceiver,intentFilter);

这里需要注意的是，如果需要接收系统的广播（比如电量变化，网络变化等等），别忘记在AndroidManifest配置文件中加上权限。另外，动态注册的广播在活动结束的时候需要取消注册：

    @Override

    protected void onDestroy() {

        super.onDestroy();

        unregisterReceiver(myBroadcastReceiver);

    }  

静态注册：

在创建好的广播接收器中添加一个Toast提示。代码如下：

public class MyReceiver extends BroadcastReceiver {

    @Override

    public void onReceive(Context context, Intent intent) {

        Toast.makeText(context,"开机启动！",Toast.LENGTH_LONG).show();

    }  

} 

然后在AndroidManifest文件中添加：

• 权限 <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"></uses-permission>

• Intent-filter

          <receiver
  
              android:name=".MyReceiver"
  
              android:enabled="true"
  
              android:exported="true">
  
              <!--添加以下3行-->
  
              <intent-filter>
  
                  <action android:name="android.intent.action.BOOT_COMPLETED"></action>
  
              </intent-filter>
  
          </receiver>
  
  

  此时重启Android系统就可以收到开机提示了。

总结：

动态注册和静态注册的不同：

动态注册的广播接收器可以自由的实现注册和取消，有很大的灵活性。但是只有在程序启动之后才能收到广播，此外，不知道你注意到了没，广播接收器的注销是在onDestroy()方法中的。所以广播接收器的生命周期是和当前Activity的生命周期一样。

静态注册的广播不受程序是否启动的约束，当应用程序关闭之后，还是可以接收到广播。

标准广播和有序广播的接收和发送都是全局性的，这样会使得其他程序有几率接收到广播，会造成一定的安全问题。为了解决这个问题，Android系统中有一套本地广播的机制。这个机制是让所有的广播事件（接收与发送）都在程序内部完成。主要是采用的一个localBroadcastReceiver对广播进行管理。

背景

今天突然听到隔壁在讨论同步屏障，听到这个名字，我依稀记得 Handler 里面是有同步屏障机制的，但是具体的原理怎么有点模糊不清呢？就像一个明星，你明明看着面熟，就是想不起来他叫啥，让我这样的强迫症患者无比难受，所以抽时间来扒一扒同步屏障。

同步屏障机制

1. 直奔主题，同步屏障机制这几个字听起来很牛逼，能浅显的解释一下，先让大家明白它的作用是啥不？

同步屏障实际上就是字面意思，可以理解为建立一道屏障，隔离同步消息，优先处理消息队列中的异步消息进行处理，所以才叫同步屏障。

2. 第二个问题，同步消息又是啥呢？异步消息和同步消息有啥不一样呢？

要回答这个问题，我们就得了解一下 Message，Message 的消息种类分为三种：

• 普通消息（同步消息）
• 异步消息
• 同步屏障消息

我们平时使用 Handler 发送的消息基本都是普通消息，中规中矩的排到消息队列中，轮到它了再乖乖地出来执行。

考虑一个场景，我现在往 UI 线程发送了一个消息，想要绘制一个关键的 View，但是现在 UI 线程的消息队列里面消息已经爆满了，我的这条消息迟迟都没有办法得到处理，导致这个关键 View 绘制不出来，用户使用的时候很恼怒，一气之下给出差评这是什么垃圾 app，卡的要死。

此时，同步屏障就派上用场了。如果消息队列里面存在了同步屏障消息，那么它就会优先寻找我们想要先处理的消息，把它从队列里面取出来，可以理解为加急处理。那同步屏障机制怎么知道我们想优先处理的是哪条消息呢？如果一条消息如果是异步消息，那同步屏障机制就会优先对它处理。

3.那要如何设置异步消息呢？怎样的消息才算一条异步消息呢？

Message 已经提供了现成的标记位 isAsynchronous 用来标志这条消息是不是异步消息。

4.能看看源码了解下官方到底怎么实现的吗？

看看怎么往消息队列 MessageQueue 中插入同步屏障消息吧。

private int postSyncBarrier(long when) {

    synchronized (this) {

        final int token = mNextBarrierToken++;

        final Message msg = Message.obtain();

        msg.markInUse();

        msg.when = when;

        msg.arg1 = token;



        Message prev = null;

        // 当前消息队列

        Message p = mMessages;

        if (when != 0) {

            // 根据when找到同步屏障消息插入的位置

            while (p != null && p.when <= when) {

                prev = p;

                p = p.next;

            }

        }

        // 插入同步屏障消息

        if (prev != null) {

            msg.next = p;

            prev.next = msg;

        } else {

            msg.next = p;

            // 前面没有消息的话，同步屏障消息变成队首了

            mMessages = msg;

        }

        return token;

    }

}

在代码关键位置我都做了注释，简单来说呢，其实就像是遍历一个链表，根据 when 来找到同步屏障消息应该插入的位置。

5.同步屏障消息好像只设置了when，没有target呢？

这个问题发现了华点，熟悉 Handler 的朋友都知道，插入消息到消息队列的时候，系统会判断当前的消息有没有 target，target 的作用就是标记了这个消息最终要由哪个 Handler 进行处理，没有 target 会抛异常。

boolean enqueueMessage(Message msg, long when) {

  // target不能为空

  if (msg.target == null) {

      throw new IllegalArgumentException("Message must have a target.");

  }

  ...

}

问题 4 的源码分析中，同步屏障消息没有设置过 target，所以它肯定不是通过 enqueueMessage() 添加到消息队列里面的啦。很明显就是通过 postSyncBarrier() 方法，把一个没有 target 的消息插入到消息队列里面的。

6.上面我都明白了，下面该说说同步屏障到底是怎么优先处理异步消息的吧？

OK，插入了同步屏障消息之后，消息队列也还是正常出队的，显然在队列获取下一个消息的时候，可能对同步屏障消息有什么特殊的判断逻辑。看看 MessageQueue 的 next 方法：

Message next() {

    ...

            // msg.target == null，很明显是一个同步屏障消息

            if (msg != null && msg.target == null) {

                // Stalled by a barrier.  Find the next asynchronous message in the queue.

                do {

                    prevMsg = msg;

                    msg = msg.next;

                } while (msg != null && !msg.isAsynchronous());

            }

    ...

}

方法代码很长，看源码最主要还是看关键逻辑，也没必要一行一行的啃源码。这个方法中相信你一眼就发现了msg.target == null，前面刚说过同步屏障消息的 target 就是空的，很显然这里就是对同步屏障消息的特殊处理逻辑。用了一个 do...while 循环，消息如果不是异步的，就遍历下一个消息，直到找到异步消息，也就是 msg.isAsynchronous() == true

7.原来如此，那如果消息队列中没有异步消息咋办？

如果队列中没有异步消息，就会休眠等待被唤醒。所以 postSyncBarrier() 和 removeSyncBarrier() 必须成对出现，否则会导致消息队列中的同步消息不会被执行，出现假死情况。

8.系统的 postSyncBarrier() 貌似也没提供给外部访问啊？这我们要怎么使用？

确实我们没办法直接访问 postSyncBarrier() 方法创建同步屏障消息。你可能会想到不让访问我就反射调用呗，也不是不可以。

但我们也可以另辟蹊径，虽然没办法创建同步屏障消息，但是我们可以创建异步消息啊！只要系统创建了同步屏障消息，不就能找到我们自己创建的异步消息啦。

系统提供了两个方法创建异步 Handler：

public static Handler createAsync(@NonNull Looper looper) {

    if (looper == null) throw new NullPointerException("looper must not be null");

    // 这个true就是代表是异步的

    return new Handler(looper, null, true);

}



public static Handler createAsync(@NonNull Looper looper, @NonNull Callback callback) {

    if (looper == null) throw new NullPointerException("looper must not be null");

    if (callback == null) throw new NullPointerException("callback must not be null");

    return new Handler(looper, callback, true);

}

异步 Handler 发送的就是异步消息。

9.那系统什么时候会去添加同步屏障呢？

有对 View 的工作流程比较了解的朋友想必已经知道了，在 ViewRootImpl 的 requestLayout 方法中，系统就会添加一个同步屏障。

不了解也没关系，这里我简单说一下。

（1）创建 DecorView

当我们启动了 Activity 后，系统最终会执行到 ActivityThread 的 handleLaunchActivity 方法中：

final Activity a = performLaunchActivity(r, customIntent);

这里我们只截取了重要的一行代码，在 performLaunchActivity 中执行的就是 Activity 的创建逻辑，因此也会进行 DecorView 的创建，此时的 DecorView 只是进行了初始化，添加了布局文件，对用户来说，依然是不可见的。

（2）加载 DecorView 到 Window

onCreate 结束后，我们来看下 onResume 对应的 handleResumeActivity 方法：

@Override

public void handleResumeActivity(ActivityClientRecord r, boolean finalStateRequest,

        boolean isForward, String reason) {

    ...

    // 1.performResumeActivity 回调用 Activity 的 onResume

    if (!performResumeActivity(r, finalStateRequest, reason)) {

        return;

    }

    ...

    final Activity a = r.activity;

    ...

    if (r.window == null && !a.mFinished && willBeVisible) {

        r.window = r.activity.getWindow();

        // 2.获取 decorview

        View decor = r.window.getDecorView();

        // 3.decor 现在还不可见

        decor.setVisibility(View.INVISIBLE);

        ViewManager wm = a.getWindowManager();

        WindowManager.LayoutParams l = r.window.getAttributes();

        a.mDecor = decor;

        l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;

        l.softInputMode |= forwardBit;

        ...

        if (a.mVisibleFromClient) {

            if (!a.mWindowAdded) {

                a.mWindowAdded = true;

                // 4.decor 添加到 WindowManger中

                wm.addView(decor, l);

            } else {

                a.onWindowAttributesChanged(l);

            }

        }

    }

    ...

}

注释 4 处，DecorView 会通过 WindowManager 执行了 addView() 方法后加载到 Window 中，而该方法实际上是会最终调用到 WindowManagerGlobal 的 addView() 中。

（3）创建 ViewRootImpl 对象，调用 setView() 方法

// WindowManagerGlobal.ddView()

root = new ViewRootImpl(view.getContext(), display);

root.setView(view, wparams, panelParentView);

WindowManagerGlobal 的 addView() 会先创建一个 ViewRootImpl 实例，然后将 DecorView 作为参数传给 ViewRootImpl，通过 setView() 方法进行 View 的处理。setView() 的内部主要就是通过 requestLayout 方法来请求开始测量、布局和绘制流程。

（4）requestLayout() 和 scheduleTraversals()

@Override

public void requestLayout() {

    if (!mHandlingLayoutInLayoutRequest) {

        checkThread();

        mLayoutRequested = true;

        // 主要方法

        scheduleTraversals();

    }

}



void scheduleTraversals() {

    if (!mTraversalScheduled) {

        // 1.将mTraversalScheduled标记为true，表示View的测量、布局和绘制过程已经被请求。

        mTraversalScheduled = true;

        // 2.往主线程发送一个同步屏障消息

        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();

        // 3.注册回调，当监听到VSYNC信号到达时，执行该异步消息

        mChoreographer.postCallback(

                Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);

        notifyRendererOfFramePending();

        pokeDrawLockIfNeeded();

    }

}

看到了吧，注释 2 的代码熟悉的很，系统调用了 postSyncBarrier() 来创建同步屏障了。那注释 3 是啥意思呢？mChoreographer 是一个 Choreographer 对象。

要理解 Choreographer 的话，还要明白 VSYNC。

我们的手机屏幕刷新频率是 1s 内屏幕刷新的次数，比如 60Hz、120Hz 等。60Hz表示屏幕在一秒内刷新 60 次，也就是每隔 16.6ms 刷新一次。屏幕会在每次刷新的时候发出一个 VSYNC 信号，通知CPU进行绘制计算，每收到 VSYNC，CPU 就开始处理各帧数据。这时 Choreographer 就上场啦，当有 VSYNC 信号到来时，会唤醒 Choreographer，触发指定的工作。它提供了一个回调功能，让业务知道 VSYNC 信号来了，可以进行下一帧的绘制了，也就是注释 3 使用的 postCallback 方法。

当监听到 VSYNC 信号后，会回调来执行 mTraversalRunnable 这个 Runnable 对象。

final class TraversalRunnable implements Runnable {

    @Override

    public void run() {

        doTraversal();

    }

}



void doTraversal() {

    if (mTraversalScheduled) {

        mTraversalScheduled = false;

        // 移除同步屏障

        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);



        if (mProfile) {

            Debug.startMethodTracing("ViewAncestor");

        }

        // View的绘制入口方法

        performTraversals();



        if (mProfile) {

            Debug.stopMethodTracing();

            mProfile = false;

        }

    }

}

在这个 Runnable 里面，会移除同步屏障。然后调用 performTraversals 这个View 的工作流程的入口方法完成对 View 的绘制。

这回明白了吧，系统会在调用 requestLayout() 的时候创建同步屏障，等到下一个 VSYNC 信号到来时才会执行相应的绘制任务并移除同步屏障。所以在等待 VSYNC 信号到来的期间，就可以执行我们自己的异步消息了。

各位，两个月没写文章了，这两个月发生了很多事，也让我产生了很多不一样的感悟。从上次发完《阅阿里大裁员有感》，我的手机里就推了越来越多的“裁员”、“经济下行”、“焦虑”等信息。我这边现在这家公司，虽然不裁员，但是执行了“SABC”绩效分布考核，什么内容大家应该也都清楚，最后给我打了个 B-。呵呵，扣工资 20%，变成所谓的绩效工资，下次考核看情况发放。

很多兄弟看到这可能会替我打抱不平，狗资本家，快去发起劳动仲裁。可是他们马上又下上另一剂猛药，那就是不停的 PUA 你，告诉你现在有家庭，要多努力，要一心扑在工作上，放心，下次一定给你打回来。

我承认，他们这些话术我都看过，基本相当于明牌。可依然我还是被影响到了，情绪十分低落，也没心思去劳动局跟他们 PK。对未来的预期瞬间变得很悲观，人要是一悲观了，真的干什么也提不起兴趣。我一门心思都扑在以后能干什么上，其它的啥也不想管，疯狂的在国内外门户上刷信息，希望能找到一条“赚钱之路”。我研究了 Web3、AI 绘画、搞自媒体、网赚攻略（什么视频搬运、抄书、小说转漫画等等），基本上信息流推给我的，我都研究了一遍。这些玩意越研究越让人焦虑，因为那些标题都起的特别的有煽动性，动不动就日入几万，而我发的那些，浏览量都破不了百。于是我就想研究更多的路子去赚钱，老实说，东南亚那边的情况，我也了解过一些。

后面我对家人的态度也越来越坏，经常不耐烦，看着我小孩我经常叹气，我想这他妈可能就是中年危机提前爆发了，总之那段时间人会越来越焦虑。

后来还是我一兄弟，邀请我一家人去平潭自驾游，我们其实也没玩几天，属于特种兵式旅游，两天两晚（晚上熬夜开车去）。回来之后心情就好多了，也没那么焦虑了。其实本来也没什么，君子不立于危墙之下，这里不行那就走。找不到就先干自己的项目（我有开源项目）。我其实对干这行还是蛮有兴趣的，应该持续坚持的干下去，半途而废干别的是下策。

回想下我那时候焦虑的经历，我以前根本看都不看那种赚钱文章的，因为我知道这些大部分是在卖课，可为什么那时候我着了魔一样呢？其实很大部分与网络有关系，你着急干什么，你就愿意看点什么，你看点什么，网络就给你推什么。这种消极循环人一旦深陷其中，光凭自己是很难走出来的。其实这种时候应该主动去接收一些积极乐观的情绪，有助于自己调整心态，网络给不了你，只有身边人能给你。

更深一步的想，所谓内卷是不是也是通过网络在传播着，深刻的影响到每一个人。所谓的“智能推荐算法”，真的智能吗？大家想看的一定就是适合每个人的吗？你不停的点击去看的信息，真的能帮助到你吗？网络是我们的工具，还是我们是网络的工具？

我想我们真的应该停下来，想想我们到底在多大程度上需要抖音、需要 BiliBili、需要知乎，也许它们真的没这么重要。

人生在世，我们到底应该追逐什么？或者说，追逐什么其实不重要，重要的是我们去追逐的过程。在这个过程中，没有内卷，没有与别人的竞争，只有对自我的审视和成长。

换句话说，我有多久没有好好了解自己了，那些独属于自己的东西，永远不会背叛的资源。我们常说的：能力、人脉、技术、视野。其实除此之外还有很多很多，我刷视频看到的有趣视频点的赞，我 Chrome 里收藏的网页，我百度网盘里躺着的分享资料等等等等，还有最重要的一项，就是我的身体和组成我身体的每一个部分：大脑、心脏、肺...... 有多久没有关注和了解它们了？在这个内卷的时代，每个人都在比拼都在竞争，都怕落于人后，都想快点挣更多的钱，这些，时常让我们忽视了对我们最重要的东西。

有趣的是，每个平台都在疯狂的更新自己的算法，期望能更精准的描述一个人，给人打上各种各样的标签。但在这场竞赛中，没有平台能竞争的过你自己，在这个世界上，只有自己更了解自己。所以我真的感觉它们在做无用功，浪费资源，最好的平台，不是给打各种标签，而是引导每个人发现自己的标签是什么。

这里我想分享给各位几个我思考的点，以供探讨。

原则一：相比与到处去找信息差，更重要的是建立自己的“资源池”

我那时候不停的刷信息，不停的找信息，本质上，我是在幻想着找到一个信息差，从而获利。这也是网上铺天盖地的文章所推崇的，所谓在风口上猪都能飞。但它们总是在掩盖一个逻辑错误，那就是找到信息差和获利之间的因果关系。实际上，找到信息差只是获利的条件之一，你有多大的能力利用这个信息差，这个信息差的时效性，方方面面的因素都会互相交织和影响。

更进一步的想，信息差就像风一样，它存在于冷热空气的交换之时，它存在于各行各业、每时每刻。让我们去追逐风，这现实吗？

我们更应该静下来，好好数数自己手头的东西，整理自己的大脑。找到自己“资源池”有哪些资源，哪些可以为我们所用，哪些可以继续扩充。思路可以打开一点，任何在当前时刻属于你的东西，都是你“资源池”的一部分。

原则二：出卖自己时间和体力的不做

这个不做，不是指不去做，而是指不长期的做。一般入门一个行业或者技术，肯定要付出时间和体力的。但你要说十年如一日的付出相同的东西，那所谓“35 岁”危机就只能找到你了。这点其实各行各业都一样，只是互联网行业处在发声的前沿罢了。

包括所谓网赚、搬运都是一个道理，毫无技术含量的事做几年就好。要时常审视自己现在在干什么，手头有哪些资源，未来的目标是什么。这跟程序运行是一个道理，运行了一段时间，停下来让自己 GC 一下。不然很容易 StackOverflow。

原则三：自己抓住的资源，千万不要轻易放手

如果不经常审视自己的“资源池”，给所有资源估估价值，就很容易被人带坑里。

原先我就做过一个项目，这是个跨部门项目，我那个领导一直告诉我说这个项目没前途、没卵用，绩效也给我打的不好，问我还要不要继续做。我说那就算了吧，做的我都不想做了。

我一放弃，马上就有新人接手，连交接也不用做，代码直接拿走，吃相可见一斑。

也就是从这里我才理解到，我其实没有了解自己，没了解过我手里的项目，被人潜移默化的影响了。影响一个人的思想真的不难，不停的重复就好了。所以还是那句话，多把自己手里的“资源池”拿出来晒一晒，整理一下。

其实 996 也是一样，拿出了你最重要的资源---身体，到底换来了什么，值得好好评估一下。

原则四：做自己喜欢的赛道，更要积累自己的资源

这几个月的经历给我的最大感觉是，这世界上真的有太多太多的行业，也有很多人赚到了钱（至少网络上宣传他们赚了钱）。网络能让这些信息病毒式的传播，导致很多人错觉的以为自己照着做也能挣到钱。但他们忽视的是，网络能把世界各地的人汇聚起来，让信息流通。其实也提供了一个更大的平台，在这个平台里，只有更卷的人才能挣到钱。

有时候真的应该抛开网络。比如，你会写代码，这是你“资源池”里的一项技能，你把这个技能公开到网络售卖。只有两种情况，要么你非常的卷，打拼出一番事业；要么你根本竞争不过别人，这是普遍情况，这世界那么大，比你优秀的人有太多太多了。

但是抛开网络，回到你身边的小小社交圈子，你的技能可能就没那么普遍了。可能你会说，那我做程序员，我身边朋友认识的大部分也是做程序员啊。那么可以这么想，假如你会做菜，你身边的程序员朋友都会做菜吗？假如你会画画，你身边的程序员朋友都会画画吗？人和人总有差异点，你觉得找不到优势，那是因为你尚未建立自己的“资源库”。

先认识自己，再让身边的人认识自己，当他们会给你打标签时，他们就成了你“资源库”中的一员，这就是人脉。这才是是独属于你自己的标签，而不是抖音、B 站为你打的冷冰冷的标签。

总结

以上我感悟的四个原则，我称之为“资源池思维”，一个比较程序员化的名词。

这篇文章发完后，我后续可能就继续更新一下具体的技术文章了，继续深耕技术。

最后，推荐看到最后的各位看一部冷门电影：《神迹》，讲述的是医生维维安托马斯的故事。看完可以来一起交流交流感悟。

辞职

我辞职了

拿上水杯，挎起背包，工位被我丢在了身后，一阵清风过后，我便离开了这度过一年半载的地方

辞职的原因很简单，公司快没钱了，要么同公司共进退，要么离开，于是我选择了离开

公司的待遇不算好也不算差，工资不算满意，但至少双休不加班。平时开发阶段末尾还比较闲，大把摸鱼时间，逛逛各种论坛，掘金、知乎、github不亦乐乎，现在看来公司倒闭和我不无关系

久而久之，不免有些无聊。论坛里充斥着灌水文章，看多了属实是食之无味。于是为了打发时间，只能写一写自己的项目。一想到老板在为我打工，敲打键盘的双手便愈发轻盈了

未曾设想的道路

大半年前为了记录学习一项技能到底要花多少时间，我开了个新坑，做一款计时软件，记录某个时间段发生的事情

和以往一样，最初只是打算随便写写，写个基础功能完事。但在使用的过程中，越来越多的需求在脑海中构建。编程最有趣的便是创造感，你能感受到自己在创建一个新的世界，在创造的过程中时间飞速流逝，一转眼便度过了无聊的一天

激情是短暂的，生活是漫长的。和往常一样，功能在逐步完成，但我的兴趣在逐渐减少。没有添加柴薪，火便只能渐渐势弱

此时两个选择摆在面前，一个便是不再更新下去，毕竟要做的已经完成了，再去寻找下一个打发时间的事情就好了。另一个则是保持兴趣继续做下去

兴趣？利益？

做一个开源软件，如果能收获社区的掌声想必是件自豪的事情。但如果只有掌声，久而久之开源作者可能会陷入自己到底为了什么才做这件事的思维泥潭。有的人失去了兴趣便离开了，有的人发出了声音希望得到一些回馈

兴趣可以支撑人前行，但又有多少人能不求回报去做一件事？不可否认，曾经幻想过做出爆红的软件，然后不用打工，财富自由这样的白日梦。虽然不能一步登天，但我想借助它向前一步

审视一下目前的状况，如果要供用户使用，一个简单的计时功能加上记录，未免太过单薄。这么简单的功能实在谈不上什么竞争力，实现成本过低，而且我相信人们更愿意使用移动app，而不是在pc上去使用这个功能。我需要一个特定于pc且有实在价值的功能，很快我便找到了，它既满足前面的要求，又契合软件的主题

广告恐怕是最理想的获利方式，不会影响用户使用，也不用去考虑升级版之类的的东西。虽然不知道具体能有多少收入，但希望起码能够抵消掉域名的费用

有了继续前进的目标，这艘小船便能扬帆远航

但眼下的问题很严重，我在技术选型上摔了个大跟头

重头再来

好的开始是成功的一半，但没有人能预料到未来会发生什么

使用vue3为前端，我直接选择了webview方向的跨端框架

在以go为后端的wails和rust为后端tauri中，我选择了go。之前学习过一段时间的rust，深知学习的难度。而且在最初的预想中，我只是打算做个简单的计时软件，使用go也只是做一下数据库操作。不久后就完成了最初的一版，但在后续的尝试中，发现wails的生态还是太小了，很多基础的功能都需要自己实现。这时再看看tauri就显得很香了，各种插件和前端的绑定，再加上go并没有用得多么称手，于是只能长痛不如短痛了

ui框架的选择上我也犯了同样的问题。开始是偏向于material design这种风格，选择了vuetify，这个框架当时我看了很久，做的时候已经要到v3正式版本了。本来以为没问题，但后续使用时过于难受，此时文档基本没怎么更新，issue也被各种bug塞满了。只能快刀斩乱麻，换了习惯的ant-design-vue，风格区别很大，但改改样式也能用。quasar同样在我的考虑范围内，但更加小众，目前是不打算换了，在tauri v2移动端正式版后，再做尝试

为什么最开始没有选择做移动端？功能契合，使用起来也更方便。一方面是我的主要技能栈是js，另一方面重新学移动端过于不切实际，为一个八字没一撇的项目去学实在没有必要。flutter我之前也学过，试着写了一点，但还是不如js来得舒服

回过头来，发现走了很多弯路，但不去尝试只站在远处观望，永远也不会有结果。颠颠撞撞重头再来

编程之外

我一直把时间花在了代码之上，但想要做一款产品还远远不够，它迫使我不得不将视角转向那些我不曾关注的角落

UI可谓是产品的脸面，用户的第一印象便停留在了logo和界面上，虽然使用了风格统一的组件库，但将他们组合在一起的时候未必能将它们严丝合缝。目前只能说是勉强能看，日后再做修改

说明文档带领用户快速理解程序的运作，由于用户没有设计者的前提条件，很多理所当然也就需要一一记录

想要完善功能，bug和feature的反馈也要做指引，方便接收用户意见，确定前进路线

说明文档

参考vite的官网，使用vitepress，写markdown就可以了，还可以配上vue组件，还算方便

部署上选择了netlify，可以换自己的域名，还可以自动更新ssl证书

本来以为部署很麻烦的，结果一个小时左右就全部搞定，包括在namesilo上买域名，然后在netlify部署、配置

拥抱AI

在完成这些工作的过程中，有不少地方借助了AI，可以说很大程度加快了进程

编码上，由于我完全不懂windows编程和勉强会点rust语法，想要完成监听系统上的应用状态这项功能，根本就无从谈起。要花大量时间去学习的话，反而和我利用碎片时间进行编程相冲突了。况且在new bing的帮助下，我完成一个简单的函数就要花费数个小时的尝试。new bing根据我的需求返回了相关的api参考，但很多时候返回的代码并不能直接运行，有着这样那样的问题，需要去修正。很难想象仅凭我一人去翻找资料何时才能完成这冰山一角

在这个过程中，new bing最大的帮助就是提供了关键词。很多时候，你知道一个事物，想用自己的语言需要一长串词语去描述，但过去的搜索引擎并不能理解这些，而且就算把描述输入进去，也会因为过多的关键字导致答案被淹没在茫茫的网页之中。这就造成了一个困境，我不知道它叫什么，所以我要去搜索，但搜索的时候要知道它叫什么

在netlify配置域名，我输入了如何去配置，new bing给出了关键的name servers，省去了花时间去到处去找教程

为应用绘制一个logo，很显然我并没有这个能力，使用Bing Image Creator，一段描述就能生成

这些都是一些无关紧要，琐碎的事情，我只想获取结果，把精力留在我擅长的事情上。试想一下，我一个人去实现要花掉多少时间？最终能实现吗？部分功能交给其他人，又要用什么去换取？

计划

讲到这里如果有兴趣了解一下的话，可以移步仓库地址，但目前的功能我只能说很少，而且还可能出现问题，我提前声明一下。说明文档见此处，需要看清警告提示

为什么这个时候来写这篇文章来介绍呢，主要是辞职了也没事干，已经做了大半年就整理了一下。原本是半年后再辞职的，但计划赶不上变化，只能提前放出来看看情况

还有一项没能赶上的便是广告，使用的是google adsense，但提交申请后便石沉大海。尽管提前做了申请，但已经过去了几个星期。可能是开始建站时随意申请被驳回的缘故，久久没有反应

最后

辞职其实还有一个原因，就是累了，光是待在公司什么都不干，也能感觉到劳累。工作小憩之余，在过道眺望远方时，我一直想问自己究竟在干些什么。我想做出改变，想去尝试新的东西，体验另外一种生活

想过很多次，以后也许不会从事编程的工作，但又有什么选择呢。我希望是创作，而不是枯燥的重复劳作，但我很清楚这不是换一个职业就能改变的问题，终究是实力的问题。编程很有趣，但在公司并不是如此

现在我已经度过了一周的悠闲时光了，白天在家看看书，傍晚下楼走走，看着面向我驶过的匆忙下班的人流，感叹这也是自己前不久的模样。我背朝着喧闹，走上凉爽的林荫道，晚风吹过，天边挂着一轮淡淡的月牙

一眨眼工作已经三年了，前两年的总结 工作第一年、工作第二年 基本上把在公司做的事情都介绍了，今年站在「前端已死」、互联网大裁员的环境下，想想未来的路可能更为应景。

经常说这是最好的时代，也是最坏的时代，互联网便是如此。通过互联网将人与人之间的各种链接都成为了可能，在互联网诞生之前，人与人之间的交流就是现实生活中的圈子，而现在本来这一辈子都不会在现实中产生交集的人在互联网却会相遇。

各种写书的大佬、开源的大佬，以往可能只是从文字、代码中了解他们，但现在通过社交媒体、微信竟然就产生了互动。当然不好一面就是也会遇到和自己不相投的人，也许会影响自己的心情。

通过互联网极大的扩宽了我们的视野，看到了别人在怎么生活，也放大了自己的焦虑和欲望。我们需要认清自己的边界，知道自己想要什么，自己能做什么，不需要对本来不可能发生在自己身上的事情而焦虑。

当迷茫焦虑时，看看宇宙的纪录片，从宇宙的视角去看自己，无论从空间大小还是时间维度，其实自己什么都不是，想那么多干啥。

再想想其他动物，吃饭睡觉喵喵叫，也挺好的。

前端已死

互联网已经结束了快速扩张的时期，这是个客观事实，因此招聘的人数相对于之前减少了很多，但远没到一个已死的状态，相对于其他行业，选择互联网依旧是一个不错的选择。

前端会不会死不知道，互联网肯定会一直存在下去，现在整个社会都是基于互联网，已经变成了像电、水一样的基础设施，没有人可以离开它。因此互联网的相关的岗位一定会一直一直存在。

至于互联网中具体的职业划分，前端、后端、算法、数据库等，它们各自使用的语言、技术一定会发生变化的，当选择互联网技术行业的时候，就应该抱有持续学习的态度。

塞班操作系统被安卓、iOS 取代、.Net 岗位的减少、客户端大量岗位转前端，这些也就发生在近十几二十年。当某一个岗位减少的时候，一定又会出现新的岗位，保持开放的心态去学就可以，变化再多肯定也有不变的东西。当掌握一门技术再学习另一门技术的时候，肯定会比小白学习一门新技术快很多很多，很多经验也会迁移过去。

去年 12 月出来的 chatGPT 为代表的大模型，到现在也就半年多的时间，很多以前完全不敢想的事情就这样发生了。可以预见的是一部分岗位数量肯定也会减少，目前影响最大的应该是 UI 岗，其次一定程度上可以提高程序员的开发以及学习效率，但还没有到取代的程度，但未来会再怎么发展就不得而知了。

相对于其他行业，虽然互联网相关技术迭代确实很快，但如果是因为热爱而选择这个行业，我觉得去做一辈子是没问题的。

技术

底层技术服务于上层技术，上层技术服务于应用，真正赚钱的是应用，它可能提升了用户的效率、也可能提升了用户的生活体验，这样用户才愿意付费。上层技术的人收到了钱，进一步也愿意为底层技术的人付费。

但对于一个应用，技术并不是最重要的，更多需要的是产品和运营，一个应用在 chatGPT 和各种框架、云服务的加持下做出来变得太简单了，更多的是我们需要思考如何设计产品和如何推广运营产品，和用户产生更亲密的连接，用户才愿意付费。

极端一点，即使现在所有的应用都停止更新了，其实也并不会产生多大的影响。

在公司中亦是如此，对于技术开发，没有谁是不可取代的，公司更期望的是那些可以发现问题、分析问题、定义问题的人，至于怎么解决，问题定义清楚以后，解决方案自然可以出来，谁去解决并不重要了。

但也不用太过悲观，虽然技术不是最重要的，但一定是不可或缺的，在解决问题的过程中也会区分出能力强和能力差的：方案的设定、代码编写的好坏、线上的 bug 数、代码的扩展性等。

赚钱

赚钱很大程度又是需要运气的，比如同一个人十年前进入互联网和现在进入互联网差别就会很大，再比如开发一个应用突然爆火，例如「羊了个羊」，这些我们是很难控制的，我们只能「尽人事，听天命」。

最近几年，除了在公司工作，对于有技术的同学赚钱有下边的方式：

• 付费课程、出书

  最近几年越来越多的人在极客时间、掘金小册写课程或者直接出书。

  对于写课的人赚到了钱，对于买课的人只要跟着看完了，多多少少都会有很多收获。付费课程会比较系统， 如果没有这些课程，去学东西肯定也是可以学的，但需要花很多时间去网上搜一些零碎的资料，由于没有经验甚至可能走很多弯路。

• 付费社群

  市面上也会有一些付费训练的社群或者知识星球

  对于组织付费社群的人会花费很大的精力，需要持续运营并且照顾到每一个人，不然就等着挨骂吧。因此这类收益也会很高，一些人会辞去工作专职来搞。

• 开源

  大部分开源基本上是用爱发电，更多是收获一些朋友、流量、提升技术。

  比如 core-js 作者的经历，一个 22.6k star 的项目，几乎各个网站都在用的一个项目，作者却因为钱的问题被很多人谩骂。因此如果是个人专职开源一个项目靠 GitHub Sponsor 会很难很难。

  当然，开源也是能赚到钱的，比如 Vue 开源就赚到了很多钱，但毕竟是很少很少数了。

  依赖纯开源项目赚到钱，还是需要背靠公司。比如阿里云谦的 Umi、通过开源加入 NuxtLab 的 Anthony Fu、在 AFFiNE 的雪碧等等。

• 应用

  身为一个程序员，尤其是前端程序员，当然可以自己维护一个应用来赚钱。

  做得很成功的比如 Livid 的 V2ex 社区，Abner Lee 的 Typora（后来知道作者竟然是国内开发者）。

  也有一些没有那么出名的，比如大鹏的 mdnice，秋风的 木及简历。

  当然如果要做一个很大的项目，背靠公司也是一个很好的选择，比如之前阿里玉伯的语雀、之前极客邦池建强的极客时间。

  还有一些小的创业公司会做的，冯大辉的「抽奖助手」、吴鲁加的「知识星球」等。

  做出这些应用不需要很多时间，需要我们善于发现生活中的痛点以及强大的执行力，当然想成功的话需要再加一点运气，在成功前需要不断尝试不同的东西。

• 流量变现

  有流量就会赚钱，不管是接广告、还是带货。互联网上也会有部分人专注于怎么搞流量，知乎怎么获得更多曝光、视频号怎么获得更多流量、怎么批量注册号，各个平台规则可能是什么，怎么对抗规则，这类有技术加持也会更加顺利，很多人也在专职做。

赚钱的方式有很多，对于我来说，我会尽量选择复利的事情，这样才能产生更大的价值。比如一对一咨询，一份时间换一份收入。但如果把东西写成课程，只需要花一份的时间就能获得 N 份的收入。

另外就是需要保持分享，分享除了能帮助其他人，对自己也会有很大的帮助，写文章的过程中也会不断的有新的认知得到。虽然当下可能没有金钱方面的收入，但时间放宽到几十年，相信一定会有很大的回报。

人的欲望是无穷的，也不能陷入赚钱的极端，目标应该是关注此刻，体验生活，享受生活，而不是不停的赚钱。之前听播客，有一个恰当的比喻，钱就好比汽油，不停的赚钱相当于不停的加油，但如果汽车停着一直不动，再多的汽油也是无意义的。

健康

最近几年总是爆出程序员突然离世的新闻，前段时间耗子叔突然离世的消息听到之后真的很震惊。twitter 经常刷到耗子叔的动态，然后突然一天竟然就戛然而止了，毫无征兆。

意外是无法避免的，只能尽可能的从饮食、作息、锻炼三方面降低生病的风险。

饮食

我是工作第一年体检的时候检查出了中度脂肪肝、尿酸高，当时因为是刚毕业，体重是我的巅峰，140 多斤，脂肪都堆在了肚子上。那段时间就开始跑步加吃沙拉，少吃米饭、面条。降的也快，几个月就回到了 130 斤以下，甚至到 120 多点。

第二年体检的时候，脂肪肝基本没有了，尿酸也降了许多。

后来就保持少吃米饭，多吃蛋白质、蔬菜的饮食了。

作息

有一次得了带状疱疹，那种非常痛的类似于痘痘的东西，后来了解了一下是因为免疫力低导致病毒入侵的。猜测因为晚上坐在电脑前，气温降低了没注意，从而导致了生病。

病好之后就决心养成早睡早起的习惯。

之前作息基本上是 1 点到 2 点睡觉，9 点前后起床。现在基本上保持在 11 点前后睡觉，6 点到 7 点间起床了。

早起的好处就是早上会有大把的时间，而且这段时间是专属于自己的，并且因为大脑刚苏醒，效率也会很高。但如果是工作一天，晚上回家再做自己的事情，此时大脑已经很疲惫了，效率会比较低。

运动

最开始是跑步，但确实很难坚持下去，跑步需要换衣服、出门，还依赖于外边的天气，成本很高。后来陆续尝试过 keep、一些付费课程，都做了但没有完全养成习惯。

后来知道了 switch 的健身环大冒险，然后就一路坚持到了现在，前段时间已经通关了。

目前也一直在坚持，基本上一周会运动三到四次，一次大概花费 50 分钟左右。

投资

大学的时候开始接触到理财，知道了基金的概念，看了银行螺丝钉的「指数基金定投指南」，也看了「穷爸爸富爸爸」、「小狗钱钱」这类理财入门的书。当时赚到的一些钱，就跟着银行螺丝钉投了，主要是一些宽基和中概、医疗。

一直到工作的第一年，基金收入确实不错，甚至赚了百分之四五十。当时想着原来股市这么简单，这咋还能亏钱了。

接着疫情不断发展，还有外部经济的变化，中概、医疗都大跌，当时发了年终奖还不停的补仓中概，到现在亏损也有百分之三四十了。

但我心态是可以的，一切都是浮亏和浮盈，只要不卖一切都是浮云。

经历了大起大落后吸取了一些教训，那就是一定要严格执行计划，现金流多不一定要立刻全部投入，而是按计划定投，因为没人知道会跌多久，只有有充足的现金流，才能够把亏损逐步拉平。

现在国家规定互联网基金这些必须走「投顾」，也就是主理人帮我们买入、卖出，我们只需要交一定的投顾费即可。目前我都是在雪球上投，跟投的有孟岩的「长钱账户」、alex 的「全球精选」、螺丝钉的指数增强和主动优选。

能设置自动跟投的就自动跟投了，我相信专业的事交给专业的人肯定是没问题的。

投资肯定是财富自由不了的，但一定比把钱放余额宝强一些，只要耐心持有，尤其是目前这样的熊市投入，相信到下一个牛市会有不错的回报。

（以上仅个人看法，股市有风险，入市需谨慎）

保险

如果开始接触理财，除了投资，一个绕不过去的点就是保险。

对于保险是什么的比喻，之前听薛兆丰的课时候印象深刻。

我现在还年轻力壮，将来年纪大了可能会生病，为了防止以后生病要花一大笔医药费，今天就开始存钱，每个月拿出 10% 的收入存起来，未雨绸缪。这是一种做法。

另外一种做法，是我每个月也拿出 10% 的收入去买保险。

这两种做法有什么区别呢？

区别在于，如果我是用储蓄来未雨绸缪，那么未来可能就会发生两种不同的情形。

如果我将来年纪大了也没生病，我存的钱就还是我的钱，我不需要花出去，这时候我还是很幸运的，能够保有我原来的收入，这份储蓄没有被花掉，我赚了。

但是如果我运气不好，生病了，这份储蓄就会被用掉，甚至需要借很多钱去治病，生活会发生巨大的变化。

所以通过储蓄来未雨绸缪，它的特点是未来的结局是可变的，是变动的、是带有风险的。要么高、要么低，要么能够保有原来的这份储蓄，要么这份储蓄就被用掉了甚至借更多的钱。

而对于保险来说，如果你没病，那你的生活该怎么样还是怎么样。如果你病了，那会有保险公司给你支付一大笔钱，你也不用和别人借钱，病好后继续该干啥干啥。

因此存钱去防止生病就有赌的成分了，如果没病就白赚了很多钱，如果病了生活质量可能会发生很大的变化。

而保险就可以降低风险，未来即使生病了，由于看病不需要花钱了，病好后生活质量也尽可能的维持在原来轨道 。

我期望未来肯定是尽量稳定的，所以在不影响当前生活质量的条件下我愿意拿出一部分钱来买保险。原计划我可能会 30 岁以后开始买重疾险，之前女朋友的朋友有推荐保险的，然后就跟女朋友一起配置了重疾险。

选保险一定要慎重，一些看起来很划算的保险， 到理赔的时候可能会推三阻四，甚至理赔前公司破产了，尽量要选择大公司。

总

当然生活没有标准答案，每个人看到世界也都是不同的，我也一直在成长，一直在认识新的东西，上边的所想的也不能保证说未来不会再变。

未来能做的就是多看看书，不限制自己，看看经济学的、哲学的、心理学的、人文的，多出去走走看看，尽可能多的增加人生体验，去认识世界，认识自己，做自己想做的事，爱自己所爱的人，走下去就好了。

掘友的一个评论，让我又想跟大家唠会儿嗑了。

我之前写过一篇文章叫《该写好代码吗？我也迷茫了》。于是，这位掘友评论说，他在上家公司的时候，他们组代码质量要求高，前期设计考虑全面，所以上线后问题少。但是在领导眼里就像没事做一样。其他组经常出事故，反而很忙，像是一直在攻克难题。

我回复说：那可能是领导不够专业，没有深入到项目里。

回复完了，我仍然意犹未尽。于是，才有了这篇文章。

正常情况下，对于一个软件项目或者一次版本迭代，负责人应该是心中有数的。这个项目的难度如何？手里的人员能力如何？大约做多长时间？最终会达到什么效果？这些应该是负责人的基本功。我不自夸，反正我带项目时，我们几个负责人都是能做到的。

据此，你才能更好地把握一个项目的始终。有时，项目中间出现难题，要干预。有时，大家超额完成，要嘉奖。有时，很简单的功能，他开发出了很多bug，要扣奖金。甚至有时候，一个月的工期，老板硬要半个月完成，这时对结果不能要求太高，你不能又要做完又要做好，那是找打的节奏，最终会两败俱伤。

但是，存在一种叫“外行管理内行”的情况。这类领导呢，他不知道你干了啥，也不知道对你来说这活好不好干，甚至你干没干完他也分辨不出，全靠读你的周报和计划。但他却是你的分管领导。

我原本以为，在技术领域不会存在这类情况。后来发现，不但有，居然还很普遍。而且在国内，这还是一道别致的景观。

听过一个报道，说国内有一位教授，他从国外买来高端芯片，先把标志磨掉，再印上自己的Logo。然后，他对外宣传是自主研发的。出人意料的是，他还开发布会，还拿到了上亿的科研资金。随后几年，他甚至还推出了第二代、第三代、第四代，都是通过自己印标签的手段完成的。

整个过程，但凡有内行审一下图纸，看一下生产车间，都会很容易识破骗局。

当然，咱们普通人一般到不了研究芯片，那么高精尖的层次。但是，我觉得作为一个普通企业的小领导，参与到项目中，这总是可以的吧。

从实际情况来看，其实很少有领导能躬身入局。哪怕这个领导只管六、七个人，他也会再分成三四个组。遇到一项任务，领导会安排给员工，让它们去协商完成。而他，要去规划团队未来的发展。

我有种很明显的感觉，但现在还找不到一个合适的名词来描述它。只能从一些例子上去体会其中的差异。

我有一个任领导，开周会是他做总结。他说这一周，后端完成了什么，前端没有完成什么。前端还反驳他，说自己完成了。领导说，别糊弄我，你只是把接口地址敲上了，根本没调用过，你跑跑试试，数据结构对不上。他是最了解整个项目开发进度的人。

还有些领导与他形成鲜明的对比。他们了解事情靠开会听汇报，就算只有三个下属，也要他们说说这周干了啥。他做一下汇总，然后再上报给他的领导。功能交付后，项目出现了问题，他会说是下属欺骗他，居然谎报工期，没测说测了，没做说做了。

至于形成这种区别的原因，可能跟文化和制度有关。不能说哪种绝对好或者不好。

前面那种“严管型”领导所在的公司，企业文化中，负责人制，不讲理由。出了问题不要推脱是张三、李四没做好，他们担不起这个责任，就是你负责人的问题。所以，这才导致了领导会落实每一项流程。

后者那类“汇报型”的企业，从上到下都注重文书的格式、措辞，讲究高瞻远瞩，着眼未来，允许试错，探索创新。因此，他们便将更多的精力投入到了汇报上。

作为一名老程序员，我感觉，软件开发是一种很工程化的工作，一层层拆分好，安排到基层人员手里，告诉他们如何执行就可以了。但是新一代领导说，管理的最高境界是让团队具备自驱力，硅谷就是这样的。自驱力就是你不用安排，他们自己就能主动克服困难去完成。即便领导不在，团队也能照常运转，这才是健康的团队。

抱歉，有点儿跑题了。

本文的初衷是“外行管理内行”与“躬身入局”。

我觉得“外行管理内行”在国内是必然现象，尤其在技术领域。

在国内的中小企业，作为团队的领导，“行政类”的事情要比“专业类”多。你看看你的领导，他经常开会和写材料。这不是它自己要干的，也不是老板要求的，是受行业和环境的影响。你想要申报科技企业，申请政策扶持，参加高新评级，你就得去准备。

除此之外，团队的日常管理，年计划、月计划，人员流动、评优、优化等等，都会耗费日常的精力。而这些活，专业的程序员并不想干。

另外，就算一个内行被推上管理岗位，程序员工种复杂，知识更新也快，那他干上几年，也会慢慢被磨成“外行”。

因此，内行外行只是相对的，并不重要。我则更强调“躬身入局”。

躬身入局，就是参与到项目中。就算不写代码，起码也了解下大家遇到的问题。在这个过程中，作为管理者，可以制定一些规则和标准，来保证良性运作。好的流程制度，是可以实现员工自驱动的。

举一个身边的例子。现在夏天了，天气很热，办公室都会开一天的空调，温度调到23度。

这天下过大暴雨，空气清爽，气温很低。这时，23度的空调就很冷了。正对着空调口的瘦同事，就想去关掉空调。结果被一个静止都会喘粗气的大胖子给制止了。

胖子问：为啥关空调？

瘦子说：外面下雨，不热了！我冷。

胖子说：你冷你穿衣服。你关了我热。

瘦子说：你热，你打开小风扇。

说完，瘦子关了空调。 随后，胖子又打开了空调。

这类事情就是公说公有理，婆说婆有理。搞不好还需要领导出面调停，或者搞一个群体性的投票。如果没人理你，那就看谁的底线更低，或者说谁更狠。

但是，如果说团队制定这么一个小规则，就是室温超过26度可以开空调制冷，制冷底线是23度。那么，即便没有领导在场，大家也能很好处理此类事情。甚至，这类情况根本都不会发生。

这只是为了体现规则重要性的例子。到软件开发中，可能就是比如这类情形：一个接口如果多个端都调用，那么就由后端组织特定的数据格式。

如果你躬身入局，你就会经历类似的事情。否则的话，你可能会说，吵什么吵，大家要以大局为重（只是要求停止争吵，没有决定开不开空调）。

可能说这么多，有人朝我笑了：你以为我傻？我这么做，老板给我涨工资，多拿钱！

抱歉，抱歉！我只想着如何提高项目质量了。关于挣钱方面，我外行了！

唉，大家一定要重视环境的重要性。

大家好，我是老三，最近沉迷于听脱口秀，并且疯狂安利同事。

脱口秀演员常常说的一句话是：“脱口秀是冒犯的艺术”。最近我发现，同事们好像有点不一样了。

阳光灿烂的早上，趿拉着我的宝马拖鞋，跨上包浆的小黄车，屁股感受着阳光积累的炙热，往公司飞驰而去。

一步跨进电梯间，我擦汗的动作凝固住了，挂上了矜持的微笑：“老板，早上好。”

老板：“早，你还在呢？又来带薪划水了？”

我：“嗨，我这再努力，最后不也就让你给我们多换几个嫂子嘛。”

老板：“没有哈哈，我开玩笑。”

我：“我也是，哈哈哈。”

今天的电梯似乎比往常慢了很多。

我：“老板最近在忙什么？”

老板：“昨天参加了一个峰会，马xx知道吧？他就坐我前边。”

我：“卧槽，真能装。没有，哈哈。”

老板：“哈哈哈”。

电梯到了，我俩都步履匆匆地进了公司。

小组内每天早上都有一个晨会，汇报工作进度和计划。

开了一会，转着椅子，划着朋友圈的我停了下来——到我了。

我：“昨天主要……今天计划……”

Leader：“你这不能说没有一点产出，也可以说一点产出都没有。其实，我对你是有一些失望的，原本今年绩效考评给你一个……”

我：“影响你合周报了是吗？不是哈哈。”

Leader、小组同事：“哈哈哈“。

Leader：“好了，我们这次顺便来对齐一下双月OKR，你们OKR都写的太保守了，一看就是能完成的，往大里吹啊。开玩笑哈哈。”。

我：”我以前就耕一亩田，现在把整个河北平原都给犁了。不是，哈哈。”

同事：“我要带公司打上月球，把你踢下来，我来当话事人。唉，哈哈”

Leader、同事、我：“哈哈哈“。

晨会开完，开始工作，产品经理拉我和和前端对需求。

产品经理：“你们程序员懂Java语言、Python语言、Go语言，就是不懂汉语言，真不想跟你们对需求。开个玩笑，哈哈。”

我：“没啥，你吹牛皮像狼，催进度像狗，做需求像羊，就这需求文档，还没擦屁股纸字多，没啥好对的。不是哈哈。”

产品经理、前端、我：“哈哈哈”。

产品经理：“那我们就对到这了，你们接着聊技术实现。”

前端：“没啥好聊的，后端大哥看着写吧，反正你们那破接口，套的比裹脚布还厚，没事还老出BUG。没有哈哈。”

我：“还不是为了兼容你们，一点动脑子的逻辑都不写，天天切图当然不出错。不是哈哈。”

前端、我：“哈哈哈”。

经过一番拉扯之后，我终于开始写代码了。

看到一段代码，我皱起了眉头，同事写的，我顺手写下了这样一段注释：

/**

* 写这段代码的人，建议在脑袋开个口，把水倒掉。不是哈哈，开个玩笑。

**/

代码写完了，准备上线，找同事给我Review，同事看了一会，给出了评论。

又在背着我们偷偷写烂代码了，建议改行。没有哈哈。

同事、我：“哈哈哈”。

终于下班了，路过门口，HR小姐姐还在加班。

我：“小姐姐怎么还没下班？别装了，老板都走了。开玩笑哈哈。”

HR小姐姐：“这不是看看怎么优化你们嘛，任务比较重。不是，哈哈。”

HR小姐姐、我：“哈哈哈”。

我感觉到一种不一样的氛围在公司慢慢弥散开来，我不知道怎么形容，但我想到了一句话——

“既分高下，也决生死”。

写这篇的时候，想到两年前，有个叫码农小说家的作者横空出世，写了一些生动活泼、灵气十足的段子，我也跟风写了两篇，这就是“荒腔走板”系列的来源。

后来，他结婚了。

看（抄）不到的我只能自己想，想破头也写不不来像样的段子，这个系列就不了了之，今天又偶尔来了灵感，写下一篇，也顺带缅怀一下光哥带来的快乐。

什么是密封接口？

密封接口（sealed interface）是kotlin 1.5引入的一个新特性，它可以让我们定义一个限制性的类层次结构，也就是说，我们可以在编译时就知道一个密封接口有哪些可能的子类型。这样，我们就可以更好地控制继承关系，避免出现意外的子类型。

密封接口与密封类（sealed class）类似，都可以用来表示一组有限的可能性。但是，密封类只能有一个实例，而密封接口的子类型可以有多个实例。此外，密封类只能被类继承，而密封接口可以被类和枚举类（enum class）实现。

要声明一个密封接口，我们需要在interface关键字前加上sealed修饰符：

sealed interface Error // 密封接口

一个密封接口可以有抽象或默认实现的方法，也可以有属性：

sealed interface Shape { // 密封接口

    val area: Double // 属性

    fun draw() // 抽象方法

    fun printArea() { // 默认实现方法

        println("The area is $area")

    }

}

密封接口的优点

使用密封接口有以下几个优点：

• 类型安全：由于密封接口的子类型是固定的，我们可以在编译时就检查是否覆盖了所有可能的情况。这样，我们就不会遗漏某些分支或者处理错误的类型。
• 可读性：使用密封接口可以让我们清楚地看到一个类型有哪些变种。这样，我们就可以更容易地理解和维护代码。
• 灵活性：使用密封接口可以让我们定义更多样化的子类型。我们可以使用数据类（data class），对象（object），普通类（class），或者另一个密封类（sealed class）作为子类型。我们还可以在不同的文件或模块中定义子类型。
• 表达力：使用密封接口可以让我们利用多态（polymorphism）和继承（inheritance）来实现更复杂和优雅的设计模式。

密封接口在设计模式中的应用

设计模式是一些经过验证和总结的解决特定问题的代码结构和技巧。使用设计模式可以让我们编写出更高效，更可复用，更易扩展的代码。

下面，我们将介绍几种常见的设计模式，并展示如何使用密封接口来实现它们。

策略模式

策略模式（Strategy Pattern）是一种行为型设计模式，它可以让我们在运行时根据不同的情况选择不同的算法或策略。这样，我们就可以将算法的定义和使用分离，提高代码的灵活性和可维护性。

要实现策略模式，我们可以使用密封接口来定义一个策略的抽象，然后使用不同的子类型来实现具体的策略。例如，我们可以定义一个排序策略的密封接口，然后使用不同的排序算法作为子类型：

sealed interface SortStrategy { // 密封接口

    fun sort(list: List<Int>): List<Int> // 抽象方法

}



object BubbleSort : SortStrategy { // 对象

    override fun sort(list: List<Int>): List<Int> {

        // 实现冒泡排序

    }

}



object QuickSort : SortStrategy { // 对象

    override fun sort(list: List<Int>): List<Int> {

        // 实现快速排序

    }

}



object MergeSort : SortStrategy { // 对象

    override fun sort(list: List<Int>): List<Int> {

        // 实现归并排序

    }

}

然后，我们可以定义一个上下文类（Context Class），它可以持有一个策略的引用，并根据需要切换不同的策略：

class Sorter(var strategy: SortStrategy) { // 上下文类

    fun sort(list: List<Int>): List<Int> {

        return strategy.sort(list) // 调用策略的方法

    }

}

最后，我们可以在客户端代码中使用上下文类来执行不同的策略：

fun main() {

    val list = listOf(5, 3, 7, 1, 9)

    val sorter = Sorter(BubbleSort) // 创建上下文类，并指定初始策略

    println(sorter.sort(list)) // 使用冒泡排序

    sorter.strategy = QuickSort // 切换策略

    println(sorter.sort(list)) // 使用快速排序

    sorter.strategy = MergeSort // 切换策略

    println(sorter.sort(list)) // 使用归并排序

}

使用密封接口实现策略模式的优点是：

• 我们可以在编译时就知道有哪些可用的策略，避免出现无效或未知的策略。
• 我们可以使用数据类，对象，普通类或密封类作为子类型，根据不同的策略需要定义不同的属性和方法。
• 我们可以在不同的文件或模块中定义子类型，提高代码的模块化和可读性。

如果使用java实现策略模式，我们可能需要定义一个接口来表示策略，然后使用不同的类来实现接口：

interface SortStrategy { // 接口

    List<Integer> sort(List<Integer> list); // 抽象方法

}



class BubbleSort implements SortStrategy { // 类

    @Override

    public List<Integer> sort(List<Integer> list) {

        // 实现冒泡排序

    }

}



class QuickSort implements SortStrategy { // 类

    @Override

    public List<Integer> sort(List<Integer> list) {

        // 实现快速排序

    }

}



class MergeSort implements SortStrategy { // 类

    @Override

    public List<Integer> sort(List<Integer> list) {

        // 实现归并排序

    }

}

然后，我们也需要定义一个上下文类来持有和切换策略：

class Sorter { // 上下文类

    private SortStrategy strategy; // 策略引用



    public Sorter(SortStrategy strategy) { // 构造函数

        this.strategy = strategy;

    }



    public void setStrategy(SortStrategy strategy) { // 设置策略方法

        this.strategy = strategy;

    }



    public List<Integer> sort(List<Integer> list) {

        return strategy.sort(list); // 调用策略的方法

    }

}

最后，我们也可以在客户端代码中使用上下文类来执行不同的策略：

public static void main(String[] args) {

    List<Integer> list = Arrays.asList(5, 3, 7, 1, 9);

    Sorter sorter = new Sorter(new BubbleSort()); // 创建上下文类，并指定初始策略

    System.out.println(sorter.sort(list)); // 使用冒泡排序

    sorter.setStrategy(new QuickSort()); // 切换策略

    System.out.println(sorter.sort(list)); // 使用快速排序

    sorter.setStrategy(new MergeSort()); // 切换策略

    System.out.println(sorter.sort(list)); // 使用归并排序

}

使用java实现策略模式的缺点是：

• 我们不能在编译时就知道有哪些可用的策略，因为任何类都可以实现接口。
• 我们只能使用类作为子类型，不能使用数据类或对象。
• 我们必须在同一个包中定义子类型，不能在不同的文件或模块中。

访问者模式

访问者模式（Visitor Pattern）是一种行为型设计模式，它可以让我们在不修改原有类结构的情况下，为类添加新的操作或功能。这样，我们就可以将数据结构和操作分离，提高代码的扩展性和复用性。

要实现访问者模式，我们可以使用密封接口来定义一个元素（Element）的抽象，然后使用不同的子类型来实现具体的元素。例如，我们可以定义一个表达式（Expression）的密封接口，然后使用不同的子类型来表示不同的表达式：

sealed interface Expression { // 密封接口

    fun accept(visitor: Visitor): Any // 抽象方法，接受访问者

}



data class Number(val value: Int) : Expression { // 数据类

    override fun accept(visitor: Visitor): Any {

        return visitor.visitNumber(this) // 调用访问者的方法

    }

}



data class Sum(val left: Expression, val right: Expression) : Expression { // 数据类

    override fun accept(visitor: Visitor): Any {

        return visitor.visitSum(this) // 调用访问者的方法

    }

}



data class Product(val left: Expression, val right: Expression) : Expression { // 数据类

    override fun accept(visitor: Visitor): Any {

        return visitor.visitProduct(this) // 调用访问者的方法

    }

}

然后，我们可以定义一个访问者（Visitor）的接口，它可以为每种元素提供一个访问方法：

interface Visitor { // 访问者接口

    fun visitNumber(number: Number): Any // 访问数字表达式

    fun visitSum(sum: Sum): Any // 访问加法表达式

    fun visitProduct(product: Product): Any // 访问乘法表达式

}

最后，我们可以定义不同的访问者实现类，它们可以为元素提供不同的操作或功能。例如，我们可以定义一个求值（Evaluate）访问者，它可以计算表达式的值：

class Evaluate : Visitor { // 求值访问者

    override fun visitNumber(number: Number): Any {

        return number.value // 返回数字本身

    }



    override fun visitSum(sum: Sum): Any {

        return (sum.left.accept(this) as Int) + (sum.right.accept(this) as Int) // 返回左右子表达式之和

    }



    override fun visitProduct(product: Product): Any {

        return (product.left.accept(this) as Int) * (product.right.accept(this) as Int) // 返回左右子表达式之积

    }

}

我们还可以定义一个打印（Print）访问者，它可以打印表达式的字符串表示：

class Print : Visitor { // 打印访问者

    override fun visitNumber(number: Number): Any {

        return number.value.toString() // 返回数字的字符串

    }



    override fun visitSum(sum: Sum): Any {

        return "(${sum.left.accept(this)}) + (${sum.right.accept(this)})" // 返回加法的字符串

    }



    override fun visitProduct(product: Product): Any {

        return "(${product.left.accept(this)}) * (${product.right.accept(this)})" // 返回乘法的字符串

    }

}

使用密封接口实现访问者模式的优点是：

• 我们可以在编译时就知道有哪些可用的元素，避免出现无效或未知的元素。
• 我们可以使用数据类，对象，普通类或密封类作为子类型，根据不同的元素需要定义不同的属性和方法。
• 我们可以在不同的文件或模块中定义子类型，提高代码的模块化和可读性。
• 我们可以在不修改元素类的情况下，为它们添加新的访问者和操作。

如果使用java实现访问者模式，我们可能需要定义一个抽象类来表示元素，然后使用不同的子类来继承元素：

abstract class Expression { // 抽象类

    public abstract Object accept(Visitor visitor); // 抽象方法，接受访问者

}



class Number extends Expression { // 子类

    private int value; // 属性



    public Number(int value) { // 构造函数

        this.value = value;

    }



    public int getValue() { // 获取属性值方法

        return value;

    }



    @Override

    public Object accept(Visitor visitor) {

        return visitor.visitNumber(this); // 调用访问者的方法

    }

}



class Sum extends Expression { // 子类

    private Expression left; // 属性

    private Expression right; // 属性



    public Sum(Expression left, Expression right) { // 构造函数

        this.left = left;

        this.right = right;

    }



    public Expression getLeft() { // 获取属性值方法

        return left;

    }



    public Expression getRight() { // 获取属性值方法

        return right;

    }



    @Override

    public Object accept(Visitor visitor) {

        return visitor.visitSum(this); // 调用访问者的方法

    }

}



class Product extends Expression { // 子类

    private Expression left; // 属性

    private Expression right; // 属性



    public Product(Expression left, Expression right) { // 构造函数

        this.left = left;

        this.right = right;

    }



    public Expression getLeft() { // 获取属性值方法

        return left;

    }



    public Expression getRight() { // 获取属性值方法

        return right;

    }



    @Override

    public Object accept(Visitor visitor) {

        return visitor.visitProduct(this); // 调用访问者的方法

    }

}