在实际工作中，所有任务都可以归结为围绕目标、指标、方案、排期四个核心维度展开。

• 目标：明确要实现的最终结果或期望状态。
• 指标：用以衡量目标是否达成的量化标准。
• 方案：实现目标的具体路径与方法。
• 排期：根据优先级和资源分配制定的时间计划。

这四个核心点，又可以进一步细分为短期、中期、长期三个时间维度，每个维度对应不同的侧重点与解决策略：

1. 短期方案​

短期方案专注于快速解决当前的紧急问题，常常作为“临时救火”或“特事特办”的解决办法。

• 优点：实施简单、见效快，能够迅速缓解压力。
• 缺点：灵活性较差，容易受限于当前场景。一旦有新的需求加入，或问题变复杂，短期方案可能难以为继，甚至需要返工。

2. 中期方案​

中期方案处于短期和长期之间，兼具灵活性与前瞻性。它既要解决当前的问题，又需要为未来的扩展性预留空间。

• 优点：在当前需求和未来可拓展性之间找到平衡，能够容纳一定程度的新需求。
• 挑战：需要权衡短期投入与长期收益，确保方案足够灵活但又不失稳定。

3. 长期方案​

长期方案立足全局，旨在彻底解决当前及潜在的问题，追求方案的全局最优。

• 优点：系统性强，考虑周全，能够适应未来更多的场景变化，减少重复建设和返工的成本。
• 挑战：通常需要投入较多的人力、物力和时间，短期内可能无法见效。

在实际工作中，短期方案适用于快速响应，短期见效；中期方案强调当前与未来的平衡；长期方案则专注于全局优化。三者并非互相替代，而是可以结合实际情况，逐步递进，通过阶段性优化最终实现长期目标。

从实时数仓的优化来看，制定方案时需结合短、中、长期维度，根据问题的紧急程度与复杂性合理分配资源和优先级，最终在动态中实现整体效率的提升与架构的稳健升级。

目标​

明确方向，定义终点​

目标是工作的起点，也是衡量最终成果的标尺。在任务开始前，明确目标的作用在于：

1. 聚焦关键问题，确保资源投入到真正重要的事项上。
2. 避免偏离方向，减少因需求不清或执行偏差导致的资源浪费。

定义工作项​

为更高效地推进任务，需要根据优先级对工作项进行排序，并结合短期、中期和长期目标分层规划：

前置准备：梳理现状，明确需求​

在所有工作开展之前，首先需要全面梳理现有的实时链路，了解以下核心内容：

• 当前业务场景的全貌，包括上游和下游的特点。
• 具体的需求与痛点。
• 链路的使用量及性能瓶颈。
  这一步是后续优化工作的基础，确保解决方案能够精准对焦问题所在。

1. 短期目标：解决紧急问题，快速见效​

优先级：P0（重要且紧急）
示例任务：优化“财富总览”场景的性能问题，目标是解决其在高并发场景下的性能瓶颈。

• 短期策略：针对性的 Case 优化，聚焦于当前最关键的痛点。
• 特性：短期目标执行迅速，成效明显，但解决方案通常缺乏系统性，后续需要进一步调整和完善。

短期目标总结：快速解决高优先级问题，保障核心场景的业务连续性和易用性。

2. 中期目标：标准化提升，增强复用性​

中期策略：从现有实时链路中抽象模式，进行套路归并与标准化管理

• 核心思路：通过分析大量实时链路的作用与特性（如实时表同步），提炼出适配大多数场景的固定 Pattern，推进以下两方面的改进：
  1. 工艺流程优化：通过模式化设计，让实时数仓的工艺流程更加标准化。前期梳理典型业务场景，后期推动业务系统对齐标准。
  2. 资源与需求管理：从团队角度简化资源调配和需求管理，提供统一的外部服务接口，提高协作效率。
• 目标：提升链路的清晰性与复用性，减少重复性开发工作，增强系统的灵活扩展能力。

中期目标总结：在解决当前问题的基础上，为后续需求的快速响应和标准化建设奠定基础。

3. 长期目标：引入前沿技术，全面优化架构​

长期策略：引入新技术作为全局性解决方案

• 核心举措：探索并引入前沿技术（如数据湖、物化视图等），打造一站式解决方案，全面应对当前及潜在的业务需求。
• 目标：最大限度降低人力物力的投入，追求架构的全局最优，消除重复性返工。

长期目标总结：通过前沿技术的应用，为数仓优化提供终极方案，实现架构的高效、稳定和可持续发展。

通过分阶段目标的定义与实施，可以在不同的时间维度内逐步优化实时数仓架构：

• 短期解决燃眉之急，快速见效；
• 中期搭建标准化框架，提高复用性与管理效率；
• 长期实现全局优化，为未来的业务扩展提供稳健支持。
  在实际工作中，需要灵活调整各阶段策略，根据问题的复杂度和优先级合理分配资源，逐步实现实时数仓的高效优化与持续迭代。

指标方面​

量化目标，跟踪进度​

指标是目标的具体化表现，通过量化数据直接反映目标的达成情况，是工作进展和成效的“晴雨表”。
在实际工作中，指标需要满足以下两点：

1. 可衡量：指标应具有明确的数值表述，便于比较与评估。
2. 可监控：指标数据应能实时采集和追踪，以便及时调整策略。

定义工作项​

结合实时数仓优化的实际场景，指标的设计需要覆盖多个关键维度，以全面反映优化效果：

1. 性能提升​

• 方案总耗时：对比优化前后方案的总耗时，明确效率提升的幅度。
  • 示例：优化前总耗时 300ms，优化后总耗时 200ms，效率提升 33%。

2. 资源利用​

• 内存占用：监控优化方案的内存使用情况，计算减少的资源占用量。
  • 示例：优化前存储过程的内存使用量 8GB，优化后减少至 5GB，节省 37.5%。

3. 扩展能力​

• 横向拓展与不停机能力：对比原方案与新方案在性能瓶颈时的行为差异。
  • 示例：原方案性能瓶颈需要纵向拓展，停机耗时 3 小时；新方案通过横向拓展实现了零停机，节省了 3 小时维护时间。

4. 并发支持​

• 性能阈值下的并发量：评估原方案在高并发场景下的性能极限，对比新方案在同等条件下的性能提升。
  • 示例：原方案在 10,000 并发时达到性能瓶颈，新方案在 15,000 并发下才达到瓶颈，提升了 50%。

5. 响应时间 (RT)​

• 相同并发条件下的 RT 改善：对比原方案与新方案在同样并发量下的响应时间，明确优化效果。
  • 示例：原方案在 10,000 并发下 RT 为 500ms，新方案优化至 350ms，提升了 30%。

指标的作用​

通过以上指标，能够清晰地评估工作的进展和成效，并及时发现潜在问题，为策略调整提供数据支持：

• 实时监控进展：通过指标监控工作进度，确保优化工作朝预期目标推进。
• 辅助决策调整：根据指标数据动态调整优化策略，避免资源浪费或方向偏离。
• 效果量化反馈：通过指标数据直观展示优化效果，提供决策依据。

方案方面​

方案是实现目标的具体路径，也是工作的执行计划。在制定方案时，通常需要经历以下几个步骤：

1. 调研与分析：明确当前问题的核心与瓶颈，深入理解目标达成的难点。
2. 头脑风暴：提出多种潜在解决方法，涵盖不同的技术和策略。
3. 筛选与验证：根据成本、时间、效果、风险等因素，选出最优方案，并通过试验验证其可行性。
4. 详细设计：将方案分解为具体的执行步骤，明确责任分工和时间节点。

定义工作项​

以实时数仓优化为例，针对不同场景和问题，可以提出以下几种方案：

方案 1：优化 SQL 语句、查询逻辑以及数据库参数​

• 内容：优化 SQL 的执行计划、数据库参数和索引设置，并尽可能直接计算结果表而不是明细表。
• 优势：工作量和改动量最小，适合现有配置接近最优的场景。但仍有继续优化的空间，例如继续优化某一存储过程的 session 内存占用。
• 局限：优化空间有限，效果取决于当前的数据库状态和业务逻辑。例如，数据库参数和索引可能已被前人优化到接近极限。
• 改造目的：通过减少不必要的计算和资源消耗来提升执行效率，降低查询响应时间，提高短期性能。

方案 2：使用分库分表​

• 内容：将单一大表拆分为多个小表，通过分库分表缓解访问压力和 IO 瓶颈。
• 优势：有效分散读写压力，显著提升查询性能。
• 局限：改动量适中，需要对原有表结构和业务逻辑进行重构。
• 改造目的：缓解单点压力，将查询和写入负载分散到多个表和库中，提升系统吞吐量和查询效率。

