HTTP是一个域，有请求和回复。 但是如果我们把一个叫car的成员放入HTTP中，那么我们就不能再称它为HTTP了。 在这种情况下，班级变得相当混乱。
是 {
/* 对于汽车 */
无效气体（）；
无效刹车（）；
/* 对于 HTTP */
（参数）；
示例2：单词连接
常见的模式是在类名后面添加 er 或其他以 er 结尾的单词。 例如：。 ,,,,,.
分析这个名字，我们可以得到三个层次的含义。
类名中的动词 Build 表明以编程方式这是一个包含过程并具有复合函数的类；
它有两个内部隐藏实体，一个是User，一个是User，因此可能存在违反封装原则的危险；
你可以访问User的内部工作机制，因为它和User是相互交织的。
这就像工厂模式。 当此类滥用代码库时，我们的示例就会产生问题。 需要提醒的是，在工厂模式中，我们不需要创建类。 Applied()可以很好的实现工厂模式。
示例 3：基础
让我们看一些现实生活中的例子。 第一个 I18n Ruby gem（为了简洁起见，仅给出了类和方法名称）：
类基类
定义
定义
定义
结尾
这里，Base类不表达任何含义。 它可以设置()、翻译()、判断是否可用()。 它做了一些不同且不相关的事情。
例四：命名对于设计的指导意义
当我们讨论这些类名如何影响我们的设计时，这里有一些例子。 以下例子引起了我们的兴趣：
定义
定义
定义
定义
定义
定义
定义
结尾
从名字就可以看出这个类的功能是提醒人们接收新闻发布信息。
然而，和，这些显然是在谈论其他事情，这使得这个类名不太理想。 将以上三者放在一个类中，将使类更加清晰，更容易让新人理解。
班级
定义
定义
定义
定义
结尾
结尾
示例 5：怪物名称
框架中有一些示例具有怪物类名称，因为它们的成员太多。 这是一个：
()
()
()
空白 （ ）
无效（ry）
示例 6：好名字的示例
坏名字的例子已经够多了。 好的名称示例可以在 D3'sarc() 中找到，例如：
() {
/* ... */
弧。 = () { /* ... */ }
弧。 = () { /* ... */ }
弧。 = () { /* ... */ }
弧。 = () { /* ... */ }
弧。 = () { /* ... */ }
弧。 = () { /* ... */ }
弧。 = () { /* ... */ }
弧。 = () { /* ... */ }
弧;
这里所有的方法表达的意思都是一样的：都是代表弧的组成。 我特别喜欢下面这张图，清晰明了。
方法一：分解
何时使用：你找不到这个类的好名字，但你已经对每个成员有了独立的概念，并且你想给这些组一个好名字。
分为两步：
识别概念
把他们分解
在厕所+床的场景中，我们把床推到左边，厕所推到右边。 这样，我们就可以自然地为不同的事物赋予不同的名称。
当你无法给某件事起个好名字时，你面前可能有不止一件事； 就目前你所知，命名不同的事物是很困难的。 当你遇到困难时，尝试打破你面前的困难。
例子
我们有一个未命名的类，其中包含 、 、 URL、 body 和 。 从主类中拉出所有成员，我们有 、 、 URL 、 、 Cache 等等。 如果我们拥有的只是这些类的名称，那么我们就可以非常确定我们正在处理网络请求。 网页请求的一个好名字是 。
当代码难以命名时，不要先考虑整体！ 不想！ 想想零件。
方法二：发现新概念
何时使用：当课程不简单或不连贯时。
发现新概念需要业务领域的知识。 当软件和业务使用相同的术语时，一切都是统一的，不同领域的专家使用相同的语法。
示例 1：将多个元素封装在一个新概念中
曾几何时，一家公司差点失去了一份大合同。 为什么？ 因为该团队在开发新功能和解决问题方面特别缓慢。
这个市场的电商为不同国家的学生提供了多种不同规则的支付网关，需求确实很复杂。 当我阅读付款代码时，我对它的复杂性感到震惊。 代码中存在相当多的依赖条件，包括：User、、、、、、等。这个庞大的构造函数让他们很难添加新的规则，因为添加任何规则都会破坏其他规则并需要更改网络管理适配代码。
这个问题甚至影响到支付以外的服务。 为了汇总消息数据，他们向学生发送了电子邮件。 技术支持有自己独立的屏幕来查看数据的第三次聚合，除了这个特殊使用了一个地方，叫做类（类名就是本意）。
因此，我们必须采取一些措施来挽救这个架构缺陷。
为了解决这个问题，我想出了一些想法：我需要你（ ）为我处理一些付款细节。 如果我是课桌，也许我需要有人为我整理这些发票。 因此，如果我创建一个名为只是为了处理这些详细信息的聚合的类，那么网关不需要知道这些详细信息，因为它将被处理，对吗？ 我可以尝试只向您传递一个对象，而不是注入无限数量的对象吗？
这个术语以前从未被应用过。 我们花了一个月的时间进行重组，然后我们就能够更灵活地对代码进行更改。 这是一个很好的例子，描述了收敛的概念，并且大多数人都能理解。 最终的解决方案是注入一个单独的类作为接口，屏蔽更多其他类。
一个好的命名不仅仅是一个优美的词汇，更是一种表达代码内涵的精确语言。
示例2：根据业务领域调整命名
在一个新建的拼车项目中，我们从头开始设计我们的系统。 在对其他交通选择的研究中，表示某人在某一天从某个地方到某个目的地的旅行最合适的词是“trip”； 而这些出行的人，就叫做游程。 我们打印了一个词汇表，以便公司内的人员可以讨论和分享常用词汇。
但产品发布后，我们的客户总是称我们的旅行为游乐设施。 很快，我们在将客户的要求转化为我们需要做的事情时遇到了问题。 吸取经验后，我们觉得是时候把出行改成游乐，把游乐改成游乐了。 这解决了公司使用两种不同语言的问题。
示例 3：抽象级别
一个人说，移动你的右腿，然后移动你的左腿，然后移动你的右腿，另一个人说，步行。 两者意思相同，但后者更抽象。
理想情况下，随着代码越接近其公共 API，它就越接近企业术语。 随着它越来越接近数据库和金属，它使用了更多的计算机术语。 在此期间，抽象级别逐渐降低。
在公司中，业务人员会说，所以像 () 这样的名称比公共 API 中的 () 更有意义。 在技术服务较多的公司，后者表达得足够清楚。
其次，考虑特殊性。 () 非常具体，因为 () 是通用的并且可以用于或基本上涉及 HTTP 的任何内容。 通用名称很容易被重复使用，导致含义不清楚。 这解释了为什么框架代码与商业软件代码如此不同。
4：概括
很久以前，CMS 拥有新闻、历史、视频、文章、页面等数据库表。其中大多数具有相同的列、标题、摘要、文本。 还有附加属性，例如 url（嵌入）和带有 adate 属性的历史记录，因此网页将显示一年的历史事件列表。 所有这些表看起来都像副本，到处都有一些差异，如果要添加新功能，则需要重写大量样板文件。
我将所有这些表拆成了一个类，称为，并使用外部指针指向一个表，称为，包含新闻、历史、视频等列表。目前，一段代码就足够了。 几年后，一位朋友必须编写一个小型 CMS，我建议他将所有这些表折叠到一个名为“”的外键中，该外键指向一个名为“”的表，该表列出了相同的方法。 一旦托管表单完成，执行需要 1/N 时间，因为对于同一类型的每个新部分都是相同的。
通过命名来概括流程将在很大程度上提高生产力。 新闻是其一，文章也是其一。 历史就是其中之一。 所有这些都可以共享相同的属性吗？ 是的。 这是调查吗？ 哦，不，不是。
方法三：分组标准
何时使用：当名称很好，但它们组合在一起却不太合适时。
组件可以按各种标准进行分组，包括物理属性、经济、情感、社交和软件中最常用的功能。 相框根据情感方面进行分组，而产品则根据经济动机进行分组。 沙发和电视保留在同一个房间内，根据功能标准分组在一起，因为它们具有相同的功能或提供放松的相同目的。
在软件中，我们倾向于按功能对组件进行分组。 列出您的项目文件，您可能会看到类似 /、/、/、/ 等内容。 然而，有时这些分组感觉不太舒服，是时候重新评估模块结构了。
示例：按策略分组
用于自动化文档操作的库（例如 API 蓝图）根据代码生成规范文件，对所述文件进行 lints（保证格式正确）并将其上传到云端（例如 S3）。
根据文件格式，会自动做出各种后续决策。 选择API蓝图将选择不同的测试人员和不同的API转换器。 这里的关键字策略基于结合了所有这些不同特征的一个输入。 此后，该库包含一个名为 Strategies 的模块（或命名空间），它结合了文件格式、文档测试器和存储提供程序。 这使得该库能够将上传器、解析器和命令行等常见操作文件与核心业务策略分开。
利用上下文
每个应用程序都有不同的上下文，其中的每个模块、其中的每个类以及其中的每个函数也是如此。 User这个名字可以单独代表一个系统用户，也可以是一个数据库表或者第三方服务凭证。 lib//user 与 lib//user 不同，但仍然是用户。
想象一下，每个容器就像一个模块一样，都是一个。 其中，组件被封装并与外界隔离。 您可以自由地命名这些类，而不必为常见的事物创建奇特的名称。
在整体架构（一个大容器，里面有几个较小的容器）中微服务（许多独立的容器）的一个强有力的论点是，它强制限制每个服务内的责任，因为你不能轻易地将一个完全不相关的东西纠缠在一起与彼此。 一些内部卡功能、内部预订功能等。在单一架构中，这些对应的服务名称可以是简单的模块名称，但并不是每个人都会坚持保持代码组织的原则。
示例：命名空间
Mark 正在构建一个广告平台，需要制作数千个广告并将其发送到（Google）、Facebook 和 Bing，所有这些都通过图形用户界面进行管理。
Mark 从一个名为 Ad 的实体开始，该实体很快开始膨胀。 Facebook 和 Facebook 有广告，但只有 Bing。 他需要找到一种方法来分裂他的实体。 他思考不同的上下文以及如何使用语言的名称空间来表达这一点。 他提出了以下结构：
• API::Ad：广告的HTTP 端点将有其自己的自定义属性，因此序列化逻辑位于此处。
根据上下文，单词可以表示不同的含义，当我们利用上下文时，我们可以为组件选择更简单的单词。 在这个例子中，我们不需要一个复杂的过程来找到这些组件名称，因为它们是同一个东西，AD。
无意识的单词和生词
年复一年，名字不断演变，并被赋予获取新闻的含义。 新词不断出现以填补空白。
Helpers()：助手是支持应用程序主要目标的函数。 那么定义应用程序的主要目标是什么？ 应用程序中的所有内容都支持应用程序的主要目标。
在实践中，它们以不自然的方式分组在一起，以便为一些其他杂项的常用操作提供可重用性。 当他们需要访问另一个组件的内部数据才能工作时，他们往往会感到嫉妒。 它们是无法为某些事物找到正确名称的借口。
Base：名为 Base 的类是很久以前在 C# 中指定继承的约定，因为缺乏更好的名称。 例如，Car 和 Bicycle 的父类将是 Base 而不是 。
尽管 Microsoft 的提案避免使用这个名称（2009 年），但它的采用显然对 Ruby 社区产生了影响。 到目前为止，我们仍然将 Base 视为开发人员找不到的类名。
Base 的变体包括。 例如，JSON Ruby gem 有 parse、generate、load 和 jj 方法，但常见的是什么意思呢？
任务：社区中有一个习惯，调用异步函数称为任务。 它以tasks.js 开头，即使原始库不存在，也会使用该术语。
团队里的每个人都明白吗？ 如果真是这样就好了。 但是，当团队的新成员遇到自 20 世纪 60 年代以来一直被丢弃的术语时，会发生什么情况呢？
我正在做一个项目，猜猜班级的名字，亚特兰大。 是的，亚特兰大。 哎呀，没有人能告诉它为什么叫这个名字。
交流
“现实只存在于人的头脑中，而不存在于其他地方。” 乔治·奥威尔 ( )
我相信沟通的实践是一种利他行为，我们提高技能的努力与我们对他人的关心有关。 我们希望它易于人们理解，我们希望消除矛盾和障碍。
其次，我们希望别人理解我们。 发送者有责任使接收消息的人理解该消息。 如果我们能够接受这个观点，我们就能创造一个共情的环境和双赢的局面。 没有理由不刻意练习我们的沟通技巧——除非你住在丛林里。
除了写作之外，我们还优化阅读、练习同理心和其他艰苦的技能。 但是，就像生活中的一切一样，熟能生巧。
书目摘要：
, . 2009. : , , 以及.NET , . ：，公司206。
埃文斯、埃里克. 2003.-：在.的心中。 ：- 。
扫描二维码报名参加数据大会
Big Data Digest 独家优惠将于 5 月 5 日结束
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。