课程介绍
深入详解 Apex 开发的完整七步流程：从选择合适的 Salesforce 开发组织（Sandbox、Scratch Org、Developer Edition、Trial Edition），到五大开发环境（Agentforce for Developers、VS Code & Code Builder、Developer Console、Setup 代码编辑器、文本编辑器），到学习资源（Trailhead、Apex Developer Center、Apex-recipes），到测试驱动开发（单元测试、75% 代码覆盖率要求、最佳实践），再到部署 Sandbox、部署生产环境和 AppExchange 打包发布的全生命周期。
课程章节
本课程共有 28 个章节
-
1
Apex Development Process
第 29 页咱们开始讲Apex开发的基本流程。这个过程就像搭积木，一步一步来，不会乱。 首先，你需要一个自己的开发环境，我们推荐你申请一个免费的Developer Edition组织。它就相当于你专属的练习场，可以随便写代码、测试，不会影响任何真实业务。 有了环境后，先别急着写代码，花点时间了解一下Apex是怎么回事，它的语法、运行方式，心里先有个谱。 接下来就可以动手了，开始写你的Apex类、触发器这些业务逻辑。但在写的时候，千万别忘了同步写测试代码。这个测试可重要了，Salesforce要求至少覆盖75%的代码，而且测试能帮你提前揪出问题，省得以后返工。 代码写完、测试也跑通了，如果你手头有沙盒环境，建议先把代码部署到沙盒里，再做一轮完整的测试。沙盒就是一个生产环境的复制品，在这儿你可以放心验证所有功能。 最后确认没问题了，就把Apex代码部署到真正的生产组织里，让实际用户用起来。 还有一个小贴士：如果你以后想把开发的功能打包成应用放到AppExchange上分享或销售，那这些写好的类和测试，刚好可以直接打进包里，是不是很方便？ 好，这就是Apex开发的标准流程，记住，开发、测试、部署，步步为营，你的代码会更稳健。
-
2
The 7-Step Apex Development Process
第 30 页同学们，今天我们来聊聊，如果你想开始写Apex代码，最推荐的一个开发流程是什么样的。我会一步一步地带着大家过一遍，这样你心里就有个清晰的路线图了。 第一步，咱们得选一个正确的“工作台”。记住，千万不要直接在公司的生产环境里写代码。你应该用沙盒环境，或者找一个临时的Scrap组织，也可以注册一个免费的Developer Edition组织。在这些地方折腾，不会影响到真实的数据和用户，特别安全。 第二步，磨刀不误砍柴工。在学习Apex这件事上，你可以通过Trailhead这种互动式的学习平台、Apex开发者中心里的官方文档，或者看一些代码示例和培训课程来打好基础。这能帮你理解语法和最佳实践。 第三步，准备好你的开发工具。写Apex的时候，大力推荐使用VS Code，并装上Salesforce的扩展包，体验非常好。当然，你也可以用代码生成器，或者直接在开发者控制台里写。选择一个让你舒服的环境，就可以开始敲代码了。 第四步，很重要——边写代码边写测试。我们提倡一种叫测试驱动开发的方式，就是说，在写功能代码之前或同时，就把测试类写好。这样能保证你的代码质量，也更容易满足部署时要求的代码覆盖率。 第五步，这是一个可选但推荐的步骤。如果你心里还是有点不放心，可以把代码先部署到一个专门的沙盒环境里，做一轮最终的单元测试，就像上台前的最后一次彩排，确保万无一失。 第六步，万事俱备，就可以正式部署到生产组织里啦，让你的代码真正为用户服务。 最后一步，如果以后你想把这个功能分享给更多的客户，甚至放到AppExchange上，那就可以把你的类和触发器打包成一个应用程序包，供别人安装使用。 好，这七个步骤就是我们推荐的Apex开发生命周期。记住，从安全的环境开始，测试先行，然后稳定地推向生产。照着这个流程走，能帮你避免很多麻烦。下次我们就可以挑其中一个环节再细聊。
-
3
Choose a Salesforce Org for Apex Development
第 31 页同学们，大家好！今天我们来看一个非常基础但又特别重要的话题——选择哪个Salesforce环境来写Apex代码。 首先，记住一条铁律：，绝对不要在生产环境里直接开发和测试Apex！， 为什么呢？因为生产环境里有你们公司真实的客户数据和业务流程，万一我们写的代码有bug，可能会不小心修改甚至删掉大量数据，或者把一个正在运行的业务给弄崩掉，那可是要出大问题的。所以Salesforce工程师都必须在“非生产”的安全环境里写代码。 那我们有哪些安全的“非生产”环境可以用呢？主要有三种选择：沙箱（Sandbox）、Scratch Org，还有开发者版组织（Developer Edition org）。 ，第一种，沙箱，。你可以把它想象成生产环境的一个隔离的“副本”。公司管理员会帮你从生产环境里复制一部分数据过来，可能是空白的，也可能带一些测试数据。你在这个副本里折腾，完全不影响主系统。团队协作的时候，大家经常共用一个或多个沙箱来开发和测试。缺点是，沙箱需要由管理员创建，而且数量有限，不同等级的沙箱刷新频率也不一样。 ，第二种，Scratch Org，。这个词有的小伙伴可能听成“scrap org”，其实是“Scratch”，它是Salesforce推出的一个轻量级、完全可配置的临时环境。它生存周期很短，最多30天，用完就消失了，特别适合我们做源代码驱动开发、搞持续集成或者快速试验新功能。你需要通过Salesforce CLI命令行工具，基于一个配置文件来自动创建它，创建的速度非常快，非常适合现代化开发流程。 ，第三种，开发者版组织，。这是Salesforce免费赠送给每一位学习者的一个全功能环境，跟真正的企业版几乎一样。你只需要用自己的邮箱去developer.salesforce.com网站上注册一下，立马就能得到一个永久的免费组织。它适合你练手、做小项目、学习Apex，或是展示Demo。因为是完全独立的，你不用管公司IT部门，自己注册就能用，特别方便。 那么，这么多选择，我们该怎么挑呢？如果你是初学者，就想安安静静地学Apex，那我强烈建议先注册一个免费的开发者版组织，几分钟搞定，而且永远不会过期。如果你在公司里做正式项目，那就看团队的模式了：传统项目会用专门的开发沙箱，跟着管理员节奏走；采用Salesforce DX现代开发模式的团队，会更偏爱Scratch Org，因为它能快速创建、销毁，保证环境一致。 关于如何创建，其实很简单：开发者版去官网点“注册”就行；沙箱需要你的生产组织管理员，在“设置”里找到“沙箱”，点“新建沙箱”来完成；而Scratch Org，你需要在启用了Dev Hub的生产或开发组织中，用命令 `sfdx force:org:create` 生成，不到一分钟就出来一个全新的环境。 好了，总结一下：生产环境只做神圣的发布，日常开发请乖乖待在沙箱、Scratch Org或者开发者版里。选择最适合你的那一个，然后就能安心敲代码啦。 这一节就到这里，我们下节继续。
-
4
Sandboxes (Recommended)
第 32 页好，同学们，我们来看这一页 Slide，聊一聊 Salesforce 里的沙箱。 沙箱是什么呢？你可以把它理解成一个你的生产环境的“分身”，它是一个独立的、安全的副本。这个副本会复制生产组织里的所有元数据，比如你的对象、字段、流程、代码等配置。但是，它里面的数据量，就要看你选的是哪一种沙箱类型了——有些沙箱数据是完整的，有些只是带了一小部分测试数据。 那为什么要有沙箱呢？很简单，就是为了给你一个可以放心折腾的空间。无论是开发新功能、写 Apex 代码、调流程，还是管理员想试验某个新配置，都可以先在沙箱里做。它是完全跟生产组织隔离的，你在沙箱里怎么添加、修改甚至删除，都不会对真实的生产环境产生一丝一毫的影响，这就是它的核心价值。 这里特别要提一下，启用了源跟踪的 Developer 沙箱和 Developer Pro 沙箱，。这两种沙箱在配合我们现代的 Salesforce DX 源驱动开发工具时，威力会更大。一旦开启了源跟踪，你就可以很方便地用上 Salesforce CLI 命令行工具、Code Builder 这个在线的开发环境，还有 DevOps Center 来管理整个发布流程。简单说，就是把沙箱和版本控制、自动化发布串起来了，让团队开发更专业、更流畅。 你可以把沙箱想象成一个练功房，里面的假人、沙袋都是生产配置的翻版，你可以在里面放开了练，练好了再把招式搬到真实擂台上去。这样一来，创新和试错的门槛就低多了，生产环境的安全也更有保障。 好，关于沙箱我们就先讲到这里，这一页的核心就是：安全的副本、隔离的环境，以及它为现代 DX 开发打下的基础。大家有问题可以直接提，我们接着看下一页内容。
-
5
Scratch Orgs (Recommended)
第 33 页好，同学们，咱们今天花一点时间，来聊聊 Scratch org 这个概念。这个词你可能在学 Apex 开发的时候经常听到，它到底是个什么东西呢？ 你可以把 Scratch org 想象成一张随手可用的草稿纸。它就是一个临时的、完全为你定制的 Salesforce 组织。为什么要用“临时”这个词呢？因为它的寿命不是永久的，最长也不会超过 30 天，默认情况下呢，7 天后它就自动消失了。这就意味着我们可以快速创建一个干净的环境，用完就扔掉，下次需要的时候再建一个新的。 那它有什么特别之处呢？关键就在于这个 Slide 上提到的“源驱动”。在传统的开发方式里，我们可能是在一个固定的组织里改来改去。但 Scratch org 不一样，你的代码和元数据，说白了你写的那些 Apex 类、触发器、自定义对象这些源文件，才是唯一可靠的事实来源。Scratch org 就是根据这些源文件，快速“变”出来的一个临时部署。这种模式让我们在做 Salesforce DX 开发的时候，真的非常顺手。 因为它是完全可配置的，所以你可以像搭积木一样，自由选择要在这个组织里启用哪些功能、模拟哪个 Sales force 版本。比如你想测试你的 Apex 代码在有“多币种”功能，或者在高性能版本下的表现，你只需要在配置文件中定义好，几秒钟就能拿到一个符合条件的新环境。 还有一点很重要，Scratch org 默认就开启了源跟踪。这个功能能帮我们记录下在组织里做的任何改动，然后很方便地把这些改动拉回到本地的源文件里。这样一来，我们就再也不会搞不清楚“到底哪些代码是我刚刚在组织里临时测试时写过，然后又忘了同步回项目里的”了。 最后，咱们再想想它的用途。正因为它是临时的、干净的，所以特别适合短期的开发任务，比如你写了一个新的 Apex 服务，想快速验证一下，或者跑一波自动化测试。它也非常适合集成到 CI/CD 管道里，每次构建都生成一个全新的 Scratch org，确保整个测试流程在一个绝对干净、没有历史包袱的环境下进行。 所以，简单总结一下，Scratch org 就是 Salesforce DX 专门为现代开发流程准备的一个临时、可定制的开发环境。以后你自己做练习，或者参与团队项目的时候，用它的频率会非常高。好，这节课关于 Scratch org 的理解就到这里，大家先有个印象，一会儿我们看看具体怎么创建一个。
-
6
Developer Edition (DE) Orgs
第 34 页同学们，我们来看一下开发者版组织，也就是大家常说的 DE org。这在 Salesforce 的学习和探索中是一个非常实用的工具。 简单来说，DE org 是一个完全免费的开发环境，它提供了跟企业版几乎一样丰富的功能，所以你可以在里面练习大部分的特性，不用担心费用。 不过呢，免费归免费，它也有一些限制，咱们得心里有数。首先，随着时间的流逝，这种组织可能变得比较“老”，新的功能有时没法自动更新上去，而且它的数据存储空间是很有限的，不能当作正式的生产环境来用。 另外很重要的一点是，开发者版组织默认没有开启“源跟踪”这个功能。源跟踪是用来记录你对元数据修改的一种机制，因为缺少它，你就不能把 DE org 直接用在 DevOps 中心的开发流程里，没法进行专业的持续集成和发布管理。 还有一个小提醒，如果你很长一段时间不登录这个组织，它就会自动过期失效，里面的东西可能就丢了。所以记得时不时回来看看。 好处呢，就是你完全不受数量限制，可以在官方的开发者版注册页面上注册很多个 DE org，想试什么新想法，就单独开一个，互不干扰。 所以总的来说，DE org 最适合用来做什么呢？就是个人学习、练手和探索性的小开发。你可以在里面大胆尝试，不用担心搞坏什么东西，因为随时可以再建一个新的。 好，关于开发者版组织的要点就是这些，大家现在可以试着去注册一个，动手玩一玩了。
-
7
Trial Edition & Production Orgs
第 35 页好，我们来看这一页幻灯片。它讲的是 Salesforce 里两种不同组织的区别，尤其对我们写 Apex 的人来说，非常关键。 首先，大家肯定都接触过试用版，对吧？试用版一般 30 天就到期了，所以你拿它来评估 Salesforce 的功能是很合适的，比如看看某个新特性好不好用。但是一定要记住，它设计出来就不是让你当永久开发环境用的。你可能在试用版里写了 Apex 触发器，运行得也挺好，可一旦这个试用版到期，你要把它转成其他正式的收费版本，问题就来了——所有的 Apex 触发器会被自动禁用。为什么？因为系统要保护正式环境的稳定性，它不信任试用版里随便写的代码。所以这儿有一个特别重要的提醒：在你转换版本之前，一定要把你的代码部署到另一个组织里去，比如一个正式的开发版组织或者沙盒，这样才能保留你的 Apex 触发器，要不然代码就都丢了。 然后我们再看看生产组织。生产组织是什么？就是你们公司最终真正跑业务、用户访问真实数据的地方，那个才是代码和应用程序最终的“家”。在 Salesforce 的生产组织里，你绝对不能直接打开开发者控制台去写 Apex 代码。为什么呢？因为生产环境里有成百上千的实时用户正在操作数据，你在那儿一边开发一边测试，很有可能不小心改了某个字段的值，或者触发了一个还没调试好的逻辑，就可能会破坏数据的稳定性，甚至让整个应用崩掉。想象一下，财务部正在录入订单，突然因为你写的一行代码把数据搞乱了，那后果就严重了。所以，Apex 的开发工作必须在沙盒或开发者版这些安全的、隔离的环境里完成，测试好了再部署到生产。 简单总结一下：试用版是尝尝鲜的，别太依赖它；如果要保留里面的触发器，提前迁走。而生产组织是运行代码的地方，不是写代码的地方。记住这两条，就能避免很多开发中的大坑。好了，这一页的内容就是这些。
-
8
Choose a Development Environment for Writing Apex
第 36 页好，同学们，咱们现在来看看写Apex代码都能在哪儿写。Salesforce给我们提供了好几种开发环境，大家可以根据自己的习惯和需求来选。 简单来说，有三种主流的方式。第一种是人工智能辅助工具，比如Einstein for Developers或者第三方插件，能帮你自动补全代码、甚至生成测试类，特别适合想提高效率的同学。第二种是基于浏览器的IDE，比如Salesforce的Code Builder，不用在本地安装任何东西，打开浏览器就能直接开发，方便又省事。最后一种是Salesforce平台内置的开发者控制台，它就在你的Org里面，做一些简单的调试、执行匿名代码特别快，适合快速验证和临场解决问题。 你可以把开发环境想象成写作业的桌子，有人喜欢用智能铅笔，有人习惯用平板电脑，还有人直接趴在课桌上写。这几样都不冲突，你可以混着用，关键是要找到自己最舒服的方式。后面我会给大家演示每种环境怎么进入，现在先记住这三个名字：AI工具、浏览器IDE、开发者控制台。
-
9
Agentforce for Developers
第 37 页同学们，今天我们来聊聊一个特别实用的工具，叫做 Agentforce for Developers。简单来说，它就是 Salesforce 推出的一款人工智能驱动的开发助手，专门帮我们写 Apex 代码。 你想想，平时写代码的时候，是不是经常要反复查语法、想办法构建测试类？Agentforce 就能大幅减轻这些负担。你只需要用大白话描述你想要实现的功能——我们叫它自然语言提示——它就能自动生成对应的 Apex 代码。而且，它还能在你敲代码的时候，实时给出后续代码建议，就像有个经验丰富的导师在旁边提示你。 更棒的是，写单元测试一直让人头疼，有了 Agentforce，你只要描述一下测试场景，它就能立刻生成测试用例，帮助你快速达到代码覆盖率要求。这样我们就有更多时间专注在业务逻辑上。 这个工具不是额外安装的插件，它已经集成在 Salesforce Expanded Pack 扩展包里，默认在 VS Code 中启用。所以只要你用 VS Code 做 Salesforce 开发，打开就能用，非常方便。 好了，总结一下：有了 Agentforce for Developers，我们既能根据提示生成 Apex 代码，又能享受智能内联补全，还能轻松生成单元测试。下次做项目的时候，记得试试看，绝对能让你的开发效率提升一个台阶。
-
10
Salesforce Extensions for VS Code & Code Builder
第 38 页同学们，咱们这节课来看一下Salesforce开发中最重要的两个工具：Visual Studio Code扩展和Code Builder。别被名字吓到，其实很简单。 首先，咱们熟悉的VS Code，它本身就是个很轻量的代码编辑器。Salesforce专门为它开发了一套扩展插件，你把它装上以后，VS Code就摇身一变，成了可以跟Salesforce平台深度集成的开发利器。通过这个扩展，你可以直接连接各种开发环境，比如咱们常说的Scratch组织，沙箱，或者开发者版组织。然后呢，就能在里面编写、调试和部署Apex代码、Lightning组件，还有传统的Visualforce页面，非常方便。 那Code Builder又是什么呢？它本质上是一个基于浏览器的开发环境。你可以把它想象成把刚才那个配好扩展的VS Code直接搬到了云端，而且整套东西都提前帮你安装和配置好了。你不需要在自己电脑上折腾什么环境，只要打开浏览器，登录进去，就能立刻得到一个功能完整的Salesforce开发桌面体验。 这样做最大的好处就是灵活。无论你用的是公司电脑、家里的笔记本，还是出门在外的平板，只要有网络，就能随时随地开始写代码、做开发。等于说，你拥有了一个随身携带的、配置完美的Salesforce工作台。 好，关于这两个工具的概念就先讲到这里。大家记住，它们就是帮你随时随地高效开发Salesforce应用的东西。接下来咱们再看看具体怎么去使用它们。
-
11
Developer Console
第 39 页同学们，咱们今天来看看Salesforce里一个非常实用的工具，叫“开发人员控制台”。你可以把它想象成Salesforce自带的编程工作室，专业点说就是一个集成开发环境，简称IDE。有了它，咱们就能直接在Salesforce里写代码、调试程序，还能测试Apex类和触发器，不用切换到其他软件，非常方便。 那么，怎么找到它呢？这取决于你用的是哪个版本的界面。如果你用的是比较新的Lightning Experience界面，那就看屏幕右上角，有个齿轮图标，我们叫它“快速访问菜单”，点开后，选择“开发人员控制台”就行。如果你用的是经典版Salesforce Classic，那就在页面右上角点一下你自己的名字，下拉菜单里同样能找到“开发人员控制台”的选项。很简单吧？好，接下来咱们实际操作一下，看看控制台里都有什么功能。
-
12
Developer Console — Supported Tasks
第 40 页同学们，咱们今天来聊聊Salesforce开发人员控制台，这个小工具啊，功能特别强大，是咱们写Apex代码的好帮手。 你可以把它想象成一个全能型的开发小助手，它把很多任务都整合在了一起，让咱们的工作更方便。那它到底能做些什么呢？ 首先，它带有一个源代码编辑器，你可以直接在里面写代码，还能浏览不同的包。最方便的一点是，你保存代码的时候它会自动编译，如果有什么错误，马上就会告诉你，省得你到处找问题。 接着就是调试功能了，我们可以通过调试日志和检查点，一步步去追踪代码的执行过程，看看哪里不对劲，特别容易定位bug。 还有测试，你可以直接在这个控制台里跑一个测试类，或者一次性跑所有测试，然后马上就能看到代码覆盖率，这样你就能清楚地知道哪些代码还没被测试到。 性能检查也很实用，你可以查看调试日志里的信息，找到运行慢的地方，也就是瓶颈，帮助你优化代码。 别忘了，它还有一个查询编辑器，让你能轻松写SOQL语句去查数据，非常方便。 最后，从体验上来说，这个编辑器支持颜色编码和自动完成功能，代码看起来清清楚楚，写起来也更顺手，能大大提升咱们的效率。 总之呢，开发人员控制台就是咱们日常开发的一个核心工具，把这些常用的任务都集中在一起，让我们写代码、调试、测试、优化一条龙，特别省心。大家多动手用用，一定会越来越熟练的。
-
13
Salesforce Setup Code Editors
第 41 页同学们，我们接下来看看在Salesforce里怎么查看和编辑Apex类和触发器。 你可能会问，写代码的环境在哪儿呢？其实就在Salesforce的设置界面里。当你写好一个类或者触发器，只要一保存，系统就会自动帮你编译代码。要是语法有问题，它会马上标红报错，不让你保存，直到你把错误全部改对为止。这个设计挺贴心的，对吧？就像有个助教一直在旁边检查你的作业。 代码编辑器也做了很多方便你看懂的标记。比如，每行前面都有行号，方便你定位错误。而且它用不同的颜色区分注释、关键字、字符串这些元素，看起来一目了然。 那怎么找到这个编辑器呢？很简单，在设置页面的“快速查找”框里输入“Apex”，然后选择“Apex类”或“Apex触发器”，就能看到你现有的代码和新建按钮了。 如果你要创建触发器，路径稍微绕一点：先在“快速查找”里输入你要绑定的那个对象名，比如“客户”或“订单”，点击“对象管理器”，再点击对象名称，然后找到“触发器”，点击“新建”就可以开始了。 不过有一点要特别注意，在生产环境里，也就是正式运行的Salesforce组织中，你不能直接用网页上的代码编辑器修改Apex代码。这是为了安全，防止不小心的改动影响线上业务。你只能在沙盒或者开发者版本里编辑好，再部署过去。 好了，这一块我们就讲到这里。大家先有个印象，接下来我们实际操作的时候再细说。
-
14
Additional Editors
第 42 页同学们，咱们今天来说说，在Salesforce里写Apex代码，除了用那些专门的开发工具之外，还有一个简单的办法。你完全可以在自己电脑上打开记事本，或者任何你喜欢的文本编辑器，直接写你的Apex类和触发器。写完之后呢，把代码复制粘贴到Salesforce的开发控制台里就可以了。 如果你不想手动粘贴，也可以走程序化的方式，通过调用Salesforce的API来把代码部署上去。这就要提到两个关键的API：一个是SOAP API，它可以帮助你在开发过程中编译触发器和类，还能让你远程执行测试方法；另一个是元数据API，当你的代码测试通过，准备正式上线的时候，就用它把代码部署到生产环境里。 如果你有志气，想自己开发一个专门写Apex的IDE，那这些API就是你实现自动编译、测试和部署功能的基础。不过对咱们日常开发来说，知道有记事本这个选项，再加上掌握API部署的思路，就已经足够灵活应对各种情况了。好了，这一页的内容就讲到这里。
-
15
Learning Apex
第 43 页好，同学们，现在咱们来看一看，当你有了一个Salesforce开发人员帐户之后，从哪里开始学Apex。别担心，Salesforce给大家准备了非常丰富的学习资源，无论你是零基础，还是已经有一些开发经验，都能找到合适的内容。 首先，如果你是一个初学者，我最推荐的就是Trailhead。这是Salesforce官方提供的交互式学习平台，完全免费。里面有特别多针对初学者的模块，一步一步带着你动手练习，就像玩游戏做任务一样，非常容易上手。你跟着它写一写代码，很快就能理解Apex的基本概念。 当你慢慢熟练了之后，想要深入钻研更高级的主题，就可以去访问高级开发人员中心。这里汇集了大量的技术文章、最佳实践，还有开发者论坛，很多复杂的问题都能在里面找到答案。 另外，别忘了官方还提供了丰富的代码示例。代码示例就像一个现成的工具箱，你可以直接看别人是怎么写的，甚至把代码片段复制下来改一改就用，这对于快速理解Apex的语法和设计思路特别有帮助。 所以，从Trailhead入门，再利用开发人员中心和代码示例进阶，这样学起来既轻松又扎实。有了这些资源，再加上你的开发环境，完全可以自己探索起来了。
-
16
Apex Trailhead Content
第 44 页同学们，今天我们来聊聊，想要学好Apex，Trailhead上有哪些现成的好模块可以用。这些模块就像一步一步的阶梯，帮你从零基础慢慢攀上高峰。 首先，推荐一个叫“快速入门：Apex”的模块，它采用项目式教学。什么意思呢？就像你第一次学做饭，不单独去背菜谱，而是直接动手做一道完整的菜，边做边理解每个步骤。这个模块会带着你做一个实际的小项目，让你对Apex能干什么有一个直观的、整体的感觉。 接着，你需要打好地基，那就去看“Apex基础知识与数据库”这个模块。这里会讲Apex的语法长什么样，怎么定义变量，怎么写循环和判断，更重要的是，教你怎么用Apex去查询、新增、修改Salesforce里的数据。因为大部分业务逻辑都离不开数据操作，这部分一定要搞懂。 然后，特别重要的一个模块叫“Apex触发器”。触发器就是当记录被创建、更新或删除时，能自动执行的一段代码。比如，每次新建一个客户，就自动发一封邮件通知销售经理，靠的就是触发器。这个模块会详细教你触发器的写法、执行顺序和常见注意事项。 当你的系统需要跟外部服务对话时，就去看“Apex集成服务”模块。它教你怎么用Apex发送HTTP请求，调用外部的Web服务，或者把Salesforce里的数据暴露成REST接口给其他系统用。像天气预报、支付网关这些，都可以通过这种方式集成进来。 代码写完了不能直接上线，还得有质量保证，所以“Apex测试”模块必不可少。它会教你写单元测试，模拟各种场景去验证你的代码对不对，还能告诉你代码覆盖率是什么，为什么需要达到75%才能部署到生产环境。把测试当作给代码买的保险，非常重要。 最后，当一些操作比较耗时，不能马上完成时，就需要“异步Apex”模块了。它包含未来方法、批处理、定时任务这些技术。比如，晚上定时清理数据、批量更新几十万条记录，都用得上异步模式，既不影响用户体验，又能高效完成任务。 总结一下，学完这些模块后，你就能用Apex在多个地方实现自定义的业务逻辑了：可以用，触发器，在数据变化时自动做事；用，同步Apex，做一些即时的计算和验证；通过，REST Web服务，打通内外部系统；在，Lightning组件，的控制器里调用Apex来获取数据；再配合，单元测试，保证代码可靠。这样一来，你就掌握了在Salesforce平台灵活添加业务逻辑的核心技能了。怎么样，听起来是不是很清晰？赶紧去Trailhead上动手试试吧！
-
17
Additional Learning Resources
第 45 页同学们，我们接着来看这一页幻灯片，它讲的是 Apex 开发人员中心提供的各种资源。简单来说，就是给你指路，告诉你哪里能找到学习 Apex 的好材料。 首先，Apex 开发人员中心本身就像一个入口，汇集了很多链接，里面有专门介绍 Apex 编程语言的文章。这些文章非常适合快速入门，让你对 Apex 有一个整体的认识，而且还会教给你一些开发中的最佳实践，让你一开始就养成好习惯。 那除了文章，官方的“代码示例和 SDK”页面也特别有用。那里有开源的代码例子、软件开发工具包，还有一些参考代码和推荐的最佳实践。说到这里，有一个重点推荐——就是 GitHub 上叫 Apex-recipes 的项目。这个仓库里面收集了很多简洁又实用的代码示例，每个例子都针对一个常见的业务场景，而且完全是按照最佳实践来写的，非常适合你边学边练、直接参考使用。 另外，如果你想更系统地学习、还想拿个认证，Salesforce 的 Trailhead Academy 提供了专门的培训课程。配合 Salesforce 的认证体系，你可以一步步验证和提升自己的技能水平。 这一页就是在告诉我们：想学好 Apex，别光看理论，这些配套的资源——文章、代码库还有培训——都是你的好帮手。那这一页的内容就说完了，有什么问题随时提出来。
-
18
In This Guide — Apex Developer Guide
第 46 页大家好！今天咱们来聊一聊 Apex 开发人员指南。这个指南设计得特别贴心，不管你是刚入门的新手，还是已经写过不少代码的老手，都能在里面找到适合自己的内容。咱们先看，如果你是初级程序员，刚接触 Apex，可以从哪些部分开始。首先有个“Apex 简介”，这里面讲了文档约定、一些核心概念，还有一个快速入门的小练习——叫收件箱，能让你很快就动手试一试。接着可以往下看“类、对象和接口”，这部分会帮你理解怎么组织代码、怎么让不同的代码块互相配合。然后还有“测试 Apex”，写代码不能光写完就完事儿，得确保它运行正常，这一块会教你写测试。最后，初级部分还包含“执行管理器和限制”，让你明白代码是在什么环境下跑的，有哪些资源限制，避免写出来的东西超限跑不动。 那如果是高级程序员呢，指南里也有很多深造的内容。像“触发器和批量请求最佳实践”，告诉你触发器怎么写才高效，处理大批数据的时候怎么避免踩坑。还有“高级 Apex 编程示例”，直接给你看一些复杂场景下的代码范例，跟着学思路。“理解 Apex 描述信息”能帮你更深入地读懂系统自动生成的那些元数据。另外，还有“使用@future 注释的同步执行”，这解决了某些需要异步处理的场景，让系统更流畅。以及“批 Apex 和 Apex 收件箱”，教你如何处理海量数据，分批执行，同时监控进度。 总体看，这个指南就像一本阶梯式的成长手册，你是什么水平就可以读对应的章节，一步一步提升。所以啊，无论是初学还是进阶，都可以把这份指南当成一个常备的手边参考，随时翻阅。这就是今天要跟大家分享的内容，我们下次再见！
-
19
Writing Tests
第 47 页好，同学们，我们这节课来聊聊写测试这件事。 你可能会想，测试嘛，写完代码再跑一跑不就行了？但其实啊，测试是保证我们项目能长期成功的一个关键。它不仅仅是开发流程里的一小步，而是整个开发过程里非常重要的组成部分。 所以我们强烈建议大家采用一种叫做 ，测试驱动开发， 的方式。简单来说，就是你在写功能代码的同时，就把对应的测试代码一起写了，边写边测，不要等到所有代码都堆完再去补测试。 这样做的好处是，每一步你都能马上验证自己的逻辑对不对，有问题立刻改，效率反而更高，代码质量也会好很多。 记住，测试不是负担，而是帮你写出可靠代码的好帮手。接下来我们会具体看看怎么写测试类和方法，一步步来，很好理解的。
-
20
Unit Tests — Overview
第 48 页同学们，今天我们来聊一聊 Apex 里的单元测试，这可是写出稳定、靠谱代码的好帮手。你可以把单元测试想象成给代码做的一个个小体检，能帮你提前发现潜在的毛病。 具体来说，单元测试就是一些特殊的类方法，专门用来验证某一段代码是不是按预期在工作。这些测试方法和普通方法可不一样，它们有几个硬规矩：第一，它们不能接收任何参数；第二，运行的时候不会把数据真的存进数据库；第三，更不会乱发邮件打扰别人。这样一来，你就能在完全安全的环境里检查代码逻辑，不用担心把生产系统搞乱。 那么怎么告诉 Salesforce “这是个测试方法”呢？很简单，在方法定义前面加上 `@IsTest` 这个注解就行了。而且，这个方法还必须待在一个测试类里面，这个类同样要用 `@IsTest` 来标注。你可能会在一些老的代码里看到 `testMethod` 关键字，它的作用和 `@IsTest` 差不多，但 Salesforce 现在强烈建议大家用 `@IsTest`，因为 `testMethod` 将来可能会在新版本里被淘汰。养成用 `@IsTest` 的习惯，你的代码就能一直跟上时代。 记住这些要点，你就能写出安全又规范的单元测试，让代码质量从一开始就有保障。好了，关于单元测试的基础就讲到这里，大家在实操中多练练手，很快就能掌握。
-
21
Test Coverage Requirements
第 49 页同学们，咱们今天讲一个非常实用的知识点：当你辛辛苦苦写好了Apex代码，想要部署到生产环境，或者打包发布到AppExchange的时候，必须先跨过三道门槛。这三条要求，缺一不可。 第一条，关于单元测试的覆盖率。你的测试代码，必须覆盖至少75%的Apex业务代码，而且所有的测试方法都要成功跑通，不能有一个失败。注意啊，等到真正部署到生产组织的时候，Salesforce会默认把你这套命名空间下全部的单元测试统统执行一遍。这里有个小细节：计算覆盖率时，测试类和方法本身是不算进去的，你写在测试里的System.debug调试语句，也不会算进覆盖范围。所以别指望靠一大串debug来凑数。 第二条，专门针对触发器。每一个触发器，不管多简单，都必须被测试覆盖到。哪怕触发器里只有一行代码，你也得去写一段测试，确保它被执行过。 第三条，最基础的要求：你所有的类和触发器，必须成功编译，不能有任何语法错误。一旦编译失败，部署就会被直接拒绝。 别看这三条要求讲起来简单，它们可是保证你代码质量的第一道防线。记牢了，以后部署就不会手忙脚乱啦。咱们下节课再见。
-
22
Test Coverage Best Practices
第 50 页同学们好，今天我们聊一个非常容易踩坑的话题：测试覆盖率。 Salesforce要求我们写的Apex代码至少要有75%被测试覆盖，这大家都知道。但很多同学一上来就盯着那个数字，不停地跑测试看百分比，千方百计就为了凑够75%。其实，这是一个常见的误区。 我们真正应该做的，是忘记那个百分比，把心思放在，覆盖所有业务用例，上。 什么意思呢？就是你写的这个功能，用户会怎么用？正常的流程要测，这叫积极情况。比如用户正确提交了一个订单，系统应该顺利创建记录。那如果用户填错了信息、或者缺少必填字段呢？这些消极情况，也就是异常流程，同样要测。因为真实世界里，用户犯错太正常了。 另外，还要记住一点：你的代码可能在处理一条记录时好好的，但一下子进来200条记录，会不会崩？所以，单元测试里既要测单条记录的场景，也必须模拟批量处理的场景，比如一次插入200条数据，看看触发器、各种逻辑能不能扛得住。 当你真正把积极情况、消极情况、单条、批量这些真实世界的场景都覆盖到了，你会发现，75%的覆盖率自然就达到了，甚至远远超过。而且这时候你的代码是真正健壮的，上线以后你不会提心吊胆。 一定要记住：单元测试的目标从来不是凑那个数字，而是给你信心——让你确信，当真实用户在各种五花八门的情况下使用你的应用时，代码都能稳稳地给出正确的结果。 所以，下次写测试的时候，别问“覆盖率够不够75%”，要问自己：“我把所有可能的用户使用场景都测到了吗？” 这才是全面的质量保证。
-
23
Deploying Apex to a Sandbox Organization
第 51 页现在我们来讲讲怎么把写好的Apex代码部署到沙箱组织里。你可能会问，什么是沙箱？别担心，我打个比方你就明白了。 想象一下，你是一个画家，正在创作一幅很重要的画。你不能直接在大画布上乱涂乱画，万一画错了，整幅画就毁了。所以你会先拿一张小一点的草稿纸，在上面打草稿、调颜色、试笔触，满意了再搬到正式的大画布上。 沙箱其实就是这么一张“草稿纸”。它把生产组织——也就是你公司真正在用的Salesforce系统——一模一样地复制一份到一个隔离的环境里。这个复制出来的就是沙箱。你在里面做开发、测试、培训，怎么折腾都行，因为沙箱跟生产环境是完全隔开的。你在沙箱里删掉一条客户数据，或者改了某个设置，都不会影响到真实的业务系统。这样，你就有了一个安全、自由的“练习场”，可以放心地去修改代码、试验新功能。 我们的Apex代码写完以后，肯定不能直接就扔到正式系统里跑，得先在沙箱里部署，看看它能不能正常工作，有没有跟别的功能冲突，数据对不对。确认没问题了，再部署到生产组织。就像画家在草稿纸上画得满意了，才正式动笔画大画一样。 所以，记住一个核心：沙箱就是你的安全试验场，隔离、独立，随便试，不怕闯祸。这就是今天要讲的概念，很简单吧？
-
24
Sandbox Deployment Methods
第 52 页同学们，我们这节课来看看 Apex 代码写好之后，怎么把它部署到 Salesforce 组织里。 最常见的一种方式，就是直接用 Visual Studio Code 里的 Salesforce 扩展。 你在 VSCode 里面把项目设置好，写好 Apex 类，然后直接在扩展里点一点，或者用它的命令，就能把本地代码部署到你绑定的 Salesforce 组织，特别方便。 如果你想更自动化一些，或者要从一个开发组织转移到沙盒环境，也可以使用元数据 API 的 `deploy()` 调用。 简单说，就是通过代码或者工具去调用这个接口，把开发组织里的 Apex 部署到沙盒组织。 这里还有一个很实用的 API 调用，叫 `runTests()`。 在开发组织或者沙盒组织里，你可以用它来运行单元测试，可以指定运行某一个类、一组类，甚至是整个命名空间下的测试。非常适合在部署前后快速验证。 除了这些，Salesforce CLI 命令行工具也是我们经常用的。 比如执行 `sfdx force:source:de
-
25
Deploy Apex to a Production Organization
第 53 页同学们，咱们接着讲。前面你已经学会了怎么在沙盒或开发者环境里写Apex代码，也做了单元测试，确保逻辑完全正确。那现在到最后一步了——就是把你的Apex部署到真正的生产环境，也就是你们的正式Salesforce组织。 先记住一个关键点：生产环境是你公司正在使用的真实系统，里面有客户数据、业务流程，所以部署一定要小心，不能随随便便就直接改。而且Salesforce有硬性规定，你部署到生产环境的Apex代码，必须至少有75%的单元测试覆盖率，并且所有的测试都要跑通。也就是说，你之前在沙盒里跑过的测试，在生产部署的时候系统会再自动跑一遍，如果有一个失败，整套部署都会被回滚，保证生产不被破坏。 部署的方式有好几种，最常见的让新手容易理解的是变更集。你可以在开发环境里创建一个出站变更集，把你要部署的Apex类、触发器、组件什么的都选进去，然后上传到生产组织。生产组织那边接收以后，先验证一下，跑一遍所有相关测试，确认没问题了，再真正部署进去。这就好比寄快递前你先把东西打包好，对方收到后检查完好才签收。 另外如果你公司用更自动化的流程，也可能通过元数据API，配合一些CI/CD工具来做部署，但原理类似——都是把代码封装起来，经过测试验证后才允许进入生产。 所以总结一句话：先写代码，再写测试，全部通过之后，用安全的传递方式部署到生产，让系统自动再检验一遍，成功就上线，失败就回退。大家记住这个流程，以后工作中每次部署都会用到。 好了，有不清楚的随时可以问。咱们下节继续。
-
26
Production Deployment Process
第 54 页同学们好，今天我们来聊聊如何把写好的 Apex 代码从你本地的编辑器里，真正部署到 Salesforce 的组织中去。这个话题很实用，因为我们写代码，最终是要让它跑在服务器上的。 首先，我们现在最常用的本地开发工具就是 Visual Studio Code，你可以在里面安装 Salesforce 提供的官方扩展包。装好之后，就能直接在 VS Code 里连接你的 Salesforce 组织，然后把 Apex 类、触发器这些源文件一键部署上去。这套体验在 Salesforce 后来推出的 Code Builder 这个在线的开发环境里也是一样的，因为它背后用的也是和 VS Code 一样的扩展。所以你只需要记住：当你在 VS Code 或 Code Builder 里开发完，想发布时，直接在扩展的面板里操作部署就行，很方便。 那除了用这些现代的开发工具，Salesforce 还提供了一种更传统的方式，就是通过用户界面里的“变更集”。变更集是什么呢？你可以把它想象成一个包裹，你把写好的 Apex 类、触发器、字段、对象等等组成一个集合，然后把它从一个环境，比如沙盒，上传到另一个环境，比如生产环境。这个方式不需要安装任何外部工具，完全在浏览器里点一点就能完成。只是它相对慢一些，适合比较小的、不太频繁的发布场景。 当然，不管是用哪种部署方式，在正式把代码推到组织之前，有一组硬性要求你必须遵守。这些可不是建议，是 Salesforce 平台强制检查的。最重要的第一条，就是代码的整体测试覆盖率要超过 75%。也就是说，你写完 Apex 类之后，必须编写对应的测试类，执行这些测试后，被覆盖到的代码行数要占到所有代码行的 75% 以上。这个规则是为了保证你部署上去的逻辑是经过验证的，不会轻易出问题。 第二条是，所有的测试都要能通过，不能有任何一个测试报错或者断言失败。哪怕覆盖率够了，如果有一个测试没跑通，部署也会被直接拒绝。 第三个检查点专门针对触发器，每一个你写的触发器都必须要有相应的测试覆盖。你不能写了一个触发器，却从来没测试过它，这是不行的。 最后，也是最基础的，你所有的 Apex 类和触发器必须能成功编译，不能有任何语法错误或者编译报错。如果代码本身编译都过不去，那部署自然不可能成功。 总结一下，今天这个知识点告诉我们两点：一是部署的常见途径——用 VS Code 加上 Salesforce 扩展是最现代的，用变更集是界面化、传统的做法；二是部署前必须通过的四个关卡：75% 以上的测试覆盖率、全部测试通过、每个触发器都有测试覆盖、以及代码编译零错误。记住这些，你的部署就会非常顺畅。 好，这节课就到这里，大家课后可以打开自己的开发环境，试着写一个简单的类和测试类，然后亲手执行一次部署，感受一下这些规则是怎么运作的。
-
27
Adding Apex Code to an AppExchange App
第 55 页好，接下来咱们聊一下关于 AppExchange 打包时，对 Apex 代码的一个硬性要求，这个要点虽然简短，但非常重要。 你在为 AppExchange 开发应用的时候，当然可以把写好的 Apex 类和触发器一起打包进去。但是呢，发布到 AppExchange 上给客户安装之前，Salesforce 会严格检查你的测试覆盖率。 首先，一个包里面所有的 Apex 代码，注意是累计起来，总的测试覆盖率必须达到 ，至少 75%，。什么叫累计覆盖率呢？不是你每一个类都要达到 75%，而是把你所有 Apex 类的被测试覆盖的代码行数，加在一起算总比例，不能低于 75%。所以哪怕有个别类的覆盖率稍微低一点，只要整体达标就可以。 其次，还有一点专门针对触发器的：，每一个触发器，都必须要有一些测试覆盖，。也就是说，触发器绝对不能是零覆盖。哪怕你的触发器只有简单几行，也必须写测试类去执行它、覆盖它，让它有哪怕一点点覆盖率，但绝不能是空的。 为什么这么规定呢？因为 AppExchange 上的应用会被成千上万的客户安装到他们重要的生产环境里，Salesforce 需要保证这些代码是经过验证的、稳定可靠的。测试覆盖率就是一个最基本的安全网。 所以简单总结一下：想把 Apex 放进 AppExchange 包，就得记住两条规则——第一，整体 Apex 累计测试覆盖率至少 75%；第二，每个触发器都要有覆盖，不能留白。这样你的应用才能顺利通过安全审查，上架到 AppExchange。 好，这一页的核心要点就这些，咱们把它记住了。
-
28
AppExchange Packaging Requirements
第 56 页同学们，今天我们来聊一个在Salesforce开发中非常重要的概念，就是打包时的测试覆盖率要求。你看啊，如果你想把写好的Apex代码打包成一个托管包，然后发布到AppExchange上让别人安装使用，那就必须遵守一些质量门槛。这个门槛是什么呢？就是测试覆盖率。 简单来说，任何包含在你包里的Apex代码，包括你写的类和触发器，一定要有至少75%的累积测试覆盖率。注意这个“累积”的意思，是不管你有多少个类，全部加在一起算，而不是每个类单独都要达到75%。比如你有一个大类和几个小类，只要整体覆盖的行数比例超过75%就行了。但是，对于触发器，可不能说“我整体够了就不用测它”，文档特别强调：每个触发器也必须有一些测试覆盖，哪怕只覆盖一点点，也不能是零。 为什么要有这样的要求呢？因为你上传包到AppExchange的时候，Salesforce平台会自动运行你包里所有的测试方法，确保它们全都无错误地通过。这样做是为了保护下载你包的用户，保证你的代码质量是可靠的。如果测试通过不了，系统是不让你上传的。 好，这还没完。当有用户真正把这个包安装到他们自己的组织里时，系统还会再跑一次测试，但并不是跑全部测试哦。它会只运行那些你用 `@isTest(OnInstall=true)` 这个注解标记过的测试方法。也就是说，你可以在测试类里挑一些关键场景，打上这个标记，专门用来验证安装过程是否顺利。这样做的好处是既节省安装时间，又能抓住最核心的问题。那当然，要成功安装，这组被标记出来的测试子集，也必须全部通过才行。 我提一下，有些资料里可能会写错，把 `OnInstall` 写成了 `OnSure`，同学们要留意正确的注解是 ` @isTest(OnInstall=true) `。如果你想知道更详细的内容，可以去看官方发布的《第二代托管打包开发人员指南》，里面有更完整的说明。 所以总结一下，就是三件事：包代码整体覆盖率要到75%，触发器不能没有覆盖，安装时只跑你打标的关键测试且必须通过。记住这些，你打包发布的流程就会顺畅很多啦。 好，这节就讲到这里，我们下回见。
📋 课程信息
- 所属目录：DEX455
- 课程名称：Apex 开发流程详解
- 章节数量：28 个