方案 3：服务编排，将存储过程迁移到应用层​

• 内容：将存储过程的计算逻辑迁移至应用层，通过 API 编排实现横向扩展。聚合操作依然在ADB 中实现，在应用层做加和操作。
• 优势：提升了横向扩展能力，通过增加应用服务器来避免单点瓶颈。
• 局限：需要将存储过程逻辑从 SQL 转换为 Java 实现，同时对数据服务平台进行适配性改造。后续新增功能需要同步调整编排逻辑。
• 改造目的：通过应用层扩展逻辑来分担计算压力，避免数据库成为单点瓶颈，提升系统弹性。

方案 4：基于 Flink + Hologres 的流式数仓​

• 内容：建立实时数仓，通过 Hologres 实现预计算，应用层仅需执行简单的加和或返回操作。
• 优势：在高并发场景下提供高效点查能力，将大部分复杂计算提前至数仓完成，提升整体性能。
• 局限：改动量最大，涉及实时链路的全面重构，需要构建分层实时数仓，对人力和资源的需求较高。
• 改造目的：通过预计算和分层处理实现复杂场景的高效查询，减少延迟并降低应用层的负载。同时便于支持未来大规模、高并发场景下的实时数据处理和查询需求，通过实时链路优化整体架构，达到性能的全局最优。

方案分析​

1. 工作量与改动量最小的方案：
   主要通过优化已有资源来提升性能，适用于短期内见效的场景。但此方案改善有限，且受制于现有系统的优化空间。

2. 平衡型方案：
   分库分表是常见优化的典型方式，通过调整表结构和分片策略提升性能。

3. 提升横向扩展能力的方案：
   服务编排适合未来可能不断增加的需求场景，但需要投入一定的资源进行逻辑迁移和架构调整。

4. 长期全局优化方案：
   基于 Flink + Hologres 的方案专注于全局最优，通过实时数仓支持复杂场景下的高效查询，适合面向未来的大规模系统架构，但需要较高的初始投入。

方案选择的决策权​

需要特别注意的是：具体选择何种方案，通常需要由领导决定。领导站在更高的视角，能够综合考虑企业的发展战略、资源分配以及团队能力，从而选择最符合当前实际情况的方案。作为执行者，需要为领导提供详尽的方案分析和数据支撑，帮助其做出合理决策。

排期​

排期是将方案落实为实际行动的重要一步。它明确了任务的优先级、负责人和时间节点。在排期时，需考虑以下因素：

• 任务依赖：识别出哪些任务必须先完成，哪些可以并行推进。
• 时间预算：为每个任务分配合理的时间，避免不切实际的压缩。
• 风险评估：为可能的延误或问题设计缓冲时间和应对措施。

定义工作项​

以下是排期的具体工作拆解，以当前项目为例：

1. 实时任务盘点​

• 任务：
• 梳理所有实时任务的台账，确保数据全局清晰。
• 梳理当前存储过程具体内容，调用session所占内存消耗
• 了解前期阿里方优化存储过程具体内容，避免重复工作
• 时间计划：
  • 第一周：完成 v1.0 版本，初步判断现状与问题。
  • 第二周：补充遗漏任务，完善细节与标准化。
• DDL：12.20，一周判断v1.0，一周补充完善

2. 技术可行性验证​

目标：验证当前技术方案的适用性，避免在后续阶段因技术限制导致返工。
任务列表：

• Blink 技术验证：
  • 检查是否支持提交 JAR 任务，验证自定义 Sink 和 Source 的可行性（用于搭建 Blink + Holo 标准版的实时数仓分层）。
• Holo 技术验证：
  • 大宽表性能测试：评估复杂任务在 Holo 上的性能表现。
  • 极限并发测试：探查 Holo 在高并发场景下的性能上限。
• ADB 技术验证：
  • dblink插件，实现跨库查询（用于支持分库分表）
• Rill Flow 部署验证：验证服务编排是否可行。
• DDL：12.27，根据验证结果同步调整优化方案

3. 方案预研​

目标：提前识别并优化方案中可能的瓶颈或不足，为后续落地奠定基础。
任务列表：

• 存储过程分析：分析“财富总览”功能中的存储过程，记录重点 Session 的内存消耗情况（评估事前的优化空间）。
• 服务器拆分压测：针对应用服务器进行性能测试，重点关注 QPS、RT 和内存优化表现（评估迁移后的承载能力和提升预期）。
• DDL：1.18

1、接受工作，只问标准。

领导安排你活后，你可以不问为什么要做、有什么意义等等，但有一件事你必须当面问明白，那就是：“领导希望这件工作达到一个什么样的状态？”

因为要想量化考核工作，就必须要有明确的工作标准；因为要想达成目标，目标本身必须清晰。这个不能意会，只能言传或者白纸黑字写清楚，这样才可避免误解。

如果领导期望达到a标准，你却认为b标准就行，结果就是你吭哧吭味地把工作做到b标准，满以为领导会嘉奖你，结果却得了个“工作不合格”的回答，你一定会认为受到了不公正的对待，满腔热血瞬间冷却。

2、请示工作，带着方案。

你总会遇到一些难题为了解决它们，你少不得要向领导请示。请注意，在请示前，你一定要站在实际角度给出一到两种解决方案。你不是领导者，没有决策权，但你是执行者，具有强大的建议权。会做工作的人，懂得给领导做选择题，而不是做问答题。

现有两种请示风格，一种是“我们遇到问题，不知怎么做，请领导指示”，另一种是“我们遇到一个问题，想到了两种解决方案，请领导定夺”，哪一句话会受到领导的青睐？显然后者。

还有个致命原因是，如果跟领导请示时，只谈问题不带方案，说着说着很容易就情绪激动，变成抱怨，矛头直指客户领导，那就更糟糕了。很可能你得到一时口舌之快，却永远失去成长的机会

3、汇报工作，先说结果。

他们深知一切没有结果的工作汇报就是浪费时间。领导肯定在意的是结果，谁会听你唠叨的工作过程，只有结果极好极差的时候，领导才有兴趣听过程，就跟上学时，班主任最先容易记住的是班里成绩前几名和倒数几名的学生。

领导首先关注的一定是结果。虽然重点是说结果，但也不能只说结果。

你说：领导，上个月公司电费超预算了2万元。

领导：？（好家伙，你小子逗我呢）

告诉你一个汇报小方法：结果+背景+行动你说：张总，上个月公司电费超预算了2万元。（抛出结果）公司创立至今，各种电器一直未采用节能设备，同时.....（交代背景）所以，行政部采取了…解决这个问题。（说明行动）

这样向领导汇报，是不是简明扼要，领导一听就懂啦？

之前有个奇葩的手机软件，能让领导看到员工的加班过程。当时有人一针见血的说“领导要的是结果，哪有时间看你的加班生活。这东西肯定活不长。”果然，到现在已经看不到它任何踪迹了。

确实，你天天只会让领导知晓你在加班，缺拿不出领导满意的结果，这些行为恐怕只会给你减分。

4、分享工作，细说流程。

如果某项工作你做得很漂亮，领导安排你跟别人做个工作分享，推广经验。这时，你就得重点谈工作过程了。

工作结果轻描淡写即可，只要稍微谈得多点，立马就会给人吹嘘卖弄的感觉。要知道，别人花专门的时间来听你讲，学取经验，而不是检查工作。 他们关心的是你中间究竟做了哪些流程控制，最终才会把工作完成得这么出色。

5、总结工作，漫谈感受。

如果你足够优秀，做出了惊艳的业绩，在大会上或领导面前复盘工作，这时重点，就要放在务虚的工作感受上了。比如，谈谈自己在面对高标准严要求时是如何自我激励的，在面对困难险阻时是如何迎难而上的。你也会被贴上“工作能力出众”的标签。谁说人不愿被人贴标签，人只是不愿意被人贴上负面标签而已。正面标签，大家喜欢着呢。

6、再教你一招，想凸显自己的工作能力，只需要记住一个字，催。

下催员工，上催领导，内催同级，外催客户，上上下下，无处不用到这个催字诀。

设身处地的想一想，当你发现了问题、明确了目标、给出了解决方案、确定了执行人、定下了交付时间、明确了交付物、与执行人—一确定了分工，接下来要做什么？

坐等吗？

不，那样计划绝对不可能按时完成。那要如何做？答案就是一个字，催。

