《10x 程序员工作法》笔记

1.本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity）

本质复杂度：指解决问题时，无论采用何种方案都无法规避的核心固有工作量，是问题本身自带的底层复杂度。

偶然复杂度：因方案选型不合理、流程不规范、工具落后等人为因素额外产生的冗余工作量，属于可优化、可消除的非必要复杂度。

软件开发想要稳步推进、高效落地，核心关键就是选对设计思路与研发模式，最大限度削减偶然复杂度，聚焦解决业务本质问题。

核心思考框架

1. 梳理现状：客观盘点当前问题、现存瓶颈与现有资源
2. 明确目标：锚定最终交付结果与核心价值，拒绝模糊诉求
3. 规划路径：拆解步骤、制定方案，搭建从现状到目标的落地链路

落地执行原则

1. 以终为始

   跳出单一任务指令，聚焦业务核心目标与最终价值，不将表层任务当作最终目的，避免无效劳作。

2. 合理任务分解

   将宏大目标逐层拆解为轻量化、可落地、可验收的细分任务。拆解越精细，进度可控性越强，风险越容易提前预判。

3. 高效沟通反馈

   双向同步信息：精准传递需求与进度，规避理解偏差引发的返工；主动接收外部反馈与优化建议，避免闭门造车、固步自封。

4. 流程自动化

   标准化、重复性、低价值的繁琐工作，通过工具、脚本、流水线自动化落地，解放人力，聚焦核心研发工作。

2. DoD（Definition of Done，完成的定义）

DoD，即完成的定义，用来清晰界定一件事做到什么程度才算真正收尾，统一团队认知，减少因理解偏差导致的返工、内耗与无效浪费。

核心理念：凡事先行定义完成标准，再动手执行。

1. DoD 是一份检查清单，由多条检查项组成

用一条条明确条目约束工作，告别 “凭感觉、看经验” 判断进度。

举例：

一个接口开发任务，检查项可以是：

• 接口代码已编写完成

• 入参、出参规则已按需求实现

• 异常场景已做兼容处理

  依靠清单逐项核对，不漏项、不遗漏。

2. DoD 的检查项必须实际可检查、可验证

拒绝模糊化描述，每一条标准都能客观判定 “合格 / 不合格”。

反例（不可检查）：

代码写得没问题、功能大致能用。

正例（可检查）：

• 所有接口请求响应耗时控制在 200ms 以内
• 不存在崩溃、报错、白屏等线上问题
• 核心流程连续测试 20 次无异常

3. DoD 是团队协作的汇报机制，工作只有两种状态：做完 / 没做完

杜绝「差不多好了、快完成了、基本没问题」这类模糊状态。

举例：

没有 DoD 时：

开发说功能写完了，测试介入后发现缺逻辑、缺边界处理，反复返工。

有 DoD 时：

不满足全部检查项，一律判定为未完成，不流转下一环节，从源头减少跨环节返工。

4. DoD 是一种思维模式，用来消除不确定性、达成团队共识

它不只是一张表单，更是提前对齐预期的工作思维。

举例：

需求迭代前期，产品、开发、测试一起约定 DoD：包含功能、性能、文档、自测、评审等要求。

所有人提前明确验收底线，不会出现「我以为要做」「你觉得不用做」的认知分歧，大幅降低协作中的偶然复杂度。

3. 扩大工作上下文

1. 核心认知：角色差异的本质是上下文差异

在软件开发协作中，不同角色的工作核心差异，本质是上下文的不同：产品关注业务价值，测试关注质量底线，开发关注技术实现。每个角色都有自身的工作边界和思考维度，这直接决定了看待问题的视角。

关键结论：单一局部上下文里难以破解的难题，跳出固有边界、切换到更广阔的上下文，甚至可能无需刻意解决，这就是“跳出局部看全局”的意义。

2.局部优化≠全局最优，上下文缺失易做“无用功”

若始终局限于自身角色边界，即便在单个环节付出再多努力，也只是“局部优化”，很难实现整体工作的最优效果，更无法从根源上减少前文提到的“偶然复杂度”。

举例：只专注于优化某段代码的执行效率，却忽略其对应的业务场景是否合理、是否有更简洁的业务逻辑可替代，最终努力可能沦为“无用功”，甚至增加后续维护成本。

3.程序员的常见盲区：过度依赖技术，忽略上下文

技术是程序员的“利刃”，但并非所有问题都需要用技术解决。“手里有了锤子，眼里都是钉子”，正是很多程序员的盲区——过度依赖技术思维，会下意识用技术应对所有问题，甚至花费大量精力解决“根本不是问题”的问题。

