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

閱讀本文大概須要 4 分鐘。

原文：http://t.cn/Eau2d0h

譯文：http://21cto.com/article/2093

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

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

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

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

一、對你的需求來講 「User」 幾乎歷來都不是一個好的描述。

二、「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 服務幾乎老是：

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

二、一個或多我的共同使用這個服務。

若是你一開始就把這些人做爲一個用戶，你將會陷入一個痛苦的世界。你沒法創建團隊模型，你沒法組建同時爲多人支付的模型，而後你就會開始改造你的系統。如今你在SaaS案例中學到了一課，咱們來看一看你的生活。

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

「Users」 是一個安全問題

「user」 這個單詞不只是業務邏輯的問題，它也致使了一系列安全問題。「user」 這個單詞如此的模糊以致於從根本上將兩個概念合併了：

• 一我的。
• 他們在軟件中的表明性。

爲了說明這個問題，假設你正在訪問一個居心不良的網站，在它服務器上的圖片致使了你的瀏覽器內存溢出。遠程網站控制着你的瀏覽器，而且開始將你的文件上傳到他的服務上。爲何它能這樣作？

由於瀏覽器是以系統用戶的身份運行的，它被認爲與人類身份的你相同，實際上大家是不一樣的。

你做爲’user’，不想上傳文件。可是系統的帳號也是‘user’，可以上傳文件，若是瀏覽器運行在你的帳號之下，他全部的行爲會被看成是你的意圖，也就是說是你讓它這麼作的，實際上不是。

這就是被稱爲Confused Deputy的問題。若是你使用「用戶」這個詞來描述兩個根本不一樣的東西，那麼這個問題就更有可能成爲你設計的一部分。

前期設計的價值

花更少的功夫處理相同的問題是成爲高產程序員的關鍵。使用模糊不清的概念好比「用戶」來組織你的軟件，將會話費大量時間和精力來解決將來發生的問題。一上來就開始編碼看起來是高產的，事實剛好相反。

下次你開始一個新的軟件項目時，花幾個小時預先肯定你的術語和概念：你仍然不會徹底正確，但你會作得更好。將來的你將感謝你所作的全部預防浪費的工做。

·END·

程序員的成長之路

路雖遠，行則必至

本文原發於 同名微信公衆號「程序員的成長之路」，回覆「1024」你懂得，給個讚唄。

回覆 [ 520 ] 領取程序員最佳學習方式

回覆 [ 256 ] 查看 Java 程序員成長規劃