通過將設計師帶入代碼審查過程來更好地協作

開發人員和設計師之間的順暢協作是每個人都嚮往的事情，但這是出了名的困難。 但是對於當今先進的網絡，如果不跨學科協作，很難（如果不是不可能的話）構建一個真正偉大的產品。 由於構建產品所需的技術範圍很廣，只有當所有學科——開發人員和設計師、內容創建者和用戶體驗策略師——從項目的早期階段深入參與時，產品才能真正取得成功。 當這種情況發生時，構建產品所需的所有方面自然而然地結合成一個統一的整體，從而成為一個偉大的產品。

正因為如此，沒有人再真正推廣瀑布流程了。 然而，儘早讓其他人參與進來，尤其是其他學科的人，會讓人感到害怕。 在最壞的情況下，它會導致“委員會設計”。

此外，設計師和內容策略師通常都具有在其中唯一的創意天才仍然是理想的領域的背景。 讓其他人證明您的工作可能會威脅到您的創造力。

那麼，您如何儘早讓人們參與進來，這樣您既可以避免瀑布，又可以確保您不會為委員會的設計做好準備？ 我在學習代碼審查時找到了答案。

啊哈！ 片刻

2017 年 7 月，我與兩名開發人員一起創立了 Confrere，我們很快聘請了我們的第一位工程師（我自己不是開發人員，我更多的是 UX 或內容設計師）。 我們的合作出人意料地順利進行，以至於在我們的回顧展上，反復出現的主題是我們都覺得我們“做得對”。

我和我的同事坐下來，試圖確定我們“做得對”到底是什麼，這樣即使我們的公司發展壯大，我們的團隊擴大了，我們也可以努力保持這種感覺。 我們意識到，我們都很欣賞整個團隊早期的參與，並且我們在彼此的反饋中都誠實而清晰。 我們的首席技術官 Dag-Inge 補充說：“它之所以有效，是因為我們是作為同行這樣做的。 你沒有被責備，只是得到一個錯誤清單”。

“同行”這個詞給了我一個哈哈的時刻。 我意識到我們這些從事 UX、設計和內容工作的人在協作方面需要向開發人員學習很多東西。

以代碼審查形式進行的同行審查對於軟件的構建方式至關重要。 對我來說，代碼審查為改善我們自己領域內的協作提供了靈感，同時也是跨領域和跨學科協作的模式。

如果您已經熟悉代碼審查，請隨意跳過下一部分。

什麼是代碼審查？

可以通過多種方式進行代碼審查。 今天，最典型的代碼審查形式是所謂的拉取請求（使用一種稱為 git 的技術）。 如下圖所示，拉取請求讓團隊中的其他人知道開發人員已經完成了他們希望與主代碼庫合併的代碼。 它還允許團隊審查代碼：他們在合併之前對代碼提供反饋，以防需要改進。

拉取請求具有明確定義的角色：有作者和審閱者。

例如，假設我們的高級工程師 Ingvild 對 Confrere 的註冊流程進行了更改。 在將其合併到主代碼庫並交付之前，她（作者）創建了一個拉取請求，以請求我們的 CTO Dag-Inge（審閱者）進行審閱。 他不會對她的代碼進行任何更改，只會添加他的評論。

取決於 Ingvild 如何根據她在評論中收到的反饋採取行動。 她將使用她認為合適的更改來更新她的拉取請求。

當審閱者批准拉取請求時，Ingvild 可以將她的更改與主代碼庫合併。

為什麼要費心進行代碼審查？

如果您從未進行過代碼審查，那麼上述過程可能聽起來很官僚。 如果您有疑問，這裡有大量關於代碼審查優勢的博客文章和學術研究。

代碼審查為整個公司定下了基調，我們所做的一切都應該接受其他人的審查，並且這種審查應該是您工作流程中受歡迎的部分，而不是被視為威脅。

——布魯斯·約翰遜，全文的聯合創始人

代碼審查降低了風險。 讓某人證明您的工作，並且知道有人會證明您的工作，有助於消除錯誤並提高質量。 此外，它確保了一致性並幫助每個團隊成員熟悉更多的代碼庫。