有人可能想，催谁不会呀，不就是盯着人不停的唠叨吗？

你试试？别人成天对着你唠叨你就会乖乖把活干了？所以“催”可不简单，始于技术，终与艺术。

催下属： 怎么催？坐在旁边盯着？盯一上午，人家下午就撂挑子不干了信不信？人家觉得你不相信我，那你自己干吧，你以为我求着你给你干活呢？所以，催下属，一定要做到对事不对人。

把计划拆解详细，最好每天都有一个交付结果，然后形成完整流程，每天固定花10分钟碰进度，大家自己说自己的进度，超时的，要说清楚为什么超时？解决方案是什么？预计会超时多少？对整个计划的影响是什么？需要什么帮助？需要什么资源？等等。

这样，你就不是在盯着人家，而是跟人一起解决问题，不会引起反感。如果真的超时，你也可以很快得到反馈，及时采取方案止损。

催同级： 怎么催？还像下属那样每天固定时间碰头会？人家有人家的安排，凭什么听你的；自己主动去问进度？一次两次还行，次说多了人家烦了怎么办；让人家追进度？人家听你的吗；给他老板打小汇报？这就不成了告黑状了。

所以，催同级，重要的还是机制。 与催下属类似，这次把他的领导和你的领导拉上，需要的话，最好把大领导也拉上。每周例行汇总工作进度，把超时项醒目的单列出来。并跟领导说明，这些超时会导致项目整体延期多少，自己超时的给出解决方案，别人超时的让他们自己给出解决方案。如果还不听话，那就是领导的问题了。

催领导： 什么？还要催领导？难道不都是领导催我们吗？没错，就是要催领导，不催领导说明你的向上管理做得不到位。

很多项目需要的资源是在领导手里面，这些资源可以大大减少你完成项目的难度，能用凭什么不用？ 所以，在做计划时，一定要把大小领导都拉

进来，都是给你们干活，要你们点资源怎么了？ 而资源中，最重要的就是管理资源，说白了，就是有些话你说了不管用，领导说了就管用。

领导作为最终负责人，肯定是最关心项目进度的，真要完不成，他是最大责任人，底下小员工反倒可以混日子。

领导最苦恼是下属没人跟他一条心，一个项目只有他一个人着急，其他人都悠哉游哉。 这正是你挺身而出的时候，受人之托、忠人之事，为了自己的荣誉，哪怕领导打退堂鼓，你都要坚持住。

所以，如果你是牵头的人，必须有舍我其谁的气势，神挡杀神、佛挡杀佛，清除一切阻碍，领导也不例外。该领导签字的，盯着催他签，该他发的话，盯着催他说。每天汇报进度，如果找不着人，那就堵门口，哪怕一句也得见面说上这话。

这样领导会不会烦呢？你放心，他要是明白人，高兴还来不及呢。有你这么个小闹钟，他自己就不用时时刻刻记着催你了。当然，领导如果不是明白人，劝你趁早另谋出路吧。

你必须知道的一些职场经验：

1、有些上司喜欢装作轻松幽默，天天开玩笑和你闲聊，实际上是在通过侧面套话观察你对某些事情和观点的反应。接着，他会以玩笑的形式挑拨事端，看着你在一旁的反应！

2、切勿自以为比同事聪明，更不要玩弄小聪明。大家都在同一家公司，别以为智商差距很大。有时候，我们自认为很聪明，其实别人早就看透了。一旦被发现是这种人，就很容易被排斥。

3、学会保持低调。 在上司面前不要展示对讨厌同事或有争议情绪的不满，因为除非涉及上司个人利益，他们通常不会介入调解。这样他们能更迅速地了解每个人的优劣，从而更好地权衡个人的能力！

4、工作点到为止。 按劳分配懂吗？只要完成了工作，没必要超额完成，现在的职场充斥着太多偷懒的人。不要冒进，像个听命的韭菜盒子，越是努力，出错和树敌就越多。最近收到的粉丝求助基本上都是为了超负荷工作，最后却得不到功劳和尊重。老板觉得你应该这样，同事觉得你活该。明白了吗？

5、老板不让你提建议时，你有再多好的建议也别提，但平时想到的话要归纳整理，当老板问你时，你再说。（别问我为什么，这是潜规则，不信你试试就知道结果了）

6、对领导的能力或人品有疑虑时，记住，向上沟通并不是解决问题的有效途径，真正的解决方法是换个环境。如果一个人明显水平不济还能坐在高位上，要么他的领导愚蠢到看不清，要么他的领导心知肚明但故意包庇。

7、做事前三思“能不能不做，能不能让别人做，能不能明天做”

能不能不做：动手之前三思，这事真的非得做吗？做了对自己和部门有什么实际好处和价值呢？每个人的职责都是公司战略的具体执行，每项具体工作最终都应指向战略目标，这就是战略思维。

能不能让别人做：非得你亲自上阵吗？难道没有其他人能做吗？这不是推卸责任，而是需要学会合理授权和任务分配。公司支付工资给每个员工，不是为了让大家去做超出职责范围的事情，分散精力只会导致自己本职工作都做不好，得不偿失。这就是明智的任务分工和正确的用人原则。

能不能明天做：看似急迫的事情真的有那么紧急吗？手头任务那么多，哪一个是真正紧急且重要的？如果这事明天再做，会不会因为领导的指示变化或外部因素发生变动而干脆不需要做了？这涉及的是任务管理和洞察力。

8、会哭的孩子有奶吃。

工作能力强的人，会让领导知道你现在手头很忙，不是找借口不做，而是可以后续再找时间做。领导派活后，你先说手头在做1，2，3，哪些事情，再问您刚交代的任务是否着急，若着急做，大概什么时候要完成，您看xx时间行不行？

9、工作能力强的人，还会主动创造：非正式场合汇报的机会。

比如在电梯、食堂聊天时有意无意提一下工作，看下领导的反应，如果他愿意接着聊，就提一下建设性的意见，进而跟领导讨论这事的可行性。他们深知非正式的场合，气氛会更轻松一些，领导也更愿意说些自己内心的想法。

10、走上层路线的人，永远比走下层路线的人混得好，为什么，因为秩序是自上而下的。

当你取得成绩获得表彰的时候，不要把奖金拿出来请同事吃饭，因为他们帮不了你什么。而拿出来感谢领导那就不一样了，下次如果有好的机会，领导铁定第一个想起你。

在对上、对中、对下三个维度的关系中，对上的关系最为重要，也需要更多的维护。

11、不管在哪里工作，少说话绝对都是保身的不二之策，你不说话，就会少去很多把柄。

要知道，办公室里没有秘密，你以为的悄悄话，你以为的放心人，搞不好转身就变成了另外一种情形。俗话说，三人成虎。很多话传着传着就变味了，解释都解释不清楚。

需要特别注意的是，不要吐槽单位、抱怨领导，很多事情自己心里清楚明晰就好。

12、责任和担当，并不是什么事情或什么责任都往自己身上揽，而是把握好责任界限。

不是你的问题你还去揽，不是你的活你还去干，不仅不会让别人认为你有责任有担当，还会让别人认为你是个傻瓜，进而把更多脏活累活或莫须有的责任推给你甩给你。

是自己的就果断承认，不是自己的那就坚决拒绝，做人做事一定要有自己的原则。

原文链接：职场上哪些行为会凸显自己的工作能力

做好以下 6 件事：

每日阅读​

每天读 2 - 3 篇文章，可以是行业趋势、技术干货（自己的工作有关的方向）、经验分享、思维提升等。坚持一年，你就读了将近 1000 篇文章，相当于几十个教程，绝对大有裨益。

文章从哪儿找？

• 大厂的技术博客：适合想学硬核技术的同学，比如美团技术团队、阿里技术团队

• 科技资讯类：量子位、差评、新智元、无敌信息差

• 经验分享、编程趋势、技术干货：程序员鱼皮、小林 coding、java guide、程序喵、神光的编程笔记、小白 debug、古时的风筝、苏三、阿秀等

技术学习​

对程序员来说，一定要持续学习新技术。每天只需要抽不到 1 小时，看 2 - 3 集教程，那么坚持一个月，你就能看完一套课程。

或者每天写 100 行代码，一周一个功能，那么坚持一个月，你就能做好一个项目。

复盘总结​

之前也给大家分享过，这是我坚持多年的习惯。

可以尝试做以下几件事：

• 每天记录自己完成的工作，哪怕贴个需求链接啥的也可以

• 每月记录自己这个月重点在做的事情，以及完成的工作、学习的情况等

