每隔一段时间内，我都会去尝试“重构”公司内的某一种模块代码。从“大任务拆分成小任务”，到“面向覆盖率编程”。有时是专门提一个任务，而有时是是在当前的任务中去修改一个让自己极度难受的模块。但是在几乎所有任务的最后，我只能在修复各种 bug 中，麻木且无奈地喊出一句：“还有谁（给我提 bug）！“。
错的不是我，是这个世界！这句话似乎是一个完全不负责的甩锅模式。但是很遗憾，我们越是陷入“只要我在一天，我就要捍卫者一切！”的思维模式，就越容易陷入“明明我做了那么多，为什么就是没啥效果”的失落与惆怅中。软件工程从来不是写代码这么简单，它还涉及到问题解决、需求分析、系统设计、测试和维护等方面。如果作为一个单一职能的个体，无法提供一个有效的解决方案。那么原因有且只有一个：团队有太多符合直觉但违不符合软件工程的反模式。
软件工程作为一个团队协作工程，涉及知识的产出与消费两个方面。知识产出指的是开发过程中产生的各种形式的知识，如设计文档、代码、测试用例等；而知识消费则指的是对这些知识的理解、使用和维护。
在软件开发中，知识产出的质量直接关系到软件的质量。Fred Brooks在《人月神话》中提到：“C ...
在上一讲中，我们讲到一个用户故事：“当用户是工作区管理员时，用户可以邀请别人”，现在我们新增一个用户故事“当用户时工作区成员时，用户可以退出当前工作区”。我们更新一下业务模型：
12345678910111213141516171819202122232425@startumlclass User <<Entity>> { +String id +Workspace currentWorkspace +isWorkspaceCreator(): boolean +invite(): void +isWorkspaceMember(): boolean +exitWorkspace(): void}class Workspace <<Entity>> { +String id +String name +WorkspaceAuth auth}enum WorkspaceAuth <<Value Object>> { ...
给 AI 添加角色在互联网的宣传下，很多人对人工智能（AI）抱有很高的期望，认为它无所不能，能够帮助我们“做对”各种事情。然而，实际情况往往让人失望，AI 并没有那么“聪明”，它更像是一个具有语言交互能力的“数据仓库”。我们可以把 AI 想象成一个巨大的图书馆，里面存放着各种各样的信息。当我们需要查询某个信息时，首先要确定这个信息在哪一本书（数据表）里，然后通过特定的查询语言（SQL 语句）来找到我们需要的内容。
在使用 AI 的过程中，确定“数据表”的过程其实就是给 AI 定义一个角色。一旦我们明确了 AI 的角色，它就会基于这个角色相关的“数据仓库”，提供与我们需求相关的信息。比如，如果你需要 AI 帮助你在一个项目中添加某个功能，你可以告诉 AI：“你是一个资深的后台开发，请帮我在这个项目中添加某个功能。” 这样，AI 就会基于它所“知道”的后台开发知识，提供相关的建议和代码。
这样做的一个重要原因是：AI 的“记忆力”是有限的，如果上下文太长，它可能会“记不住”或者“理解错”。另外，我们使用 AI 是为了更快地获取我们需要的信息，如果 AI 返回一大堆无关的内容，对我们来说也没 ...
列表请求应该放在哪当用户登陆系统后，有一个最直接的需求：“作为一个用户，我可以获取到所有的应用的任务列表，以此快速查询到我想要的任务数据。” 大概功能入下图所示。现在，我们基于用户故事更新一下业务模型
123456789101112131415classDiagram class User { +id: int +name: string +email: string +workspace: Workspace } class Workspace { +id: int } class Task { +id: int } User "1" -- "*" Workspace User "1" -- "*" Task
我们可以看到，用户和任务之间也是是一对多的关系，我们的现实场景下，代码设计大概如下。如果移动端用户有同样的需求， ...
列表请求应该放在哪当用户登陆系统后，有一个最直接的需求：“作为一个用户，我可以获取到所有的应用的任务列表，以此快速查询到我想要的任务数据。” 大概功能入下图所示。现在，我们基于用户故事更新一下业务模型
123456789101112131415classDiagram class User { +id: int +name: string +email: string +workspace: Workspace } class Workspace { +id: int } class Task { +id: int } User "1" -- "*" Workspace User "1" -- "*" Task
我们可以看到，用户和任务之间也是是一对多的关系，我们的现实场景下，代码设计大概如下。如果移动端用户有同样的需求， ...
在上一篇我们分享了几种常见的反模式，其实都不是什么技术问题。不管是用充血模型表达业务，还是通过 TDD 的方式去编写代码，更多的是一种技巧，就像英语一样，需要我们不断反复地去练习，才能掌握。而 TDD 的学习难点理解需求，并将需求分解为功能点。这就陷入了一种死循环，上一篇的各种反模式积累出来的问题，导致我们无法正确理解已有的需求，而我们又必须基于对已经存在的需求的正确理解上，才能合理地分解业务。虽然按照 TDD 的模式开发各种工具对个人来说是一种很好地学习方式，但是却难以向团队传递 TDD 带来的诸多好处。
我的切入点是：
通过对遗留系统的改造，建立一个新系统。
在可读性较高的新系统中，去建立 TDD 的练习场。
向钱看齐很多时候，我们所谓地对遗留系统的处理，往往是一种伪装成“重构”的重写，在一次性大量代码变更下，带来诸多 breakchange。至于为什么要重构，可能是性能过低，可能是代码过长，也有可能是单纯地某一个员工代码写烦了以重构为名申请了个任务罢了。最终的表现就是，明明花了大量时间在对代码的处理上，但不管是 bug 数量，还是未来新增逻辑的效率，都没有什么提升。
你的分层 ...
大家好，我叫钟杰，是个做了 4 年的前端工程师，我所在的公司是做低代码的，低代码行业基本都在尝试引入 AI 智能体，通过训练存量客户所搭建的应用数据，来帮助后续客户快速上手产品。大概流程就是：提出类似于“我要搭建一个生鲜市场的出入库管理系统”，之后系统会创建好一个相对完整的表单应用。然后客户在半成品上基于自己的需求，去进行调整。
在 ai 工具出现以前，客户搭建自己的应用是通过内置模板 + 帮助文档，在和公司客户成功团队的帮助下，基于自己的需求，搭建匹配业务的应用，这也是大部分 SAAS 和 低代码工具的运营模式。企业希望通过 AI 工具的引入，借此降低公司客户成功团队和客户之间的沟通时间于成本。从而服务于更多的客户来赚取更多的利润。也许是因为近两年对于各类 AI 的营销，都是以降本增效为卖点，再加上公司的盈利能力在不断下降，公司将 AI 看作了提升人效比的银弹，企图通过粗暴地替代某一个环节，来降低整体的成本。
引入工具但不引入标准对于工具或者某一项技术的盲目崇拜，其实在 ai 工具出现以前，就已经大量存在了。比如
“死文档式”记录：引入敏捷开发的站会、看板，却不构造通用语言，依旧 ...
你在一家做低代码的公司做了，做了几年基层前端开发。随着 AI 浪潮的加剧，低代码行业基本都在尝试引入 AI 智能体，通过训练存量客户所搭建的应用数据，来帮助后续客户快速上手产品。大概流程就是：提出类似于“我要搭建一个生鲜市场的出入库管理系统”，之后系统会创建好一个相对完整的表单应用。然后客户在半成品上基于自己的需求，去进行调整。
在 ai 工具出现以前，客户搭建自己的应用是通过内置模板 + 帮助文档，在和公司客户成功团队的帮助下，基于自己的需求，搭建匹配业务的应用，这也是大部分 SAAS 和 低代码工具的运营模式。企业希望通过 AI 工具的引入，借此降低公司客户成功团队和客户之间的沟通时间于成本。从而服务于更多的客户来赚取更多的利润。
但是你发现，这是一个很糟糕的思考模式，因为它是在假定 AI 有能力解决客户的问题，而 AI 本身只是一个概率模型，它产生的结果只能以相关度，而非准确度。可以说是，把 AI 当成了提升人效比的银弹。
引入工具但不引入标准对于工具或者某一项技术的盲目崇拜，其实在 ai 工具出现以前，就已经大量存在了。比如
“死文档式”记录：引入敏捷开发的站会、看板，却不 ...
on boarding，指的是企业从面试招人，到验证这个人是否符合公司需求的阶段。也就是一个员工，是否有能力：理解用户故事的上下文，以及验收条件 - 按照测试工序的指引，分解任务 - 根据任务列表逐步完成工作。在很多公司中，并没有一个有效的 onboarding 流程。一般是在试用期内，由 HR 和 mentor 以及和员工密切协作的人，来感性评估。而非从员工能否正确实施的迭代交付上入手。
难以避免的认知分歧所谓正确实施迭代交付，即是否按照公司现有的代码架构与流程，在理解正确的用户上下文下，在给定的周期内，完成预先给出的功能范围。这里需要拉齐认知的有 3 个部分
完善的业务上下文
明确统一的代码代码架构
集体认同的验收条件
由于软件开发是集体活动，从团队视角上来看，不同成员会对同一个问题产生完全不同的看法。
对于公司的老员工来说，他们能完全胜任的的表现即为：理解用户故事上下文 -> 按照架构拆解任务 -> 完成一条待办（验收条件）
对于一些对业务理解不是很好的来说（一般是技术至上的开发）：他们并不能理解用户故事由何而来，只能不断对用户故事卡进行迭代
而刚入职的员工，就完 ...
