[[245493]]

【51CTO.com快譯】一個項目你搞了六個月，突然你意識到一開始做出的一個小小的簡單假設完全錯誤。而現在你需要修復問題，同時保持現有系統正常運行;不用說，耗費的精力比當初一開始就弄好要多得多。

今天我想告訴諸位一個常見的錯誤，僅僅一個詞會給你帶來無盡的麻煩。我指的是“用戶”這個詞。

這個詞存在兩個基本問題：

1. “用戶”幾乎從來無法很好地描述你的需求。

2. “用戶”助長了一個基本的安全設計缺陷。

“用戶”這個概念含糊不清，建議你使用更準確的術語。

你沒有用戶

首先，沒有哪個軟件系統實際上有“用戶”。乍一看，“用戶”是很到位的描述，但一旦你更認真地分析，就會認識到你的業務邏輯實際上更復雜。

我們將考慮三個例子，先說一種極端情況。

航空公司預訂系統沒有“用戶”

我曾為一套航空公司預訂系統開發過訪問控制邏輯。以下是一小部分需求：

• 如果乘客有預訂號(PNR)，可以通過網站查看預訂。
• 如果購票者有信用卡號碼的***4位數字，可以通過網站修改預訂。
• 旅行代理人可以查看和修改通過其旅行社完成的預訂。
• 有了乘客的身份信息，航空登記代理人可以根據其角色和機場來查看和修改預訂。

不一而足。與人員對應的幾個基本概念是“乘客”、“代理人”(網站也可能是代理人)和“購票者”。“用戶”這個概念根本就沒用，我們根本沒有用這個詞――比如在許多請求中，我們要加入乘客和代理人的登錄信息(credential)。

Unix沒有“用戶”

不妨看一個全然不同的情況。Unix(如今名為POSIX)有用戶：用戶可以登錄并運行代碼。這似乎很好，是不是?但不妨仔細看一下。

如果我們果真經歷了所謂的用戶活動，我們有：

• 通過終端或圖形用戶界面登錄的人員。
• 還有以“用戶”的身份來運行的系統服務(比如郵件或Web服務器)，比如nginx可能以httpd用戶的身份來運行。
• 在服務器上，常常有多個人員共享的管理帳戶，這些人使用該“用戶”進行SSH連接(比如，ubuntu是運行Ubuntu的AWS虛擬機上的默認SSH帳戶)。
• root，它與上述任何一個都不完全相同。

這是四個截然不同的概念，但在POSIX中它們都叫“用戶”。正如我們稍后會看到的，將所有這些概念籠統稱之為“用戶”這個模糊概念可能會導致許多安全問題。

但就實際操作上，我們甚至沒有辦法在POSIX用戶模式的邊界內說“只有Alice和Bob可以登錄到共享的管理員帳戶。”

SaaS提供商沒有“用戶”

Jeremy Green最近在推文中提到了軟件即服務(SaaS)中的用戶模式，這促使我寫下了這篇文章。他的基本觀點是，SaaS服務幾乎總是有：

1.  一家企業組織中花錢購買服務的人。
2. 該企業組織中一個或多個實際使用該服務的人。

如果你一開始將這些人合并成一個“用戶”，就會陷入痛苦的深淵。你無法為團隊建模，也無法同時針對多個人為支付建模，現在你需要改造系統。

但這只是表明一個更廣泛問題的一個情況：“用戶”這個概念太模糊了。如果你一開始懷疑“用戶”這個詞，極有可能最終意識到你實際上至少有兩個概念：團隊(花錢支付和擁有所有權的單位)和團隊成員(實際使用服務的人) 。

“用戶”是安全問題

“用戶”這個詞不僅僅對業務邏輯來說是個問題：它還有嚴重的安全后果。“用戶”這個詞太含糊了，將兩個全然不同的概念混為一談：

• 人員。
• 人員在軟件中的表示。

想明白為什么這是個問題，假設你訪問了一個惡意網站，該網站托管了一個利用瀏覽器緩沖區溢出的圖片。遠程站點現在控制你的瀏覽器，開始將你的所有文件上傳到其服務器。為什么它能這么做?

因為你的瀏覽器作為你的操作系統這個“用戶”來運行，該“用戶”被認為與你這個人一樣，其實你是一種全然不同的“用戶”。你這個用戶不想上傳那些文件。操作系統帳戶(它也是用戶)可以上傳那些文件，又由于你的瀏覽器在你的用戶下運行，因此它的所有操作被認為是你想要執行的操作。

這就是所謂的困惑的代理問題(Confused Deputy Problem)。如果你使用“用戶”這個詞來描述兩個根本不同的東西是一回事，這個問題極有可能成為你設計的一部分。

預先設計的重要性

想成為高效的程序員，關鍵是花更少的精力完成同樣的工作。使用“用戶”這樣的含糊術語為軟件建模需要以后花費大量的時間和精力來修復。立即開始編寫代碼似乎很高效，但事實恰恰相反。

下次你開始搞新的軟件項目時，花幾個小時預先確定術語和概念：你仍然無法做到完全正確，但結果會好得多。將來你會慶幸自己避免了種種無為的勞動。

原文標題：Never use the word “User” in your code，作者：Itamar Turner-Trauring

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】