• 每半年或者每完成一个大事，做一个复盘总结。记录自己做这件事情的经历、过程、结果、好和不好的地方，防止后面踩同样的坑。

整理自己的弹药库​

为什么有些人工作五年，感觉还和工作一年一样？

可能就是没有做好 积累 ，把之前的经验忘完了！

所以，积累真的很重要，大家可以从以下几个方面下手：

• 整理属于自己的 Bug 库，记录你解决过的问题

• 整理属于自己的经验库，记录你踩过的坑

• 知识碎片积累：把你学过的所有知识点，以碎片的形式进行记录整理，后面要做项目时都可以复用

• 软件库（工具库）：整理自己的常用软件、工具，保证自己工作的高效

分享​

只要你做到了上面几件事，那么你一定是有非常多能分享的内容的。

比如：

• 分享自己的复盘总结和个人经历

• 分享自己的弹药库

• 分享自己学过的知识点

• 帮助别人答疑解惑

直接把自己之前记录的内容分享出来，就会对别人有帮助，也会收获别人的关注和认可，从而给自己获取正向激励再帮助自己更快地提升，然后再分享更多内容，这是一个非常好的良性循环。

我也是通过这种方式，从自己背过的面试题、再到自己的个人经历、再到自己的项目，依次给大家分享出来，才慢慢收获了更多人的关注，成为了一个博主。谢谢大家！

目标拆解​

工作后想持续学习，其实是非常难的，因为我们会本能地担心由于工作的影响，没有更多精力和时间干大事。

这种时候，我们一定要学会将目标拆解。比如你想做一个大项目，可以把它依次拆解为做一个子系统、做一个小的功能、小的模块、学一个技术、看一套课程、看一节教程、看 10 分钟教程。

只要把目标拆解地足够小，做好计划表，然后按照计划，每天坚持执行就好了。

最后还有一点，就是我们要多思考，比如我无法坚持学习，本质的问题是什么？跟改 Bug 一样，先发现问题、再针对性地解决，这才是我们遇到任何困境时的破局战略。

种一棵树最好的时间是十年前，其次是现在。先从上面的任何一件事开始做起，坚持 21 天养成习惯，你就会意识到自己的改变，大家加油，共勉！

原文链接：要是工作前就知道这个，该多好。

视频链接：程序员在工作中如何快速成长？我的 6 个技巧分享_哔哩哔哩_bilibili

• 保持一颗解决问题的心
• 了解你的用户
• 不要拿自己的尺子去度量别人
• 保持学习、be open-mind
• 想清楚，再下手写代码
• 敬畏用户
• 跨团队合作是利益交换
• 用别人的语言交流，会有意想不到的收获
• 理解前人写的「烂代码」
• 在技术和工作之间找到平衡点

来源：做了 6 年程序员，我学到的 10 条经验 | Randy's Blog；仅学术引用，著作权归作者所有。

保持一颗解决问题的心​

按照我的观察，那些在工作中用技术取胜的人们共同点都在于他们能保持一颗解决问题的心。他们可以率先想到一种更优的手段解决存在的问题(一般是效率问题)。他们不是嗅觉特别灵敏或者技术特别强，而是当他们遇到了问题，不是把它作为抱怨的话题，而是开始思考这个问题为什么没人解决、应该怎么解决，然后把它实现出来。这种心态在职场上特别稀缺。

我在创业公司的时候做一个图文排版的 App, 设计师会设计一些模板，然后交给我来实现。当时我们有很多模板，为了测试这些模板实现在不同的手机屏幕大小会有什么问题，我们要花特别多的精力。可以想象测试的数量 = 模板数量 * 屏幕尺寸的数量。后来我用 puppeteer 写了个自动生成不同屏幕和模板的截图，直接交给设计师一个一个地看。节省了大量的时间。这个事情没什么技术含量，但它解决了很重要的问题。

工作中需要解决的问题不仅仅在代码上，也有可能出现在非技术问题上。工作中我特别喜欢和非技术同事聊天，了解他们的工作。因为我常常觉得影响项目前进的原因不一定出在我们用了不适合的技术或者不够「先进」的技术。了解非技术同事的工作流程让我大有收获，我会发现他们有一些工作是可以通过写一段程序把原本的工作量做到指数级的下降，而通常非技术同事是很难察觉到的。

这样的例子特别多。有次我和一个运营同事聊天，我们当时在开发一个新闻内容的管理后台，他们常常用这个后台对一些内容做分析。聊天的时候了解到他们有一部分的工作就是在上面按条件查询一些内容，再一条条地粘贴到 excel 里面，他说这常常要花一下午。后来我帮她做了一个一键导出成 excel 的功能。

她觉得这很不可思议，但这在技术的角度来说太简单了。我也因此了解到，对于不是做技术的人来说，他们很难察觉到哪一些事情是可以用技术解决的，所以我们不能希望他们主动地提出一个需求，只能我们作为掌握技术的人主动地去了解他们。

有一次我和我们的测试吃饭，聊到他们怎么做测试。我发现他们会用 mindmap 先梳理出来一些测试流程，然后一个个地做。但是痛点在于他们常常要手动维护一个文档列出这些 case 的测试结果，这些结果包括截屏，以及证明测试通过的请求返回信息等等。不但麻烦，还很难追踪。

于是我做了一个小 demo Web App，他们可以直接上传他们做好的 Mindmap, 通过他们的 mindmap 直接生成出

来 case item，在项目的开发环境页面代码里面，只要注入这个 case id，就可以在测试之前开始记录请求日志，结束之后会上传到这个平台，这样在这个平台就能直接看到每一个 case 操作的时候的整个过程的记录。这个小 demo 后来被用于花呗的大部分前端项目，当然听说现在已经做得和我当时做的小 demo 完全不同了。

了解你的用户​

我自认为自己还算是一个有那么一些产品思维的程序员，因为经常也会写一些自己的小产品。但在刚出来工作的时候，我在工作中太沉迷于技术本身。把心思都放在了诸如怎么重构，怎么改进构建速度之类的问题。我在阿里 P5 升 P6 的答辩中，我被问了一个我至今印象深刻的问题：你有了解你的用户是怎么用你在做的这个东西吗？

这个问题是我从来没有想过的，我哑口无言。可能它只是一个晋升答辩问题模板中的一个问题，但对我来说这个问题让我清醒了许多。当时我们做的是内部用的新闻内容管理后台，这个后台的用户是一些小编。我们和这些小编有一个群，但基本是用来报 bug 的。我离这些用户这么近，却从来没有了解过他们的使用感受。我想，如果我当时找他们聊一聊，可能也会有意想不到的收获。或许他们会抱怨这个后台的加载速度很慢，我们就可以着手解决加载速度的问题，而不是和同事纠结在用哪种前端状态管理库这种无聊事情上。用户并不关心我们用的是 MobX 还是 Redux.

不要拿自己的尺子去度量别人​

我刚出来工作犯的最大的错误之一就是拿自己的尺子去度量别人。我因为从小对编程痴迷，写程序对我来说是人生中最大的兴趣，我把几乎所有的时间都花在了技术上。当时我天真地认为所有程序员都应该像我这样，对待技术也应该有一种理想主义，我在互联网上结交的技术朋友都是这样的。所以我当时对我的同事特别苛刻，甚至对那些把写程序只当成工作的人嗤之以鼻。后来回想起来，这是非常错误的想法。每个人有每个人的追求，技术也只是多个兴趣爱好的其中一种。在当时别人的眼里我可能是个「怪人」，甚至有点「装逼」。

保持学习、be open-mind​

我每天都会在 Twitter 和 Hackernews 发现很多最新的技术和思考，我关注了很多开源库的作者，我可以第一时间了解到他们最近在思考什么，在接触什么。这种主动接收会扩大你的眼界，让你在解决问题的时候有更广的思路。

不要只关注自己的领域。我还关注了很多写 Rust, 写 Go, 写 iOS/Android 的人。主要是学习技术背后解决问题的方式，这些解决问题的方式说不准也能应用到你自己的领域。

保持学习一直是和同行拉开差距最重要的一点。

想清楚，再下手写代码​

我写代码的速度非常快，因为我已经花了超过十年的时间在写代码了。很多东西想实现，对我来说基本是纯粹的堆代码。导致我非常容易不经过多的思考就开始动手写。我为此吃了不少亏，常常写到一半发现一些没有想到过的问题，导致需要重新设计，重新改写。我的一位前老板很了解我，他也是个多年经验的程序员了。有一次我们在讨论一个新东西，他对我说，「不要着急，想清楚了再写」。这句话我一直记在心里。后来每次动手写代码之前，我都会把整个流程的设计先思考清楚，避免了很多不必要的重写。

