【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】