一种构建开发者平台的金字塔模型

【51CTO.com快译】您是否听说过“开发者金字塔”的概念?它是一种简单的结构，代表着开发者将如何学习与使用目标平台，社区将如何在该平台上成长，以及如何通过构建各种程序，来提高开发者的水平，并让社区更加成熟。在本文中，我们将逐步解构开发者金字塔，以帮助您了解如何从零开始构建新的金字塔，以及那些可用作改进现有开发水平的诊断工具。

通常，开发者金字塔由三个部分组成。如下图所示，每个部分都有着自己所服务的角色，以及支持该角色所需的基础结构。

其实，金字塔对于开发人员来说是一个很好的隐喻，它暗示着金字塔只能从基础结构开始构建。在下层尚未完成之前，您是无法直接到达金字塔顶端的。那么开发人员要想让自己的程序达到顶端，就需要保证基础的坚固与广泛。

支持学习者

在上文中，我们提到了为开发者社区中的学习者提供支持。此处的“学习者”不能被简单地理解为“初学者”，而是那些在使用既有软件产品进行二次开发的整个过程中，意识到需要通过补充某些知识，来了解核心概念，进而得出优秀实践，并提高软件产品质量的人员。

其实从本质上说，开发人员是一些永不停止的学习者。无论是平台上的新手、还是资深的用户，无论是新手程序员、还是专家，无论是要学习新的知识、还是查缺补漏，他们对金字塔底层基础的依赖性只会有增无减。

建立金字塔的基础

下面我们来看看开发人员在目标平台上如何积累成功构建的所需资源。

工具

无论是要去下载的工具包，还是使用基于云服务的平台，开发人员都需要通过工具来帮助他们配置、管理和监视自己所构建的应用程序。您可以有针对性地去收集如下领域的工具，以根据不同的应用场景，按需实现其具体的功能：

• 用户注册
• 应用注册
• 密钥和访问管理
• 数据支持
• 调试与诊断工具( https://dzone.com/articles/how-to-debug-and-optimize-boolean-strings-tutorial )
• 分析工具

文档和内容

内容是几乎每一位开发人员程序的“命脉”。由于它是其编程思想的直接表达，以便使用该系统的其他开发者了解与学习，因此，它值得您花费大量的时间和精力，去精心打磨。您可以从各种博客文章、视频、书籍、网络研讨会等渠道来营销自己的产品。其中，最值得您关注的一项核心资源是文档。它通常分为三大类：

参考资料

如果您只能为软件产品制作一份文档的话，那一定是定义系统基本输入和输出的参考资料。此类资料的可读性和参考性尤为重要。劣质的参考文档往往会带来适得其反的效果。它们将不可避免地给您的支持团队造成负担，并且阻碍社区在支持方面的推进。因此，我们甚至可以在公司的内部建立一种文化：使开发人员以完备的文档为荣，并将其作为开发过程的必备要素加以维护。

入门指南

在软件产品中，入门指南往往仅占总内容集的最小部分，但是大家在对产品进行优化时，却时常能获得团队的广为关注。由于“快速入门指南”是最终用户和其他开发人员对于目标软件的第一印象，因此我们需要保证质量，以便其他开发人员据此了解到下一步需采取何种步骤。在具体实践中，我们可以在设计和编写上参考如下原则：

• 为开发人员提供一站式的入门指南，罗列出所有值得注意的关键点。
• 任何诸如访问站点的变更、以及API的调整等针对本平台的迭代和功能的提升，都应当反映到入门指南中，并能清晰地查找和定位到。
• 请尽量保持简单，以避免纠结细节、或通过示例去践行软件的理想状态。开发人员应能够获悉完成那些首次成功调用API的最小任务集。
• 通常，我们见到的入门指南是基于文本的形式，但是为了吸引不同类型的受众，我们可以考虑采用多媒体的形式。例如：我们可以开发出视频内容，甚至是游戏闯关，以吸引年轻一代的开发人员。

代码示例与参考实现

在必要的时候，您可能需要为开发人员提供一些功能齐全的应用，以作为平台的优秀实践和参考。为了让开发人员能够据此在您的产品上自行构建与开发出新的产品，您所给出的参考实现应清晰明确，并注意如下方面：

• 如何将应用集成到CI/CD( https://dzone.com/articles/learn-how-to-setup-a-cicd-pipeline-from-scratch )的框架中?如何部署到诸如Heroku、Google Cloud或AWS等云端。
• 如何与诸如Node/Express、Visual Studio等流行的框架相集成?

有了上面的讨论，我们的开发者金字塔的基础已基本成形，请参阅下图：

规模建设

不知您是否已发现，人们愿意一开始就进行平台构建的主要目的是：希望最终通过一个社区来不断迭代和完善其对应的各项功能与应用。因此，在金字塔的中层，我们需要配备不同的论坛、博客、研讨会、以及其他活动。

工程文化

对于许多初创公司，以及项目团队而言，他们的压力主要来源于按时交付。每个组织都有自己的文化，在此，我希望每个产品开发团队都能够建立和遵循一种重视文档的工程文化，并将其贯彻到产品的开发整个过程中。

您可以采用Swagger或类似的框架，来定义自己的API，并建立一个开发的过程。在该过程中，开发人员拥有定义资源的所有权，并负责提供足够的内容，以便内、外部开发者的按需使用。当然，他们也需要谨慎而全面地考虑到，该过程的接口一旦发生更改，则可能会给向后兼容性、以及现有的实现带来何种影响。

分析工具

通常而言，我们是否具备针对目标程序及内容的调整与优化能力，将完全取决于所收集的流经该节点的相关数据量。为了实现该目标，我们往往需要通过如下三步走，来创建良好的数据收集与分析环境：

• 创建一个帐户，以专门收集此类信息。同时为内、外部开发者分配不同的账号。
• 获悉其他开发人员是否访问过您的平台，是否浏览过相关教程与指南，是否调用了您提供的API，即评估用户的转换率。
• 通过设定某些API的调用阈值，以获悉开发人员在激活了账号后，是否会持续使用该平台。

自动化

为了对开发人员提供持续的支持，并管理和收集他们可能遇到的问题，我们可以借用诸如HubSpot或Customer.io之类的营销自动化工具，来与他们保持联系，以及在开发人员发布了程序之后，帮助他们提高应用的软件质量。

原文标题：Developer Pyramid: A Tool for Building Developer Programs，作者：Byrne Reese

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】

【责任编辑：庞桂玉 TEL：（010）68476606】