敬畏用户​

在写自己的一些没什么人用的开源库或者公司内部用的平台的时候，通常不需要过多思考就能把代码发布出去。到了做花呗这种用户基数庞大的产品，才意识到代码发布和以前所体验到的完全不同。

蚂蚁金服有代码发布的「三板斧」，这是从入职培训到实际工作中就会被反复提及的 must-follow rule. 「三板斧」指的是「可灰度」、「可监控」、「可回滚」。在代码发布之前，要先想想自己的代码是不是符合这三个条件。

你的代码发布之后，如果出了问题，是不是可以被监控到的？

你的代码是不是可以灰度发布的，而不是一下子全量被推到线上的？

代码发布以后，出了问题，是不是可以回滚的？如何回滚？

在经历了用户基数如此庞大的产品开发之后，我对代码发布变得尤为审慎。我记得有次只是单纯改了某段 HTML, 但我还是盯着这个 PR diff 看了几分钟，在想这个修改会不会导致什么问题。

虽然蚂蚁的基础建设可以让这三板斧很容易实现(有成熟的发布平台进行灰度和回滚，有成熟的监控库)；虽然即使遵守了三板斧，还是会有 bug. 但是这种代码发布的思维模式是好的，即使我到了别的公司，我在代码发布前还是会问自己这三个问题。

跨团队合作是利益交换​

在大公司里，有时在做一个事情的时候，需要别的团队一起合作，或许是用到别的团队的接口、或许是需要别的团队开发新的接口，但这通常很难。我以前天真地以为，只要我们做的事情是有利于业务的，别的团队自然就应该一起合作。但实际上，大家更看重的是这个事情对自己的团队有什么好处。

换位思考一下，我们和别的团队合作，对于他们来说，增加了工作量，增加了风险(带来更高的 qps, 写更多的代码会导致更多的维护成本)。决定是否合作，首先取决于这是否是自上而下的要求，其次就是合作对他们的 KPI 有没有好处。

所以我学会了在游说别的团队合作的时候，首先应该想明白合作能给别人带来什么好处，而不是对事情本身夸夸其谈。这样更容易促成合作。

用别人的语言交流，会有意想不到的收获​

有研究发现如果你用别人的母语和他交流，他会更容易接受你的观点，对你也会更友好。我发现这个心理同样适用在技术交流中。作为一个前端程序员，在和后端程序员商量技术方案的时候，如果可以更多地使用后端的术语，从后端的角度反推前端的想法，他会更容易接受。

我自己业余是个 full stack 程序员，所以很容易切换到别人的语境，也能从别人的角度去理解他的想法。因此沟通会更加顺畅。

理解前人写的「烂代码」​

这里的「理解」不是指理解烂代码的逻辑，而是理解为什么会写成烂代码。我经常会听到同事抱怨他看到的旧代码写得如何烂，但是实际上很多烂代码产生的原因不是因为技术不行，而是受限于技术的发展和业务的复杂性。随着自己写的代码越来越多，就越能理解这些「烂代码」的存在。看出来了烂代码，也不要着急去重构，这些代码很有可能藏着一些你不知道的特殊业务需求。如果你不需要碰这些代码，那就尽量别碰。

在技术和工作之间找到平衡点​

在刚出来工作的前几年，我特别陶醉在把自己学到的新东西试图用在工作中。我的想法是，只有我把这个技术用到实际的工作中，我才算学习了这个技术。

其实这个想法是不对的，学习技术并不一定要求你把他用到工作中。工作就是工作，学习就是学习。工作的内容是为了业务服务的。我在创业公司工作的时候，曾经因为把一个我刚学习到的库用在业务中，因为一些我不知道的坑导致业务进度出了点问题。老板生气地说：业务不是你的试验田。

我后来遇到很多「后辈」(我竟然也开始有后辈了) 请教我说觉得自己在工作中不能运用到自己平时学习的技术，因此觉得自己技术没什么长进。我认为这种想法不太正确。

能把学习到的技术运用到自己的工作中当然是最好的，但这是可遇不可求的事。但是这不代表没有用在工作中，就等于没有真正学习到这个技术。我认为很多人对技术学习有错误的理解，对我来说，学习技术的精髓在于理解这个技术的 Why, What, How. 和能不能用到工作中没有太大的关系。

举个例子，我在刚接触到 Redux 的时候，我去学习它，除了了解它怎么用以外，我特别关心的是，Redux 的哲学是什么？是什么启发了 Redux 的作者创造了 Redux? 他和别的库有什么不同？顺着这些问题，我就会了解更多的东西，比如我发现 Redux 是受了 Elm 的启发，我就会去了解 Elm -> 了解 Functional Programming -> 了解 Immutable, 然后关注 Dan (Redux 的作者) 的 Twitter, 看他日常会分享什么，看他对自己做的这个东西的理解是什么。即使我没有把 Redux 用在工作中(事实上我从来没有用过 Redux)，当我在学习这个库的时候，我学习到的不仅仅是 Redux 本身，还有它背后的更多东西。我可能很快就会忘掉 Redux 的 API, 但那又如何，那些它背后的知识才是最有价值的，是不会被忘掉的。

而工作则相当于是一个真实的场景，是在你学习新的技术的时候，帮助你进行实际思考的场景。你需要有意识地去想，这个技术如果用到我的工作中，它是否适合？它能解决什么问题？它为什么适合？它为什么不适合。当你在学习新技术的时候，结合这个技术，多思考这些问题，这才是真正的学习。

Docusaurus 是一款静态站点生成器。 可以搭建带有快速客户端导航的单页应用，充分利用了 React，让你的网站具有交互能力。 它提供了开箱即用的文档功能，不过也可用于搭建各种网站：个人网站、产品、博客、营销主页等等。

安装​

• Docusaurus 官网
• Docusaurus 官网（中文版）

因为中国官网文档更新相对滞后，所以这里推荐使用英文官网，进入后选择中文。

环境​

• Node.js （中文网） v16.14 或以上版本
• 本文使用 Docusaurus 2.0.0-rc.1 作为演示

初始化​

使用命令行工具可以帮助你快速简单地安装 Docusaurus 并搭建网站框架。 你可以在空仓库或现有仓库的任何地方运行这个命令，它会创建一个包含模板文件的新目录。

npx create-docusaurus@latest my-website classic

项目结构​

命令行工具成功运行后，你将会在新目录 my-website/ 下看到下列文件：

my-website
├── blog
│   ├── 2019-05-28-hola.md
│   ├── 2019-05-29-hello-world.md
│   └── 2020-05-30-welcome.md
├── docs
│   ├── doc1.md
│   ├── doc2.md
│   ├── doc3.md
│   └── mdx.md
├── src
│   ├── css
│   │   └── custom.css
│   └── pages
│       ├── styles.module.css
│       └── index.js
├── static
│   └── img
├── docusaurus.config.js
├── package.json
├── README.md
├── sidebars.js
└── yarn.lock

• /blog/：包含博客的 Markdown 文件。

• /docs/：包含文档的 Markdown 文件。

• /src/：如页面或自定义 React 组件一类的非文档文件。

  • /src/pages - 所有放在此目录中的 JSX/TSX/MDX 文件都会被转换成网站页面。

• /static/ - 静态目录。

• /docusaurus.config.js - 站点配置文件。

• /package.json - Docusaurus 网站是一个 React 应用。 你可以安装并使用任何 npm 包。

• /sidebars.js - 由文档使用，用于指定侧边栏中的文档顺序。

运行网站​

cd my-website
npm run start

默认情况下，浏览器会自动打开 http://localhost:3000 的新窗口。

项目构建​

npm run build

网站内容会被生成在 /build 目录中，随后可以被上传到 GitHub Pages、Vercel、Netlify 等静态网页托管服务。

配置​

配置文件为项目目录下 docusaurus.config.js，配置字段官方文档：点击打开。

一定要参考官方文档，因为项目组贡献者有一位厉害的中国大学生，所以中文文档更新很及时。

设置中文​

docusaurus.config.js 中找到 i18n 配置节点，如下是原配置（其实看得懂英文就知道咋改 🤣）：

// Even if you don't use internalization, you can use this field to set useful
// metadata like html lang. For example, if your site is Chinese, you may want
// to replace "en" with "zh-Hans".
i18n: {
  defaultLocale: 'en',
  locales: ['en'],
},

修改为如下配置设置为中文：

