在 2019 年上一季，Chrome 開發人員工具團隊開始改善開發人員工具中的 Cookie 開發人員體驗，Google Chrome 和其他瀏覽器已開始變更預設 Cookie 行為，因此這一點格外重要。
在研究開發人員工具提供的工具時，我們發現自己經常出現以下情況：
😰? 這個控制台內含很多警告和錯誤訊息，包含與技術說明相關的問題，有時甚至會連結到 chromestatus.com。所有訊息看似同等重要，因此難以判斷應優先處理哪個步驟。更重要的是，這段文字並未連結至開發人員工具內的其他資訊，導致使用者難以理解情況。最後，這些訊息通常會交由網頁程式開發人員解決，讓他們瞭解如何修正問題，甚至還能瞭解技術脈絡。
假如您同時也使用從自己的應用程式收發訊息，有時可能難以在瀏覽器上的所有郵件之間找到這些郵件。
您和人類也難以與控制台訊息互動。舉例來說，開發人員可能在持續整合/持續部署的情況下使用 Chrome Headless 和 Puppeteer。由於主控台訊息只是字串，因此開發人員必須撰寫規則運算式或其他剖析器，才能擷取可採取行動的資訊。
解決方案：結構化與可做為行動依據的問題報表
為了替我們發現的問題找出更好的解決方案，我們首先開始思考各項需求，並透過設計文件收集。
我們的目標是以清楚的方式說明問題和解決方法。 從設計過程中，我們意識到每個問題都包含下列四個部分：
- 標題
- 說明
- 開發人員工具中受影響資源的連結
- 並提供詳細指引的連結
我們希望應用程式標題簡短且精確，協助開發人員瞭解核心問題，而且通常已取得修正提示。舉例來說，Cookie 問題現在只會寫成：
將跨網站 Cookie 標示為安全，即可在跨網站環境中設定這些 Cookie
每個問題都會附上更詳細的資訊，說明發生什麼事、提供可採取的修正建議，並可透過開發人員工具中的其他面板連結，瞭解問題所在。我們也提供 web.dev 深入探討文章的連結，讓網頁程式開發人員更深入地瞭解這個主題。
每個問題的關鍵部分都是「受影響的資源」部分，這個部分會提供開發人員工具的其他部分連結，方便您進一步調查。以 Cookie 問題為例，應該有觸發問題的網路要求清單，按一下要求就會直接將您導向「網路」面板。我們希望這不僅方便，也強調了使用開發人員工具中的各個面板和工具，對特定類型的問題進行偵錯。
我們先考量開發人員與「問題」分頁的互動情況，以期演變的開發人員互動情形：
- 初次遇到特定問題時，網頁程式開發人員會閱讀文章，深入瞭解問題。
- 再次遇到問題時，我們希望問題說明足以幫助開發人員瞭解問題所在，讓他們能立即調查問題並採取行動。
- 如果您遇到這個問題數次，希望問題標題足以讓開發人員辨識問題類型。
我們想要改善的另一個重點是匯總。舉例來說，假設同一個 Cookie 多次造成相同的問題，我們只能回報 Cookie 一次。除了大幅減少郵件數量之外，這通常也有助於更快找出問題的根本原因。
實作方式
瞭解這些需求後，團隊開始思考如何導入新功能。Chrome 開發人員工具的專案通常橫跨三個不同領域：
- Chromium：採用 C++ 語言在 Google Chrome 後方所編寫的開放原始碼專案
- 開發人員工具前端：Chrome 開發人員工具的 JavaScript 實作
- Chrome 開發人員工具通訊協定 (CDP)，亦即連接兩者的層
接著由以下三項工作組成：
- 在 Chromium 中，我們必須識別出需要顯示資訊的元件，並在不影響速度或安全性的情況下，開放開發人員工具通訊協定存取這些資訊。
- 接著，我們必須設計 Chrome 開發人員工具通訊協定 (CDP)，以定義向用戶端 (例如開發人員工具前端) 公開資訊的 API。
- 最後，我們需要在開發人員工具前端中實作一個元件，透過 CDP 要求瀏覽器提供資訊，並在適當的 UI 中顯示該元件，方便開發人員解讀資訊及與資訊互動。
我們在瀏覽器方面，會先研究控制台訊息的處理方式，因為訊息的行為與我們在問題中的想法非常相似。CodeSearch 通常是適合這類探索的起點。可讓您在線上搜尋及探索 Chromium 專案的完整原始碼。如此一來，我們就能瞭解主控台訊息的實作方式，並根據我們收集的問題需求建立平行、但有條理的方法。
我們始終謹記所有安全性疑慮，因此這項工作格外具有挑戰性。Chromium 專案能長期將內容分成不同的處理程序，而且只能透過受控的通訊管道進行通訊，以避免資訊外洩。問題可能含有機密資訊，因此我們必須謹慎處理，避免將資訊傳送到瀏覽器無從得知的位置。
開發人員工具前端
DevTools本身是以 JavaScript 和 CSS 編寫的網頁應用程式。這與許多其他網路應用程式一樣，不過早已推出超過 10 年。當然，後端的後端基本上是與瀏覽器的直接通訊管道，也就是 Chrome 開發人員工具通訊協定。
在「問題」分頁中，我們首先考量的是使用者案例，以及開發人員要如何解決問題。我們大多是從「問題」分頁著手調查，並將使用者連結至顯示更詳細的資訊的面板，做為調查基礎。我們決定將「問題」分頁與其他「開發人員工具」分頁放在開發人員工具底部，方便開發人員在與其他開發人員工具元件 (例如「網路」或「應用程式」面板) 互動時保持開啟。
因此，我們的使用者體驗設計人員瞭解我們想要達到的目標，並據此設計以下初始提案的原型：
經過多次討論找出最佳解決方案後，我們開始實作設計並重整決策，逐漸抵達今天的「問題」分頁。
另一個重要因素是「問題」分頁的曝光度。過去，許多實用的開發人員工具功能需要開發人員明確尋找特定功能才能派上用場。在「問題」分頁中，我們決定突顯多個面向的問題，確保開發人員不會錯失重大問題。
我們決定在控制檯面板中新增通知，因為部分控制台訊息現已移除，有利於遇到問題。我們也在開發人員工具視窗右上方的警告和錯誤計數器中新增圖示。
最後，「問題」分頁不僅會連往其他開發人員工具面板，與問題相關的資源也會連結至「問題」分頁。
在通訊協定中
前端與後端之間的通訊是透過名為 Chromium 開發人員工具通訊協定 (CDP) 的通訊協定。您可將 CDP 視為 Chrome 開發人員工具網頁應用程式的後端。CDP 劃分為多個網域，每個網域都包含多項指令和事件。
在「問題」分頁中，我們決定在 Audits 網域中新增事件，以在發生新問題時觸發。為了確保我們也能回報開發人員工具尚未開啟期間發生的問題，稽核網域會儲存最新問題，並在開發人員工具連線後立即發送問題。開發人員工具接著會收集並匯總所有問題。
CDP 也能讓 Puppeteer 等其他通訊協定用戶端接收及處理問題。透過 CDP 傳送的結構化問題資訊希望有助於並簡化與現有持續整合基礎架構的整合作業。如此一來，即使在部署頁面之前，也能偵測並修正問題！
未來
首先，進入「問題」分頁後，必須再顯示更多訊息。這項作業需要一段時間才能完成，尤其是因為我們要針對新增的每個問題，提供清楚實用的說明文件。我們希望日後的開發人員不必透過控制台，就能在「問題」分頁中尋找相關資訊！
此外，我們也正在思考如何將其他來源 (Chromium 後端) 的問題整合至「問題」分頁。
我們持續致力於讓「問題」分頁保持簡潔有力，同時提升可用性。我們今年推出多種搜尋、篩選和更完善的匯總功能。為使使用者回報的問題數量增加，我們正在調整問題類別。舉例來說，如果希望系統只顯示與近期淘汰項目相關的問題，可能就會發生上述問題。我們也考慮新增延後功能，方便開發人員用來暫時隱藏問題。
為協助解決問題，我們希望讓使用者能夠更輕鬆地找出網頁的哪個部分觸發問題。具體來說，我們正在設法分辨及篩選問題是否確實與網頁 (即第一方) 完全與您嵌入的資源觸發的問題，但問題並非直接由您掌控 (例如廣告聯播網)。首先，您可以在 Chrome 第 86 版中隱藏第三方 Cookie 問題。
如果你對「問題」分頁有任何改善建議，歡迎提交錯誤給我們！
下載預覽管道
考慮使用 Chrome Canary 版、開發人員版或 Beta 版做為預設開發瀏覽器。這些預覽管道可讓您存取開發人員工具的最新功能、測試最先進的網路平台 API，並在使用者使用之前就在網站上發現問題！
與 Chrome 開發人員工具團隊聯絡
使用下列選項，討論文章的新功能和異動，以及其他與開發人員工具相關的事項。
- 請透過 crbug.com 提交建議或意見回饋。
- 如要回報開發人員工具的問題，請在開發人員工具中依序點選「更多選項」圖示
>「說明」 >「回報開發人員工具的問題」。 - 在 @ChromeDevTools 張貼推文。
- 歡迎對開發人員工具的 YouTube 影片或開發人員工具秘訣 (YouTube 影片) 提供意見。