WordPress 開發人員：從這裡開始！

已發表: 2017-10-14

歡迎來到我們的 WordPress 開發人員入門指南！無論您是自由職業者還是媒體機構的一員。在本文中，我們將介紹與 WordPress 開發相關的各種主題以及一些可用的資源和工具。
文本圍繞創意產生和交付之間的不同階段進行組織。我們將討論頭腦風暴、原型設計、開發，最後討論部署。所有這些，都在產品開發的範圍內。我們相信，在一個想法的最初構思和最終執行之間，存在許多微妙的領域。在當前的 WordPress 文獻中，有些充其量沒有被討論過，而另一些則在最壞的情況下完全沒有被探索過。

如果您是 Pressidium 客戶，您可以立即開始使用我們圍繞我們的平台構建的工具，從而享受高度集成帶來的好處。我們還將討論這些工具。請記住，這是一個實時文檔，應該這樣對待。

首先，我們的目標是讓本文檔對您作為 WordPress 開發人員的實踐有用，其次，向您展示我們專為您構建的一些很酷的東西。

從構思到部署

無論您是開發新產品還是承擔了一些客戶工作，從構思到部署的過程都包含 4 個階段。儘管這些階段是離散的，但它們顯著重疊並且不是線性的。我們將在正文中進一步討論：

頭腦風暴和需求啟發。
原型製作。
發展。
部署。

當您想開始構建產品或項目並且需要想法時，可以使用自由聯想頭腦風暴的過程。但是，當您的任務是為客戶構建項目或在頭腦風暴會議後得出一個想法時，就會發生需求收集。您仍然可以在之後設置頭腦風暴會議以解決特定問題，但這些會議將受到更多限制。

頭腦風暴的基本原則有兩個。追求數量，推遲判斷。我們過去寫過關於如何促進這樣的會議、如何建立正確的心態以及一些時髦的工具來幫助你。

引出要求

有幾種方法可用於引出需求，傳統上這一直是業務分析師的工作。儘管提供有關項目要求的信息是客戶的責任，但需要為所有利益相關者建立共同的理解。需求獲取是與需求收集不同的過程。更多的是通過積極參與來提供必要的信息。它不是被動地將客戶告訴您的內容收集到文檔中並將其傳遞給開發團隊。

根據項目的範圍和性質，用例是捕獲功能的好方法。用例是一種用於 UML 圖中的技術，用於描述系統利益相關者與系統本身之間的交互。由於它們是用簡單但結構化的英語編寫的場景集合，因此它們不僅不那麼複雜，而且是開始討論和勾畫系統功能的一種快速有效的方式。

如果您想捕獲複雜產品的需求，您可能需要與所有利益相關者進行結構化訪談。為此，用戶故事是一個完美的方式。它們是敏捷思維的一部分，是一種開始討論需求的非正式方式，以建立共同的理解。功能的簡短描述寫在紙卡上，通常是便利貼，並在白板上隨機排列，以創建用戶旅程的敘述。通過參與、討論和操作白板上的卡片，現場生成用戶故事。細節慢慢充實，最後作為功能添加到產品積壓中。 Jeff Patton 寫了一本關於用戶故事映射的優秀書籍，如果你想了解更多關於這個主題並開始在你的項目中使用它，我們強烈推薦這本書。

用戶故事不是一成不變的東西，一旦創建就會永遠被遺忘。相反，它們是一個動態地圖，開發和產品團隊可以一次又一次地返回到它，隨著原型階段的到來，產品開始成形。

原型的重要性在於回答問題。儘管有幾種原型方法，但我們相信進化的方法最適合我們的目的，並且可以適應現代敏捷軟件開發管道。在進化原型方法中，這個過程是循環的，原型在每個循環中逐漸變得更加精細。

每個原型迭代都從設計階段進入開發和評估階段。它提出了早期的設計問題，並提供了一些切實的東西，人們可以指出並討論可以改進的地方。從評估階段收集的洞察力將用於下一次原型迭代，並且循環再次重複。因此，原型慢慢演變為最終系統，直到它作為成品成熟。

原型設計通常以快速的開發速度進行，使用像 Bedrock、Sage 和 Bootstrap 等樣板系統可以大大縮短開發時間。像上面提到的系統提供了完整的應用程序框架和必要的工具鏈，因此您不需要每次都從頭開始。進化原型與一次性原型不同。後者是僅作為概念證明構建一次然後丟棄的原型。如果您花費大量時間構建電子商務原型，為什麼不抽像出常用功能並在將來再次使用它們，而不是扔掉所有東西並從零開始呢？