i18n: {
  defaultLocale: "zh-Hans",
  locales: ["zh-Hans"],
},

搜索​

在使用官方插件中 Algolia DocSearch 搜索时候，会有几率踩坑，可以参考我的部署经验。

1. 正确启用 sitemap 插件，参考文档：sitemap 插件。
2. 正确启用 Algolia DocSearch 插件，参考文档：Algolia DocSearch 插件。
3. 构建项目，确认插件是否显示。

注册账号​

在 Algolia官网 注册账号后，打开控制台新建数据源，填写数据名（后面会用到），并选择免费计划。

获取 API keys​

控制台打开设置页面，点击 API keys，拷贝 Application ID、Search-Only API Key、Admin API Key。

配置 docusaurus​

打开项目配置文件 docusaurus.config.js，填写如下配置：

module.exports = {
  // ...
  themeConfig: {
    // ...
	algolia: {
		apiKey: "Search-Only API Key",
		appId: "Application ID",
		indexName: "数据源名称",
	},
  }
}

推送数据​

由于 Algolia 限制开源项目才可以免费试用爬虫，所以我们要自己推送数据。需要如下环境：

• Docker（谷歌一堆安装教程）
• jq（使用包管理器直接安装）

环境安装好以后，按照如下步骤操作：

1. 新建 .env 文件（键值不带双引号）

APPLICATION_ID=Application ID
API_KEY=Admin API Key

2. 新建 docsearch.json（爬虫配置文件）

{
  "index_name": "wiki",
  "start_urls": [
    "https://wiki.7wate.com/"					# wiki 网址
  ],
  "sitemap_urls": [
    "https://wiki.7wate.com/sitemap.xml"		# sitemap.xml 地址
  ],
  "stop_urls": [
    "/search",
    "/v3me",
    "/playground",
    "/inspector"
  ],
  "sitemap_alternate_links": true,
  "selectors": {
    "lvl0": {
      "selector": "(//ul[contains(@class,'menu__list')]//a[contains(@class, 'menu__link menu__link--sublist menu__link--active')]/text() | //nav[contains(@class, 'navbar')]//a[contains(@class, 'navbar__link--active')]/text())[last()]",
      "type": "xpath",
      "global": true,
      "default_value": "Documentation"
    },
    "lvl1": "header h1",
    "lvl2": "article h2",
    "lvl3": "article h3",
    "lvl4": "article h4",
    "lvl5": "article h5, article td:first-child",
    "lvl6": "article h6",
    "text": "article p, article li, article td:last-child"
  },
  "strip_chars": " .,;:#",
  "custom_settings": {
    "separatorsToIndex": "_",
    "attributesForFaceting": [
      "language",
      "version",
      "type",
      "docusaurus_tag"
    ],
    "attributesToRetrieve": [
      "hierarchy",
      "content",
      "anchor",
      "url",
      "url_without_anchor",
      "type"
    ]
  },
  "js_render": true,
  "nb_hits": 856
}

3. 运行 Docker

docker run -it --env-file=.env -e "CONFIG=$(cat docsearch.json | jq -r tostring)" algolia/docsearch-scraper

如果数据抓取异常，推送到 algolia 的索引条目过少。可以尝试多次运行 Docker，即可解决。至于为什么我也不知道，反正就能搞定 ~

总结​

如果想要稳定运行项目，请务必一定仔细阅读官方文档。官方文档维护的相当好，主要就是 algolia 搜索哪里，刚开始很容易无从下手……

更多优秀 Docusaurus 站点请访问：展示站点

这个问题让我想起可口可乐曾经的首席执行官布莱恩·戴森 (Brian Dyson) 在 1996 年乔治亚理工学院的毕业致词：

想像人生是一场在空中不停抛接五个球的游戏，这五个球分别是工作、家庭、健康、朋友以及心灵，而你不能让任何一个球落地。 你很快会发现，工作是一个橡皮球，如果它掉下来，会弹回去，而其他四个球是玻璃做的，如果失手，它们有无法挽回的刻痕、损坏，甚至破碎，将不再和以前一样。

想想自己如果要表演杂技，抛接五个球，还真是有一点难度。这不禁让人觉得，平衡人生的这 5 件事情是一件多难的事情，但可恶的是，那些成功者往往做的都很好。

就比如说扎克伯格，作为 Facebook 的 CEO，工作虽然忙碌，但依然坚持跑步、旅行、陪伴家人，一样也没有落下。又比如 Facebook 的 COO 雪柔‧桑德伯格（Sheryl Sandberg），在她的 《Lean In: Women, Work, and the Will to Lead》 这本书中，更是对工作和生活的平衡，分享了诸多理念和技巧。

你说他们真的做到了吗？具体我也不知道，但就算抛掉工作上的成就而言，各方面的表现也比我们强太多了。

但成功人士终究是成功人士，就比如很多问题都可以用钱来解决：家务可以找保姆解决，而我舍不得花钱，只能自己收拾家，三餐可以找专人做，而我自己做费时间，点外卖感觉又不健康，出行有专车司机，而我出行因为打不起专车，只能挤地铁，健身有顶级的教练指导，而我还在犹豫办不办卡，买不买私教课……

这样一想，虽然大家的时间是一样多，但无论是能用在事情上的时间还是完成事情的效率，其实都远不如他们。同样的事情对于他们来说是 normal 模式，对我可能就是 hard 模式，这多少会减弱一点参考性。

而从我这样一个普通人的角度来看，工作和生活平衡，与其说是一种愿景，不如说是一个谎言。

首先绝大部分的人想象的“平衡”，是将每天的事情完全掌控，无论是工作中的任务，还是生活中的事情，全都能装下，一个都不落下。但是人的时间呢，就那么多，每天 24 小时，这边增加了，那边必然减少，而如果某件事情完不成，就开始有负罪感，完美主义在心中作祟。

这种想法的本质是期望用一套框架装下所有的事情，这显然是对于人生难度的低估，同时也是对自己的过分高估，终究会被现实教育。

为什么我们要追求平衡呢？想一想，我们之所以追求平衡，是因为我们的当下并不平衡，但其实从人生的维度来看，我们的当下就不会是平衡的。

在《你的幸福曲线》这本书中，讲到了一个人生幸福曲线，通过对收入、性别、教育、工作、婚姻、健康等进行调整后，也就是过滤掉其他对生活满意度的影响因素，年龄和生活满意度的关系看起来如图：

你可以发现，人生的幸福度和年龄的关系遵循微笑曲线，从年轻时的积极乐观到中年的长期低迷再到退休后幸福感逐渐回升，我想说的是，尽管个体的差异是有的，但就对我们而言，我们在这个年龄段，就是会处在一个倾向于“失衡”的状态中。有太多的事情要做，有太多的责任需要肩负，事情汹涌而来，而你的能力又有限，痛苦是一种必然状态。

但是引用这个调查不是让大家放弃抗争，而是很多事情，你只有在接受后才会有重新出发的勇气，才会在面对失败的时候多一份淡然，才会在认清生活真相的时候依然热爱生活。

说回工作与生活，我们很多时候会刻意的将工作和生活分开，建立明确的界限，之所以这样做，很可能是因为在我们看来，工作和生活就是对立的事情。有的人觉得工作是痛苦的，只有放松享乐和陪伴家人是快乐的，由此引申开来，工作是一种必须要承受的痛苦，就是说，工作是一种累赘，我只有尽快的完成它，才能享受我的人生。

这种说法是否对自己有益呢，这其实要看很多情况。不过我想先聊聊工作这件事情，什么是“工作”呢？

最一开始肯定没有工作这种东西，更没有上班这种说法，只是到了工业时代，为了更高的生产效率，为了方便管理，才使拿工资的人必须每天去固定一个地点干活。

那我们可以不工作吗？这主要是因为我们生活在一个高度分工的社会，我们需要工作，付出劳动力和时间，来换取我们生活所需的物质资料。所以你看，“工作”并不是人类的天性，它的本质是双向交换，人类个体付出时间和劳动，换取物质资料、精神愉悦（比如各种享乐的活动）。

单从这个角度来思考的话，那得出来的结论很可能就是，我们工作就是为了享受工作换取的片刻欢愉。如果你能接受这样的现实倒也很好，但这样的结论有一个让人难过的点就是，它否认了我们工作的意义，它认为工作是带来不了精神愉悦的，这就很因人而异了。

我们一天 24 小时，有至少 1/3 的时间都在工作，而我又把工作当成“累赘”，这无疑加速了自己的精神内耗。工作的时候，感觉很累很累，然后产生看似本能性的反感和排斥，生活开始变得煎熬起来。