如果做得好，代碼審查還可以建立一種協作和開放的文化。 嘗試理解和批評他人的工作是一種很好的學習方式，獲得對工作的誠實反饋也是如此。

總是讓至少兩個人查看代碼也會減少“我的”代碼和“你的”代碼的想法。 這是我們的代碼。

考慮到這些優勢，審查不應該只針對代碼。

審查所有學科的原則，而不僅僅是代碼

對於評論，總是有一位作者和一位或多位評論者。 這意味著您可以儘早讓人們參與進來，而不會陷入委員會的設計中。

首先，我必須提到兩個重要因素，它們會影響您的團隊進行有益審查的能力。 您不一定必須掌握它們，但至少，您應該追求以下幾點：

• 你和你的同事互相尊重，也尊重彼此的紀律。
• 你對自己的角色有足夠的自信，以至於你覺得自己既可以給予批評，也可以接受批評（這也與團隊的心理安全有關）。

即使我們不審查代碼，也可以從現有的​​代碼審查最佳實踐中學到很多東西。

在我們的團隊中，我們在進行審核時嘗試遵守以下原則：

1. 批評作品，而不是作者。
2. 要批判，但要保持和藹可親和好奇。
3. 區分 a) 建議 b) 要求 c) 需要討論或澄清的點。
4. 將討論從文本轉移到面對面。 （視頻計數）
5. 好的部分別忘了點贊！ 什麼是聰明的、有創意的、紮實的、原創的、有趣的、漂亮的等等？

直到我們討論了為什麼我們的合作工作如此順利之後，這些原則才真正被寫下來。 我們都覺得我們已經被允許並被期望提出問題並提出改進建議，而且我們的動機始終是共同創造偉大的東西，而不是批評他人。

因為我們很清楚我們給出了什麼樣的反饋，並且還記得互相稱讚對方的出色工作，所以進行評論是一種積極的力量，而不是一種消極的力量。

一個例子

為了讓您了解我們的團隊如何跨學科和整個流程使用審閱，讓我們看看我們團隊的不同成員在創建註冊流程時如何在作者和審閱者的角色之間切換。

第 1 步：需求收集

作者：艾達（UX）

審稿人： Svein（戰略）、Dag-Inge（工程）、Ingvild（工程）。

如果沒有結構，白板會議可能會讓人筋疲力盡。 為了保持生產力和創造力，我們使用作者/審稿人結構，即使對於像在白板上進行頭腦風暴這樣看似基本的事情也是如此。 在這種情況下，我們提出了註冊流程的要求，我必須成為作者，而團隊的其他成員則提供他們的反饋並充當審閱者。 因為他們也知道他們能夠審查我在第 2 步中提出的建議（更多調整、建議和改進的機會），所以我們工作迅速，能夠在 2 小時內就要求達成一致。

第 2 步：用顯微鏡製作模型

作者：艾達（UX）

審稿人： Ingvild（工程）、Eivind（設計）、Svein（戰略）。

作為一名作者，我用微文案創建了一個註冊流程模型。 從用戶和工程的角度來看，註冊流程是否有意義？ 我們如何從設計和前端的角度改進流程？ 在這個階段，必須以一種所有學科都可以輕鬆提供反饋的格式工作（我們選擇了 Google Docs，但也可以使用 InvisionApp 之類的工具來完成）。

第 3 步：實施註冊流程

作者： Ingvild（工程）

審稿人： Ida (UX) 和 Dag-Inge（工程）。

我們已經就流程、輸入字段和微文案達成一致，因此由 Ingvild 實施。 感謝 Surge，我們可以自動創建更改的預覽 URL，以便無法閱讀代碼的人也可以在此階段提供反饋。

第 4 步：用戶測試

作者：艾達（UX）

審稿人：用戶。

是的，我們認為用戶測試是一種審查形式。 我們將新建的註冊流程與實際用戶面對面。 這一步給了我們很多洞察力，我們的註冊流程中最顯著的變化也隨之而來。

第 5 步：設計

作者： Eivind（設計）