盲区根源：上下文缺失，始终站在“程序员”单一维度看问题，未跳出角色了解业务全貌、项目目标和其他角色需求。

4.打破盲区的关键：主动扩大工作上下文

破解盲区的核心，是跳出程序员角色思维，主动扩大工作上下文：多问几个“为什么”（为什么做这个需求？核心诉求是什么？有无非技术解决方案？），多与产品、测试、运营等角色沟通，探讨更高效的做法，很多困惑会迎刃而解。

5.扩大上下文的具体方式：了解软件开发全生命周期

对程序员而言，扩大上下文最直接的方式，是主动熟悉软件开发全流程：从需求调研、产品设计、技术选型，到编码开发、测试验收、部署上线，再到运维迭代、问题排查。

核心改变：不再只看到“编码”这一个孤立的点，而是看到完整的工作链路；思考重心从“写好代码”转向“让代码更好地服务业务、提升整体效率”。

6.扩大上下文的核心价值：拥有“降维攻击”的视角

扩大上下文后，与他人讨论问题时会更有底气、视角更全面，相比只局限于单点思考的人，相当于拥有“降维攻击”的能力。

关键体现：站在项目整体目标、业务长期价值等更高维度思考，会发现很多低维度、单一环节难以解决的难题，在广阔上下文里根本不是问题。

7.实例佐证

程序员接到“开发用户数据统计报表”的需求：若局限于“开发”上下文，可能花费大量时间优化查询效率、美化页面；但扩大上下文后，与产品沟通得知报表仅用于临时业务复盘、使用频率极低，最优方案无需开发完整模块，只需通过SQL查询导出数据，用Excel整理即可满足需求，从根源减少了偶然复杂度。

4. 测试做好标准

做好软件测试，核心需遵循“前置准备、执行、断言、清理”四大核心流程，同时满足A-TRIP五大核心原则，二者结合可确保测试工作规范、高效、精准，从源头把控产品质量，减少因测试疏漏导致的返工与风险。

1.测试核心流程：前置准备→执行→断言→清理

测试工作的完整性，离不开四大流程的闭环推进，每一步都不可或缺，直接影响测试结果的准确性：

1. 前置准备：测试前的基础铺垫，包括明确测试范围、梳理测试用例、搭建测试环境、准备测试数据（含正常、异常、边界数据），同时对齐DoD验收标准，避免测试无方向、无依据。
2. 执行：按照测试用例逐步执行测试操作，全程记录操作步骤、出现的异常现象，确保操作可追溯，不遗漏任何一个测试场景，避免“凭经验测试”。
3. 断言：将测试执行结果与预期结果进行对比，明确判定“通过”或“不通过”，拒绝模糊判定；若出现异常，需精准定位问题、描述问题，为开发修复提供清晰依据。
4. 清理：测试结束后，清理测试环境中的测试数据、临时文件，恢复环境初始状态，避免残留数据影响后续测试执行，保证测试环境的洁净度与稳定性。

2.测试核心原则：A-TRIP

A-TRIP五大原则是测试工作的“质量标尺”，贯穿测试全流程，确保测试结果可靠、可复用、有价值，具体解析如下：

1. Automatic（自动化）：对于高频重复、标准化的测试场景（如回归测试、接口测试），优先采用自动化测试工具实现，减少人工操作成本，避免人工失误，同时提升测试效率，让测试人员聚焦于复杂场景的测试。 举例：接口回归测试，通过编写自动化脚本，每日自动执行所有接口测试用例，无需人工逐一对接，大幅节省时间。
2. Thorough（全面的）：测试需覆盖所有核心场景、边界场景、异常场景，不遗漏任何可能出现问题的点，兼顾功能、性能、兼容性等多维度，确保测试无死角。 举例：测试登录功能，需覆盖正确账号密码、错误账号、错误密码、空账号、空密码、特殊字符账号等所有场景，同时检查登录超时、多设备登录等边界情况。
3. Repeatable（可重复的）：测试过程可复现、测试结果可验证，无论谁执行、何时执行，只要按照相同的测试用例、测试环境操作，都能得到一致的测试结果，避免“一次性测试”无法追溯问题。 举例：某功能测试用例明确记录操作步骤、测试数据、预期结果，任何测试人员按照该用例执行，都能复现相同的测试结果，便于问题排查与回归验证。
4. Independent（独立的）：测试用例之间相互独立、互不影响，单个用例的执行结果不会干扰其他用例；同时测试环境独立于生产环境，避免测试操作影响生产数据与业务正常运行。 举例：测试“用户注册”与“用户登录”功能，两个用例分开设计、独立执行，即便注册功能测试失败，也不影响登录功能的正常测试；测试环境单独部署，不与生产环境共用数据库。
5. Professional（专业的）：测试人员需具备专业的测试知识、业务认知与问题分析能力，能够精准识别测试重点、设计合理的测试用例，同时规范记录测试报告，清晰反馈问题、给出优化建议，而非单纯“执行操作、记录结果”。 举例：测试过程中发现异常，不仅记录异常现象，还能初步判断问题可能出现的环节（如前端交互、后端接口、数据库），为开发修复提供专业参考；测试报告规范、清晰，包含测试范围、测试结果、问题明细、优化建议等内容。