這就是 Pressidium 克隆派上用場的地方。它允許您一鍵快速克隆網站，並開始開發。這樣，您可以使用樣板文件準備多個模板網站，使用必要的插件、主題和配置預加載它們，並在項目中每次需要它們時克隆它們。您還可以以相同的方式將它們克隆到不同的 Pressidium 帳戶，例如，克隆到您客戶的帳戶。如果您的原型位於不同的託管 WordPress 託管服務提供商上，請不要擔心。只需使用我們的遷移嚮導工具並將它們導入您的 Pressidium 帳戶！

無論您是自己開發 WordPress 項目還是與其他 WordPress 開發人員和設計師合作，從長遠來看有助於您的工藝可持續性的兩個最重要的點如下：

養成良好的軟件習慣。
並且知道一切是什麼，它在哪裡，以及它為什麼在那裡。

最佳實踐從始終如一地遵循軟件風格指南到練習編寫乾淨的代碼而不是聰明的代碼，一直到高級軟件和 UI 設計選擇。第二點是簡單的文檔，以及它可以在項目中採用的多種形式。

遵循軟件風格指南，很簡單。研究有關此事的官方 WordPress.org 資源，然後決定哪些指南對您有意義，以便將它們包含在您的編碼風格中。改變習慣是一個緩慢的過程，你應該首先做一些小的改變。最終擁有一套代碼需要遵守的準則，意味著在某個時候引入代碼審查。

代碼審查是一種閱讀和檢查代碼的系統方法，旨在消除錯誤，闡明代碼中的深奧部分，並確保代碼符合標準和約定。最好由團隊中的其他人而不是您來完成。

喜歡乾淨代碼而不是聰明代碼是軟件開發的“智慧之珠”，不幸的是，只有落入聰明代碼的陷阱後才能欣賞它。要點是：雖然在某些情況下，聰明的代碼可以為你贏得“黑客”積分和稱讚，在某些情況下甚至可以提高性能，但從長遠來看，你最終會失敗。 “hackish”且難以閱讀的代碼在未來將變得難以理解。當您需要解決一個特別難以捉摸的錯誤時，它可能會花費您。在編寫優化代碼和乾淨代碼之間找到平衡是您需要自己發現的事情，但在事情的干淨方面犯錯總是更好。

此外，由於 WordPress 網站的性能在很大程度上取決於瀏覽器緩存的正確使用，因此了解您的託管 WordPress 託管服務提供商如何使用緩存非常重要。然後，您的代碼將與您的託管平台協同工作，從而獲得最佳性能。但是，請記住，以正確的方式衡量您網站的速度並不像人們想像的那麼容易，並且它包含幾個陷阱！

因此，談到高級別的最佳實踐，導致 WordPress 解耦其核心功能並提供 REST API 的決定當然可以被視為此類實踐的一個示例。這一決定標誌著邁向新時代、向程序化內容管理系統和“無頭”WordPress 應用程序開發邁進。

我們已經編寫了 WordPress REST API 的簡潔介紹和教程，以及使用 Postman 等瀏覽器插件開始修改它的簡單方法。

這個軟件設計決策看似簡單但功能強大。 WordPress 開發人員現在可以使用 WordPress 實現遠遠超過網站或博客的應用程序和功能。一個特別恰當的例子是我們的看板原型。

我們使用 WordPress 實體（例如類別和帖子）來建模具有任務、列和價值流的看板。我們草擬了一個看板列和卡片 API，將所有內容聯繫在一起。

文檔

有人會爭辯說，最佳軟件實踐有助於編寫更好的文檔，從簡單的代碼註釋到項目可交付成果，再到產品副本。

無論您如何看待它，文檔都是一種資產。

在技術文檔方面，書面語言與您日常交流或工作中使用的語言截然不同。這種寫作形式稱為技術寫作，它不僅用於計算機或軟件工程。事實上，它用於所有需要向專業受眾傳達技術概念的行業，例如法律、醫學、航空等。這是一門大學科，甚至有一些大學提供技術寫作認證。其存在的理由是使用清晰簡潔的語言傳達技術信息。主動語態優於被動語態，後者用於需要描述性文本來解釋概念的情況。

