寫代碼注意了，打死都不要用 User 這個單詞

當你意識到你在項目開始時做的輕量、簡單的設想竟然完全錯了時，你已經用了六個月的時間投入到這個項目上。

現在你需要解決這些問題，才能讓這個系統繼續運作下去，你發現你用在這個項目上的精力遠遠超出了你的預期，如果一開始就用正确的方式來做，就不會發生這樣的事。

今天，我要告訴你的是一個經常犯的錯誤，一個會給你帶來無窮無盡的問題的單詞，那就是“users”。

這個單詞有兩個最基本的錯誤：

1、對你的需求來說 “User” 幾乎從來都不是一個好的描述。

2、“User” 會導緻一個基本的設計安全缺陷。

“user” 的概念是模糊不清的，使用更精準的術語幾乎總是能起到更好的效果。

你沒有使用者

最開始，沒有任何一個軟體系統真的有使用者存在。乍一看“user”是一個好的描述，但是你稍微一想就會意識到你的業務邏輯實際上比這要複雜的多。

我會使用三個例子，從一個極端的情況出發。

機票預訂系統沒有“users”

我曾經給機票預訂系統寫過通路控制邏輯，下面隻是一小部分需求：

旅客可以使用預定記錄碼通過網站檢視預定資訊。

購買者可以通過信用卡号後四位數在網站上修改預訂資訊。

旅行社可以檢視和修改他們的預訂。

航空公司的值機人員可以根據角色和航空公司來檢視和修改預訂資訊，這需要旅客提供身份資訊。

不再一一列舉。一些與人類相關的基本概念是“旅客”，“代理”（網站也可是看作代理）和“購買者”。

“user”這個概念根本沒用，并且在許多請求中我根本不會使用這個單詞，舉個例子，我們的請求必須包括旅客和代理人的證件，而不是使用者的證件。

Unix 沒有 “users”

我們看一個不太一樣的例子。Unix （這些天被稱為POSIX）有使用者，他們可以登入并執行代碼。這樣看起來很不錯吧？我們深入看一下。

如果我們把所有都當作“users”的話，我們将會有：使用終端或者圖形界面登入的人

像郵件或者web伺服器這種系統服務也會以“users”的身份運作，例如nginx可以以httpd使用者運作。

在伺服器上經常會有多人共享一個管理者賬号用來SSH登入（例如，亞馬遜的Ubuntu虛拟機預設SSH賬号就是‘ubuntu’)

root 身份，和上面其他身份都不同。

上面四個是幾乎不同的概念，但是在POSIX上他們都是 “users”. 一會兒我們就會看到，把這些概念都稱為‘user’會導緻很多安全問題。

在操作上，因為POSIX的使用者模型邊界存在，我們甚至不能找到一種方式說“隻能讓 Alice 和 Bob 通過這個賬号登入”。

SaaS 服務提供商沒有 “users”

Jeremy Green 最近就使用者模型在SaaS中的應用在推特上發文，它第一次提醒了我寫下這篇文章，他的基本觀點是SaaS 服務幾乎總是：

1、某個組織中的一個人支付服務費用。

2、一個或多個人共同使用這個服務。

如果你一開始就把這些人作為一個使用者，你将會陷入一個痛苦的世界。你無法建立團隊模型，你無法組建同時為多人支付的模型，然後你就會開始改造你的系統。現在你在SaaS案例中學到了一課，我們來看一看你的生活。

但是這隻是衆多例子中的一個：“users”的概念太模糊了。如果你開始懷疑“user”這個詞，最終你可能發現最終你其實隻需要兩個概念：團隊（用來組織關系和支付）和成員（實際使用服務的人）。

“Users” 是一個安全問題

“user” 這個單詞不僅是業務邏輯的問題，它也導緻了一系列安全問題。“user” 這個單詞如此的模糊以至于從根本上将兩個概念合并了：

一個人。

他們在軟體中的代表性。

為了說明這個問題，假設你正在通路一個居心不良的網站，在它伺服器上的圖檔導緻了你的浏覽器記憶體溢出。遠端網站控制着你的浏覽器，并且開始将你的檔案上傳到他的服務上。為什麼它能這樣做？

因為浏覽器是以系統使用者的身份運作的，它被認為與人類身份的你相同，實際上你們是不同的。

你作為’user’，不想上傳檔案。但是系統的賬号也是‘user’，能夠上傳檔案，如果浏覽器運作在你的賬号之下，他所有的行為會被當作是你的意圖，也就是說是你讓它這麼做的，實際上不是。

這就是被稱為Confused Deputy的問題。如果你使用“使用者”這個詞來描述兩個根本不同的東西，那麼這個問題就更有可能成為你設計的一部分。

前期設計的價值

花更少的功夫處理相同的問題是成為高産程式員的關鍵。使用模糊不清的概念比如“使用者”來組織你的軟體，将會話費大量時間和精力來解決未來發生的問題。一上來就開始編碼看起來是高産的，事實恰好相反。

下次你開始一個新的軟體項目時，花幾個小時預先确定你的術語和概念：你仍然不會完全正确，但你會做得更好。未來的你将感謝你所做的所有預防浪費的工作。