整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
HTTP是一個域，有請求和回復。但如果我們把一個叫做car的成員放進HTTP，那么我們就不能再叫它HTTP了。在這個案例中，這個類變得很混亂。
public is {
/* methods for a car */
public void gas();
public void brake();
/* methods for an HTTP client */
public (String param);
示例2: 詞語的連接
一個普遍的模式是在類名后面加上Builder或者其它er結尾的詞。比如：. , , , , .
從名字上解析，我們可得到三層意思。
類名里的動詞Build，表示程序上這是一個類中包含有過程，具有復合功能；
它有兩個內在的、隱藏的實體，一個User一個Builder，所以可能會有違反封裝原則的危險；
Builder可以訪問User的內部工作機制，因為Builder和User就是相互纏繞的啊。
這就像是一個工廠模式。當這個類在濫用代碼庫的時候，我們的示例就會帶來問題。需要提醒的是，在工廠模式里，我們并不需要創建一個類。應用的()就可以很好地實現工廠模式。
示例3: Base
讓我們來看一些真實的示例。第一個I18n Ruby gem（為了簡潔起見，只提供類和方法的名字）：
class Base
def config
def
?(locale)
def
end
在這里，Base這個類沒有表達任何含義。它可以設置（）、翻譯（），以及判斷locale是否可得（）。它做的是一些不同的、無關聯的事情。
示例4: 取名對設計的指導意義
當我們討論到這些類名是如何影響我們的設計時，有一些例子。以下的例子引起了我們的興趣：
def
def
def
def
def
def
def
end
這個名字表示這個類的功能是提醒人們接收新聞發布信息。
但是,和，這些很明顯地是在說其它的事情，這就使得這個類名不是那么理想。把以上三個放進一個的類里，就會使類更加清晰明了，便于新人理解。
Class
def
def
def
def
end
end
示例5: 怪獸名字們
Spring框架里有一些例子，因為成員太多，所以起了一些怪獸一樣的類名。以下是一個：
{
public ()
public Object ()
public ()
public void (String )
public void (ry)
示例6:一個好名字的例子
壞名字的例子已經夠多了，在D3’sarc()可以找到好的取名例子，比如：
export default () {
/* ... */
arc. = () { /* ... */ }
arc. = () { /* ... */ }
arc. = () { /* ... */ }
arc. = () { /* ... */ }
arc. = () { /* ... */ }
arc. = () { /* ... */ }
arc. = () { /* ... */ }
arc. = () { /* ... */ }
return arc;
這里的所有的方法都表達了一個意思：它們都表示了圓弧的組成。我特別欣賞下面這張圖，清晰明了。
方法1：分解
什么時候使用:這個類找不到好的名字，但是你對各成員已經有了獨立的概念，這時候你想為這些小組取個好名字。
分成兩步：
識別概念
對它們進行分解
在坐便器+床這個場景中，我們把床推到左邊、坐便器推到右邊。這樣，我們就有了不同的事物，我們可以自然而然地給出不同的命名。
當你不能為一些事物給出好的名字時，可能在你面前的不止一件事物；目前你所知道的，給不同的事物命名很難。當你遇到麻煩的時候，試著分解你面前的事物。
示例
我們有一個未命名的類，包含了request、、headers、URLs、body、caching和timeout.把所有的成員從主類(main class)中拉出來，我們就有了Request、、Headers、URLs、、Cache、Timeout等等。如果我們所擁有的只是這些類的名字，我們可以非常肯定我們是在處理一個網頁請求。對于網頁請求一個很好的命名就是。
當這個代碼很難取名，不要首先想到整體！不要！想一想部分。
方法2：發現新概念
什么時候使用:當類不簡單或者不連貫。
發現新概念需要商務領域的知識。當軟件與商務使用相同的術語時，一切就進行了統一，不同領域的專家用著同一種語法。
示例1：將多種元素封裝于一個新概念中
曾經，有個公司幾乎要丟失一單大合同，為什么呢？因為那個團隊在開發新功能和問題處理方面，速度特別慢。
這個市場電子商務為不同國家的學生提供不同規則的多個支付網關，需求確實比較復雜。當我讀到支付代碼的時候震驚了，這是有多么復雜啊。代碼里面還有相當一部分依賴條件，包括：User,, , , , ,，等等。這個巨大的構造函數使得他們很難再添加新規則，因為添加任何一條規則都會打破其他規則，并需要去改動網管適配代碼。
這個問題甚至影響到了支付之外的服務。為了聚集消息類數據，他們給學生發送了郵件。技術支持有自己獨立的屏幕來看數據的第三次匯聚，除了這個特別的用到了名為類的地方（類名也就是本義）。
于是，我們不得不做點什么，來挽救這個架構缺陷。
處理這個問題，我想到了一些主意：我需要你( )為我處理一些支付細節。如果我是一張課桌，或許我需要把這些發票幫我整理好。所以說如果我創建一個名為 invoice的類，僅用來處理這些細節信息的匯聚，那么網關是不需要知道那些細節的，因為invoice會處理的，對嗎？與其注入無數個對象，我是否可以嘗試只傳遞一個給你？
Invoice這個術語之前從來沒有應用過。我們花了一個月的時間進行重組，然后我們就能夠更為靈活地對代碼進行改動。Invoice是一個很好的實例，它描述了匯聚的概念而且大多數人都能看懂。最終解決方案是向Gateway單獨注入了Invoice類作為接口，用于屏蔽其他更多類。
好的命名不僅僅是優美的詞匯，而是要用精準的語言去表達代碼的內涵。
示例2： 根據業務領域的調整命名
在一個未開發的拼車項目中，我們從頭設計我們的系統。在對其它交通方案的研究中，對于某人在某天從某處出發到某目的地的這一旅行，最合適的詞是trip；而這一些旅行的人，就被稱為ride。我們打印了一個詞匯表，這樣公司的人就可以討論并且分享使用這些共同的詞匯。
但產品發布之后，我們的客戶總是把我們的trips稱為rides。很快，我們就在將客戶的請求轉換為我們需要做的事情上，產生了問題。痛定思痛，我們覺得是時候該把trips改變為rides、rides改變成。這樣就解決了一個公司說著兩種不同語言的問題。
示例3：抽象級別
一個人說，移動右腿然后左腿再右腿，另一個說走路。兩者都是一樣的意思，但后者說法更抽象。
理想情況下，當代碼越來越接近其公共API，它越接近于企業術語。隨著它接近數據庫和金屬，它會使用更多的計算機術語。在這之間，抽象程度逐步降低。
在一家公司中，一個業務人員會說，所以例如（）這樣的一個名字，將在公共API比（）更說得通。在一家擁有更多技術服務的公司中，后者的表達方式也足夠清楚。
二，考慮特異性。（）是非常具體的，因為（）是通用的，可以用于或基本上涉及HTTP的任何內容。一個通用名稱可以輕易地被重復使用，會導致含義不清晰。這就解釋了為什么框架代碼與商業軟件代碼有如此大的區別。
Example 4: 概括
很久以前，一個CMS有數據庫表的新聞，歷史，視頻，文章，頁面等。他們大多數有相同的列，標題，摘要，文本。有額外的屬性例如url（嵌入YouTube）和有adate屬性的歷史，所以網頁會顯示一年的歷史事件列表。所有這些表格看起來都是副本，在這里和那里有一些差異，如果要添加新功能，就需要重寫大量樣板。
我拆散了所有那些表，整合進一個類，名為，并用一個外部指針指向一個表格，名為section，包含新聞，歷史，視頻等清單。現在，一段代碼的就足夠了。幾年后，一個朋友不得不寫一個小的CMS，我建議他說，我把所有這些表折疊成一個被稱為的外鍵，指向一個叫做“”的表，其中列出了相同的方法。一旦管理content的表單完成，它花費1/N的時間來執行，因為對于同一類型的每個新的部分來說，都是一樣的。
通過命名的方式將過程通用化，會在很大程度上提高生產力。新聞是一個Content,文章是一個Content。歷史是一個Content。所有這些都可以共享相同的屬性嗎？是。那調查是不是Cintent？哦，不，不是Content。
方法三：分組標準
什么時候使用：當名字很好，但他們不能很好地相配時。
組件可以通過各種標準進行分組，包括物理性質，經濟性，情感性，社會性和軟件中最常用的功能。相框根據情感方面分組，而產品則根據經濟動機分組。沙發和電視留在同一個房間，根據功能標準分組在一起，因為它們具有相同的功能或提供休閑的相同目的。
在軟件中，我們傾向于按功能對組件進行分組。列出你的項目文件，你可能會看到像 /，models /， /， /等等。然而，有些時候，這些分組并不讓人舒服，這就是時候來重新評估模塊結構了。
示例：按策略分組
一個用于自動化文檔操作的庫（如API藍圖）根據代碼生成規范文件，lints所述文件（保證格式正確）并上傳到云（如S3）。
根據文件格式，將自動進行各種后續決定。選擇API藍圖將會選擇不同的linter，不同的測試器和不同的API 轉換器。這里的關鍵詞策略是基于一個輸入來組合所有這些不同的功能。此后，該庫包括一個稱為策略的模塊（或名稱空間），該模塊將文件格式，linter，文檔測試器和存儲供應商組合在一起。這使得庫可以將業務核心策略中的普通操作文件（如上傳者，解析器和命令行）分開。
利用上下文
每個應用程序都有不同的上下文，同樣的，其中的每個模塊，它們內的每個類，到每個功能也是這樣。User這個名字可以單獨表示系統用戶，也可能是數據庫表或者第三方服務憑證。lib/billing/user 與lib/booking/user不同，但仍然是用戶。
想象一下，每個容器，如模塊，都是一個bucket。在其中，組件被封裝，與外界絕緣。你可以自由命名這些類，無需為一些尋常的事物去創建出生僻的名稱。
一個在整體式架構（一個大容器，其中有一些小容器）中的微服務（許多獨立的容器）的強有力的論據是，它強制限制每個服務中的責任，因為你無法輕松地將完全不相關的事情互相糾纏在一起。 內部的幾張同能，內預訂功能等等。在一個單一的架構中，這些相應的服務名稱可以是簡單的模塊名稱，但并不是每個人都會恪守原則保持代碼井井有條的。
示例：命名空間
馬克正在建立一個需要生產成千上萬條廣告的廣告平臺，然后發送到AdWords(谷歌)，臉書和必應，所有這些都通過圖形用戶界面進行管理。
馬克從一個稱為Ad的實體開始，很快開始膨脹。AdWords的廣告有和，臉書不會，而必應只有。他需要想辦法分裂他的實體。他思考不同的語境，以及如何利用語言的命名空間來表達這一點。他想出了以下結構：
?API :: Ad：廣告的HTTP端點將具有自己的自定義屬性，因此序列化邏輯存在于此處。
詞語可以意味著不同的東西，這取決于上下文，當我們利用上下文時，我們可以為組件選擇更簡單的單詞。在這個例子中，我們不需要復雜的過程就能找到這些組件名稱，因為它們是一回事，廣告。
無意詞和新詞
年復一年，名字也在發展并被賦予獲得新聞的含義。新詞不斷涌現，填補空缺。
助手（helper）：助手是支持應用程序的主要目標的功能。但是，那么定義應用程序的主要目標是什么？應用程序中的所有內容都支持應用程序的主要目標。
在實踐中，它們被集中在一個非自然的分組中，為一些其他混雜的，常用的操作提供可重用性。他們傾向于Feature Envy，他們需要訪問另一個組件的內部數據來工作。他們是找不到正確名稱東西的借口。
基礎：名為Base的類是很久以前在C＃中指定繼承的慣例，缺少一個更好的名稱。例如，汽車和自行車的父類將是Base而不是Vehicle。
盡管微軟的建議避免了這個名字（Cwalina，2009），但它顯然通過影響了了Ruby界。到目前為止，我們仍然將Base看作開發人員找不到名稱的類名。
Base的變體包括。例如，JSON Ruby gem 的具有解析（parse），生成（），加載（load）和jj的方法，但是常見的是什么意思呢？
任務：在社區有一個習慣來調用異步函數，叫tasks。它從task.js開始，即使原始庫不存在，該術語也被使用。
團隊中的每個人都明白嗎？如果真是那樣就好了。但是，當一個某人新加入團隊，遇到了和60年代以來存在的已然被拋棄在垃圾中命名法，會發生什么情況呢？
我在一個項目中工作，猜一下這個類的名字，亞特蘭大。是的，亞特蘭大。真見鬼，沒人說的清楚為啥叫那名字。
溝通
“現實僅存在于人的思想，而非其他任何地方。”喬治·奧威爾（George Orwell）
我認為溝通交流的做法是一個利他主義的行為，我們提高技能的努力與我們對別人的關心有關。我們希望人們容易理解，我們想要消除矛盾和障礙。
其次，我們希望別人了解我們。令收到消息的人理解這條消息是發件人的責任，如果能夠接受這個觀點，我們營造一個共情的環境，一個雙贏的局面。沒有任何借口不去刻意練習我們的溝通技巧 - 除非你住在叢林中。
隨著寫作，我們優化閱讀，練習共情等方面的技巧可能是很辛苦的。但是，正如生活中的一切，熟能生巧是最樸素的真理。
書目提要：
Cwalina, . 2009. Design : , Idioms, and for .NET , Second Edition. Boston: Pearson , Inc. 206.
Evans, Eric. 2003.Domain-Driven Design: in the Heart of . Boston: Addison-Wesley .
掃碼報名Strata Data 大會
大數據文摘專享優惠截至5月5日
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