審稿人： Ingvild（工程）和 Ida（UX）。

當設計在第 5 步突然出現時，它可能看起來很像瀑布過程。 然而，我們的設計師 Eivind 從第 2 步開始就已經作為審閱者參與其中。他在那個階段提供了一堆有用的反饋，並且還能夠開始思考我們如何在現有模塊之外改進註冊流程的設計在我們的設計系統中。 在這一步，Eivind 還可以幫助解決我們在用戶測試中發現的一些問題。

第 6 步：實施

作者： Ingvild（工程）

審稿人： Eivind（設計）、Ida（UX）和 Dag-Inge（工程）。

然後我們回到實施。

為什麼審查有效

總之，總是只有一個作者，從而避免了委員會的設計。 通過在早期讓一系列學科作為審閱者，我們避免了瀑布過程。

人們可以及早提出他們的擔憂，也可以開始考慮他們以後如何做出貢獻。 明確定義的角色使流程保持在正軌上。

定期審查演練

從代碼演練中汲取靈感，我們還根據以下原則定期進行不同重點的審查演練：

• 演練是一起完成的。
• 一名負責審查和記錄。
• 這個想法是發現問題，而不是解決問題。
• 選擇一種能夠提供盡可能多的上下文的格式，以便稍後根據發現採取行動（例如，用於視覺評論的 InvisionApp，用於文本的 Google Docs，等等）。

我們已經完成了諸如可訪問性審核、審核功能請求、審核設計實施以及進行啟發式可用性評估等內容的審核演練。

當我們進行季度可訪問性審查時，我們的可訪問性顧問 Joakim 首先檢查界面和文檔，並優先考慮他在共享的 Google 表格中發現的問題。 然後，Joakim 向我們介紹了他發現的最重要的問題。

面對面（或至少在視頻上）討論問題有助於創造一個學習環境，而不是一種被監督或微觀管理的感覺。

如果您發現自己總是被一些應該發布的東西所束縛，或者修復收件箱頂部的任何東西，評論可以幫助解決這個問題。 如果您定期留出半天時間來回顧您已經完成的工作，您可以在問題變得緊急之前發現問題。 它還可以幫助您重新集中註意力並確保您的優先事項保持正確。 在您確信現有功能符合您的標準之前，您的團隊可能不應該開始構建該新功能。

用戶測試是一種審查形式

代碼審查的一個重要動機是降低風險。 通過每次引入更改或向產品添加新內容時都這樣做，而不僅僅是在您懷疑某些內容可能達不到標準時，您可以減少發布錯誤或低於標準的功能的機會。 我相信我們應該從同樣的角度看待用戶測試。

您會看到，如果您想降低交付時出現重大可用性問題的風險，則用戶測試必須成為您流程的一部分。 僅僅讓你的用戶體驗設計師審查界面是不夠的。 一些研究發現，即使是可用性專家也無法識別出每個實際的可用性問題。 平均而言，專家發現的問題中有三分之一是誤報——在實踐中它們不是用戶的問題。 但更糟糕的是，用戶實際上確實有 2 個問題被專家忽略了。

跳過用戶測試與跳過代碼審查風險一樣大。

評論是否意味著創造力的死亡？

在設計、用戶體驗和內容領域工作的人通常具有藝術學校或文學的教育背景，其中唯一的創造者或創造性的藝術天才被譽為理想。 如果您回顧歷史，開發人員也是如此。 隨著時間的推移，隨著 Web 開髮變得越來越複雜，這種情況發生了必然的變化。

如果你堅持創造力來自自己內心深處的想法，那麼審查的想法可能會讓人感到威脅或恐懼。 有人插手你的半成品？ 哎喲。 但是，如果您認為創造力可以來自多種來源，包括對話、協作或任何形式的靈感（無論是來自外部還是來自您內心的某個地方），那麼評論只是一種資產和機會。

只要我們正在為網絡構建一些東西，就沒有辦法與其他人合作，無論是在我們自己的領域還是其他人。 一個好主意將在審查中倖存下來。

讓我們一起創造偉大的東西。