当你意识到你在我的项目开始时做的轻量、简略的构想居然齐全错了时，你曾经用了六个月的工夫投入到这个我的项目上。当初你须要解决这些问题，能力让这个零碎持续运行上来，你发现你用在这个我的项目上的精力远远超出了你的预期，如果一开始就用正确的形式来做，就不会产生这样的事。
明天，我要通知你的是一个常常犯的谬误，一个会给你带来无穷无尽的问题的单词，那就是“users”。
这个单词有两个最根本的谬误：
1. 对你的需要来说“User”简直素来都不是一个好的形容。
2.“User”会导致一个根本的设计平安缺点。
“user”的概念是模糊不清的，应用更精准的术语简直总是能起到更好的成果。
你没有使用者
最开始，没有任何一个软件系统真的有使用者存在。乍一看“user”是一个好的形容，然而你略微一想就会意识到你的业务逻辑实际上比这要简单的多。
我会应用三个例子，从一个极其的状况登程。
机票预订零碎没有“users”
我已经给机票预订零碎写过访问控制逻辑，上面只是一小部分需要：
1. 旅客能够应用预约记录码通过网站查看预约信息。
2. 购买者能够通过信用卡号后四位数在网站上批改预订信息。
3. 旅行社能够查看和批改他们的预订。
4. 航空公司的值机人员能够依据角色和航空公司来查看和批改预订信息，这须要旅客提供身份信息。
不再一一列举。一些与人类相干的基本概念是“旅客”，“代理”（网站也可是看作代理）和“购买者”。“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 的问题。如果你应用“用户”这个词来形容两个基本不同的货色，那么这个问题就更有可能成为你设计的一部分。
后期设计的价值
花更少的功夫解决雷同的问题是成为高产程序员的要害。应用模糊不清的概念比方“用户”来组织你的软件，将会话费大量工夫和精力来解决将来产生的问题。一上来就开始编码看起来是高产的，事实恰好相反。
下次你开始一个新的软件我的项目时，花几个小时预先确定你的术语和概念：你依然不会完全正确，但你会做得更好。将来的你将感激你所做的所有预防节约的工作。
起源：21cto.com/article/2093