这就是为什么要强调工作一定要找到它有意义的地方，这听起来有一种资本家的语气，但这样做不是为了别人，恰恰的是为了自己。每天三分之一的时间都在痛苦中度过，亦或者是在无聊中煎熬，谁又愿意过这样的生活呢，所以我们能做的也就是从自己的工作中找到一点意义感了。

然而大部分的人对此是绝望的，因为很多人认为绝大多数的工作其实不是自我能力的提升，而是剩余价值的压榨。这样的概述对于总体也许是成立的，但对于个体来说，却仿佛在说着，你，改变不了自己的命运。

所幸，我的读者基本都是前端，大部分在互联网公司工作，哪有那么多的稳定性，在各个城市漂泊的同时，也多了一份选择的自由。只是希望大家能够找到自己喜欢的、有价值感的工作，并能因此有所成长。你可以为了一时的成长忍耐暂时的薪水，你可以为日后进大厂蛰伏在一家小公司，这都没有什么关系，尼采说，人如果知道自己为什么而活，什么样的生活都可以忍耐。

我想说的是，当你感觉这份工作带来的更多是精神的内耗时，你应该勇敢的选择换一个环境了。很多人面对这种内耗，依然蜷缩在自己的舒适区里，一边为自己的不离开找借口，一边叹息于自己的工作毫无意义。畏手畏脚，在看似两难的选择中犹豫不前，拖延决定，备受煎熬。你的内心毫无疑问的知道正确的选择，只是正确的路往往 too damn hard。

考虑到我的读者各种年龄段都有，这里多说一点，那就是我会更建议，刚毕业的同学，不要去考虑什么平衡，你就应该投入所有的精力在工作上，做一个工作狂也比一个躺平咸鱼好。

人生是不均衡的，初中的你一天可以毫无顾忌的投入学习，但成家后的你的一天都充满了生活琐事，你以为这是可用的时间亦或者体力精力上的差距吗? 不止如此，我觉得最重要的就是，工作、成家后的精神内耗要远比上学时强烈的多，而且年轻的时候做错了就当试错，但成家后，你会发现时间就那么点，你就只能更谨慎的将时间花在刀刃上，这是一件好事情，但也会带来部分人的选择困难，反而浪费了更多的时间。

再者，我觉得刚毕业的时候是自由的，上学的时候你所学习的内容很多是你被迫学习的内容，但是毕业后，你可以自由选择学习的内容，没有比现在更有兴趣的时候了。

还有就是，二八定律，人生的回报 80% 的回报来自于你 20% 的努力，你越早努力，在时间的加成下，你就会越多的享受到好处。想一想，很多人不就是因为高中的努力，一直吃到现在吗？高中努力了，上了个好大学，于是在面试的时候凭借学校刷掉了一大堆对手，因此去了好公司，又凭借着第一家好公司，跳槽到了第二家更好的公司吗。写博客也是这样，你越早写，你前期积攒的影响力会带来更多的影响力。所以没有什么比这更好的时间了，你就该投入其中，你只用拼那么一两年，其实你就可以吃很多年的老本了，你就已经赚了。

你把时间花在哪里，最后的收获就在哪里，这种牺牲一种的做法也只有在特殊的时候才会起到很好的作用。这种选择虽然可以有效的降低心智成本，不纠结，但也不是维持之道。

说完工作，我们说说生活，我觉得很多年轻人是没有“生活”这个概念的，大部分人理解的生活是事务性的工作，比如洗脸、刷牙、洗澡、做饭、洗碗、打扫卫生、上班、开车，或者就是躺平活动，比如刷动漫、看电视、打游戏、去网吧、短视频等等。

个人选择是一部分，社会压力也是一部分。对年轻时的我们而言，就是能力低，工资低。能力低导致加班，工资低导致租房远，交通成本高，两边都在积压我们的时间，工作的疲惫，通勤的疲惫，我们已然没有精力去享受所谓的下班后的生活，到了家，就变成了葛优躺，我知道我要学习，我知道我要奋斗，但是有了空闲时间，我就只想用在奶头乐上。

这种问题是很多人的常态，破解之道就是保持学习，不早一点掌握工作上的专业技能，平衡工作和生活说起来就是镜花水月。

但是关于生活，我倒不是想说这个，事务性的内容很枯燥无聊，只能说尽力减轻工作量，躺平活动很有意思，但引用《心流》的说法，它只能帮助我们恢复我们的内在秩序，却无助于创造新的秩序。就像饿了吃饭一样，它帮助我们恢复了身体平衡，但却不能帮助我们变得更好。我们如果要做到“生活”，必不可少的，就是爱好，换句话说，生活，你要做些有意思的事情，它才是生活。

有一个休息法则就做莫法特休息法则，它认为一个人如果长时间持续同一项工作内容，就会感到疲惫，效率降低，所以我们可以适时切换为不同的工作类型。就比如我们每天工作写代码，消耗了大量的脑力，但是回到家，你却还想着继续学习，往往就因为过分的疲惫而坚持不下来。所以与其学习，不如选择偏体力的活动，比如打扫卫生、运动，或者偏感性的活动，如练琴、唱歌、绘画之类的。到了周末再进行学习。

所有有的时候，我们需要审视一下，自己每天干的事情。列一个清单，各自花费了多少时间，浪费了多少时间，有多少时间花在了自己感兴趣的事情上，无论多忙多累，都要抽点时间做点爱好而非享乐的事情。那种投入自己的注意力，全身心的沉浸在一件事情中，它带来的那种深沉的快乐，能给你的生活带来很多的振奋。

关于工作和生活讲了那么多，在我看来，我们追求工作与生活平衡的背后，其实还是为了总体的幸福，但幸福不来自于平衡本身，而是来自于工作与生活中的幸福。所以如果你只是追求平衡，却忽略了工作和生活的意义，这就是一种舍本逐末。

所以与其追求什么平衡，我想说的是，开心工作，快乐生活。尽管这句话很阿里味，但不得不承认，这其实就是该有的状态。

关于工作和生活，再提供一些其他的小建议：

1. 少喝咖啡

很多人对咖啡上瘾，据说开在阿里园区的第一家星巴克是全国营业额最高的星巴克店面，足以看出阿里同学对咖啡的喜爱程度。咖啡确实很不错，通过咖啡可以获得所谓的精神，但结果往往是需要的量越来越大，但能获得的精神却越来越少。

在我看来，咖啡是一种透支，只是把你未来的精力短暂的放到现在而已，但你的身体本身并没有得到休息，要是真的想调整精力，冥想和健身其实是更好的选择。

1. 提升专注力

很多人解决事情的方式是堆时间，所谓堆时间，把其他事情的时间都尽力挤压掉，留出大量的时间专门用于一件事情的完成，颇有一种牺牲一切没必要的事情只为一件事情完成的魄力，但真到具体做这件事情的时候，则会各种分神，找个借口休息一下，查点相关的资料结果越查越远，不自觉地拿起手机点开了微信消息，事情还没干多少，无论是内部打断，还是外部打断，都打断了几十回。这样的事情，即便完成了，享受过短暂的成就感之后，心理上依然感到十分疲惫。

所以对于这种较大时间块，一定要明确的划分出做事和休息的时间，否则就会自己主动陷入 996 的陷阱之中。 而做具体的活动之时，可以采用比如番茄工作法。

关于番茄工作法也多说一句，这个名字想必大家都听过很多遍，本身并不复杂，但是，也没有大家了解的那么简单，什么“每工作 25 分钟，然后休息 5 分钟，第 4 个休息的时候，休息 30 分钟”，那这其中，为什么番茄工作法很有效，背后的原理是什么？对于干扰的情况如何处理？每天结束时统计和处理哪些内容？对于这些问题，大家可能都没有了解过，更多的是看一两篇二手的文章大致的了解了下。

关于番茄工作法具体包含哪些内容，我在这里也不多说，我只想说，要学习这个番茄工作法，不用去看什么二手的文章，都是别人总结过的，少了点意思，直接看原书，微信读书搜《番茄工作法》免费阅读，这是番茄工作法的作者写的，还有一本《番茄工作法图解》，也很不错，番茄工作法的作者作的序，微信读书上也是免费阅读，看完这两本书，加起来都不超过 5 个小时，但是你却可以对番茄工作法，这个非常经典的方法有更加全面深刻的了解。

作为一个备受很多人推崇的方法，大家都是傻瓜的可能性是比较小的，更大的可能性是自己傻瓜，所以失败过的同学也要多看看，最少坚持两周试一试。