5. T型人才

1.职业焦虑的根源：时代与认知的脱节

1. 核心焦虑来源：对未来的不确定性，这种不确定性是特定时代与特定行业共同作用的结果。
2. 时代对比：上世纪80年代前，人们虽生活条件有限，但人生路径清晰，很少有发展焦虑；如今身处快速发展时代，未来充满未知，而思维模式仍未摆脱上一代人“稳定至上”的认知，进一步加剧焦虑。

2.破解焦虑的关键：成为T型人才

T型人才核心定义：一专多能——“T”的一竖，是某一领域的深厚专业能力（专）；“T”的一横，是跨领域的广博知识与技能（能），二者结合可在多变时代站稳脚跟。

3.T型人才的核心逻辑：“专”是基础，“能”是延伸

1. 核心前提：有了“一专”，“多能”才具有真正价值；若无核心专业能力支撑，“多能”只是低水平重复，无法形成核心竞争力，这也是很多人职业生涯无起色的根本原因。
2. “专”的核心含义：绝非简单的“熟练操作”，而是深入底层的专业积淀——对技术原理的通透理解、对业务逻辑的精准把握、面对复杂问题的快速破局能力，而非表面熟练度。

4.“一专”为基，“多能”拓宽职业路径

当具备深厚技术功底、通晓软件开发核心逻辑与全流程后，拓展“多能”可摆脱单一角色局限，常见方向：

• 带领团队落地项目、协同推进工作，成长为技术领导者；
• 将技术理解系统化分享，帮助他人成长，成为技术培训师；
• 在实战中精准定位问题、提供解决方案，成为技术咨询师。

5.“多能”反哺“一专”，打破职业瓶颈

1. “多能”的价值：拓宽视野，帮助跳出单一技术视角，看清核心专业能力的应用场景，避免“手握技术就天下无敌”的狭隘认知。
2. 程序员的常见瓶颈：视野狭窄、缺乏大局观，只专注于代码编写，不了解业务价值、团队协作、行业趋势，最终停留在“技术工匠”层面，难以实现更高成长。

6. ThoughtWorks 技术雷达

1.技术雷达核心概况

1. 基本信息：ThoughtWorks 技术雷达 由 ThoughtWorks 技术咨询委员会（Technology Advisory Board）编写，每6个月发布一次，是一份聚焦技术趋势的专业报告。
2. 核心优势：得益于 ThoughtWorks 丰富的项目多样性，其能精准捕捉各类技术趋势，相比行业其他预测报告，技术雷达更具体、更具可操作性，可直接为项目实践提供参考。

2.技术雷达的四大生命周期阶段

技术雷达将技术、工具等划分为四个生命周期阶段，核心关注重点为“采用”和“暂缓”两项：

• 采用（Adopt）：建议重点考虑使用的技术/工具，经过实践验证，成熟度高、实用性强；
• 试验（Trial）：已具备使用条件，但成熟度不及“采用”阶段，可根据项目需求尝试应用；
• 评估（Assess）：需重点关注、深入研究，但暂不建议急于试验，除非与项目高度契合；
• 暂缓（Hold）：需谨慎推进，存在潜在风险，不建议盲目应用。

3.各阶段关注优先级建议

1. 核心关注项：“采用”和“暂缓”两项，从近年发展趋势来看，技术雷达在这两项上的推荐大部分较为靠谱，可作为技术选型、风险规避的重要参考。
2. 次要关注项：“试验”和“评估”两项，多属于新兴技术的试验区，核心作用是开拓视野，可在空闲时间逐步了解，无需急于落地应用。

4.补充

除技术雷达外，推荐关注 InfoQ，可获取更多技术趋势、实践案例等优质内容，助力拓宽技术视野、提升专业能力。

参考资料

10x程序员工作法