技術作家需要牢記讀者是在搜索特定信息時經常感到沮喪的人。因此，您的寫作不需要妨礙您。它的目標是讓這個過程變得簡單、直接，甚至令人愉快！

儘管您不需要擁有學位或成為專業的技術作家，但知道如何以簡潔明了的方式交流概念對於您作為 WordPress 開發人員的職業生涯非常重要。因此，每當您需要為您已構建（並引以為豪！）的插件、主題或 API 編寫文檔時，您都需要掌握基礎知識。出於這個原因，我們編寫了一份快速指南來記錄您的 WordPress 插件和主題，其中還涵蓋了技術寫作的 5 個基本原則。

但文檔並不止於此。如果您的主題或插件是大型項目的一部分，或者它們本身足夠複雜，則應該開始考慮產品文檔。除了文檔是一種資產這一事實之外，產品文檔本身也是一種營銷資產。 MindTouch 營銷副總裁 Mike PuterBaugh 在一篇關於產品文檔重要性的 Mashable 文章中恰當地概括了這一點：

這不是一項性感的事業，但它會讓你贏得同行的尊重、更有效的公司管理和更協作的團隊。因為這不是關於本季度或今年，而是關於影響競爭優勢和長期增長。

在產品方面，除了最常見的書面文檔形式外，還有更多，例如在線幫助、樣式指南、微內容等。產品文檔通常由許多不同的人合作編寫，這增加了額外的複雜性。我們編寫了一份詳盡的指南，幫助您也開始以這種方式思考和計劃。

最後，當我們進入流程的最後階段，即部署時，我們放置了文檔拼圖的最後一塊：部署圖。這些可以幫助您對一切是什麼以及應該在哪裡有一個清晰而全面的想法。

儘管大多數人在聽到 UML 時會驚恐地尖叫著逃跑（這是可以理解的，UML 的完整規範是糟糕透頂的），但 UML 包含可以為項目增加價值的符號工具的子集。部署圖是一種非常簡單的符號，僅包含節點和通信路徑，可以一目了然地向您展示項目中存在的不同環境以及每個組件需要部署的位置。

我們將在未來更深入地研究 UML，特別是另一個稱為序列圖的有用表示法，以及更詳細的用例場景圖示例，以充實項目需求並構建原型。

大多數（如果不是全部）現代開發和部署都使用某種形式的版本控制，例如 git 和 SVN。源代碼存儲庫不僅對團隊來說是必不可少的，因為即使您是一個單獨的 WordPress 開發人員，它們的好處也是廣泛的。

如果您是 Pressidium 客戶，您可以使用外部服務（例如 deploybot）通過 SFTP 將您的存儲庫與您的帳戶集成。或者，您可以使用 SFTP 將文件傳輸到您的帳戶，因為這是最簡單、最直接的方法。您還可以創建多個 SFTP 用戶並將他們分配給特定的網站和環境。說到這一點，為您的網站提供一個登台環境，可以確保您的開發和部署過程更加簡化，並且您的生產網站可以免受不必要的更改。例如，為您的網站啟用了登台，您可以從生產中提取副本，然後為您的開發人員創建一個只能在登台環境中訪問的 SFTP 帳戶。

建立一個通過多個環境的流線型開發管道是 DevOps 運動給 IT 環境帶來的變化之一。採用持續交付原則並以增量和頻繁的方式推動軟件更改，可以加快部署週期並減少錯誤。您不再需要使用不同版本的應用程序維護 ZIP 存檔。這樣，您很容易迷失方向，並部署可能會損害您的生產系統的錯誤更改集。還有文件權限被破壞的危險，這充其量可能會導致您的應用程序無法正常運行，最壞的情況是引入安全問題。

結語

我們知道您作為 WordPress 開發人員的空閒時間非常有限。這就是我們將所有內容合併到一個文檔中的原因，因為信息過載是真實存在的，而且它似乎影響了所有知識工作者，而不僅僅是 WordPress 開發人員。我們在開頭提到，我們的目標首先是提供有用的信息，其次是解決我們認為在當前 WordPress 文獻中代表性不足的主題。成為 WordPress 開發人員是一回事，保持相關性和競爭力是另一回事。要做到這一點，你需要對軟件工程作為一門學科有一個全面的認識，並養成長期為你的職業生涯服務的良好習慣、方法和技術。