1. 断舍离

我认为“断舍离”这个概念涵盖的内容非常的多。我们生活充满了各种无用的物品，这些物品的存在不能给我们带来幸福感，只会让我们越发无力去收拾。

我们的想法中充满了太多没用的情绪，担心、多虑、徘徊、怀疑、恐惧、受伤，挣扎、固守、困惑、焦虑、低落、愤愤不平、自卑自贱、牢骚、抱怨、呻吟、挑剔、吹毛求疵，往往外界什么事情还没有发生，我们的内心已经无数种情绪翻江倒海，汹涌而来。

我们日常要做的事情也是不断地趋向于更多，即便今天看似完美的度过了，明天后天也只会加入更多的事情，不断地做加法，但却不肯收手放自己一马，最终让自己疲惫不堪。

所以日常生活中，在你察觉到负面情绪的时候，及时的反思背后导致的原因，当断不断，反受其乱，但也不用一直的断，加加减减，才是人生的常态。

原作者：冴羽答 - 读者问：怎么平衡工作与生活

文章地址：https://github.com/mqyqingfeng/Blog/issues/298

文章采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行许可。

最近 Jetbrains 的授权又到期了，之前有些写过相关的文章。但是那时候没有加入到相关的博客订阅，阅读量也不大。现在有一定的阅读量了，便想再次分享给大家如何免费获得个人正版授权。

关于授权模式​

Jetbrains 主要面对用户为个人和组织，官方其实对于个人授权还是比较暧昧的，主要收入还是靠组织。

在此可以很明确的告诉各位，如果你所在组织使用 Jetbrains 系列工具做开发，但 Jetbrains 授权并不是组织为你购买支付并授权的，而是通过其他渠道（包括个人购买等等）授权的，都可以理解为非法授权用户。

不过国内版权意识，原谅我多 BB 了。今天最核心的事情还是免费哈哈哈

准备工作​

官方提供了很多特惠方式，在此我只阐述门槛最低的一种方式——开源项目。

官方的条件要求是：

• 了解开源定义。
• 正在积极开发，例如，在过去 3 个月内定期提交新代码。
• 不提供开源软件的付费版本，也不提供与开源项目相关的任何商业服务（例如付费支持、咨询等）。
• 未获得商业公司或组织（NGO、教育、研究或政府组织）的资助。
• 不为他们的核心项目开发者支付工资。

对于白嫖最重要的事情其实只有在过去 3 个月内定期提交新代码，项目拥有开源协议。

我多次的经验发现，可以很明确的告知各位。Jetbrains 并不注重你的开源质量和影响力，只要你满足上述加重字体的条件，放心大胆的申请即可。

你在这可能有疑问了，还要等三个月嘛。你的小脑袋瓜那么聪明，我相信你可以时光逆流嘿嘿。

申请表单​

1. 注册 Jetbrains 官方账户
2. 符合要求的开源项目
3. 打开申请网址填写表单
4. 等待邮件授权激活

如果超过七天未收到授权邮件，可以邮件联系官方，由于时差原因，所以不要着急。（官方不会磨磨唧唧，一般直接就给了）

授权书​

官方授权的仪式感满满的 ~

有什么疑问可以下方留言为各位解答 ~

折腾了好久网站了，也折腾了好久的服务器了。网络拓扑图也不想画了，总之就是弃繁就简了，一切以使用、需求为出发点。

网站​

Bitwarden​

开源的密码管理器，平时自己的密码全都放在这个上面了。

密码提示，密码填充等等。密码安全性也提高了，总之就是真香 ~

Docusaurus​

开源知识维基，用来系统化、结构化归纳自己知识。基于自建 Gitea 服务，腾讯云 web 托管。平时记录完笔记就自动推送 Gitee（国内）和 GitHub（国外）了，界面好看，也挺好用的，暂且打个 8 分把。

Gitea​

版本控制器，私有化的 GitHub，不过没有 GitHub 支持的功能丰富。搭建的原因主要就是放在第三方平台，莫名的没有安全感……

LskyPro​

图床图床，更规范的管理图片了。图片也不怕丢了，总之很好用。自建博客不推荐博客自带的附件管理，不具有可移植性。

Nextcloud​

网盘，私有化百度云。主要还是备份同步以及放一些私人资料，横向拓展比较丰富，不只是单单的网盘。邮箱、订阅、日历、看板等等，及其推荐私人开发者搭建一个。这个也是真香 🤪

RSSHub​

主要信息获取渠道，不喜欢被动的接受信息。碎片化信息太多，网文也太多。我觉得现在杂志也挺香的，不过就是要花钱。一般推荐，官方提供的也够用。

总结​

感觉越来越懒了，特别是服务器这块。不想再折腾了，也不能再单纯的靠爱发电了。能自动化就自动化，能少点一下就少点一下……

统一团队的 Git 工作流，包括分支工作流、Git commit 日志、tag 规范、README 模板、issue 模板，便于后续代码 review，版本发布以及日志自动化生成等等。

分支工作流​

根据项目实际情况安排分支工作流！

Commit 日志​

日志所有内容务必使用 ASCII 字符，不要使用中文或 emoji，要求最大化兼容，便于程序处理。

commit 包括三个部分：Header、Body、Footer。

commit 格式如下：

<type>([scope]): <subject>

[body]

[footer]

示例：

feature(auth): increase length of new API key

the length is increased from 24 to 32 for new API keys

close #12

头部（Header）​

标题部分只有一行，包括三个字段：类型、说明、标题。

• 破坏兼容性的改动，影响到依赖本项目的其它系统，请在类型后面加上半角感叹号「!」。
• 标题务必不超过 72 个字符，务必精炼易懂。如无法限制在 72 个字符内，请拆分提交。
• 描写部分小写字母开头、专有名词首字母大写、缩略语大写、结尾不用句号。

主体（Body）​

标题与正文间隔一个空行。

如果内容简单，请按照标题格式。超过一行，按照常规的段落格式。

首字母大写，正确使用标点。可以多行、多段、每行不超过 72 个字符、行尾不出现空格、段落用空行隔开。

示例

feature!(api): limit array length to 256 elements

BREAKING: Array length limit is added to further limit request size. A
small number of existing apps may receive HTTP 413 "Payload too Large"
error.

脚注（Footer）​

正文与脚注间隔一个空行。

Tag 规范​

Issue 模板​

README 模板​

作为宇宙第二 IDE：Jetbrains，业内很多 ITer 肯定都了解一二。不过相对于宇宙第一 VS，Jetbrains 严格的正版授权和高昂的售价，让很多人望而却步。不过也肯定有不少细心的小伙伴发现了，如果你拥有一个开源项目便可以申请 Jetbrains 正版的授权！已经申请成功的我来分享一下过程！

很多使用 Jetbrains 系类产品的小伙伴肯定知道学生和老师是可以通过 .edu 邮箱免费获得授权，不过很多小伙伴毕业了才发现，更是悔恨相见恨晚。但 Jetbrains 提供了很多优惠，其中一项便是开源项目授权。

申请条件​

申请过程​

1.填写项目具体信息​

这里需要注意是：

• 第一项：是否已经有关于此项目的授权，如果你一年的授权到期了，项目也正常工作，就可以输入上一年的授权 ID 申请继续授权。
• 第二项：授权数目，根据仓库贡献人数填写。
• 第三项：填写的邮箱一定是项目拥有者邮箱，而且如果使用的 github 必须公开此邮箱。

2.申请反馈​

正确填写申请成功以后，我们便可以静静等待一至两周了。

没错，幸福的事情都是需要等待的！

申请结果​

在我申请的过程中出现了一个小插曲，我是 2 月 14 日申请的，直至 2 月 24 日都没有收到反馈结果。我便向 [email protected] 询问了是否收到申请，不久便答复了我。随后授权也一并下来了，很开心。

授权证书​

开源的精神永远是被值得尊敬，心存向往之心的！

估计很多看到这的小伙伴该有疑问了，开源项目？三个月？持续贡献？这容易申请么，别辛辛苦苦三个月 push 再申请失败了。

如果可以，你去我的 github 个人主页查看 Index 仓库。它不过也只是一个简单的不能再简单的静态 H5 网站，但是我也一直在不停的贡献。

记住，梦想是不分大小的，每个拥有梦想的小伙伴也都是值得尊敬的！

不过申请成功的小伙伴谨记，**此授权是不可以用在商业项目上的！**所以拿到公司用是不可以的，不过通过自己努力得到的正版授权一定别有一番意义！