IT行業需要更好的命名嗎？

關鍵點

為什麼有合適的名稱很重要

在IT行業內命名欠佳的實例

命名欠佳或有漏洞的命名有什麼副作用

在團隊和公司里如何處理欠佳的命名

如何防止在未來出現不好的術語

在閱讀大量的文章、書籍和聽了會議發言之後，我常常問自己，我們在IT業內是不是總在使用適當的或一致的術語呢。我們從其他領域借鑒一些術語，這是一個相當好的方法，但是，有時我們會歪曲這些術語的含義，或與其他學科相比，我們沒有用一致的方式來使用這些術語。

在本文中我將分享一些不良術語的例子，並就為什麼這很重要以及如何處理不一致談談我的看法。我將就如何在組織內部和跨組織改善這種局面提出建議。

為什麼這很重要，什麼使命名如此重要

近年來，IT業已經開始被越來越多的潮流和風尚（如方法、框架）所驅動；IT學術會議的數量以指數級增加，相比以往，我們已經開始更多地通過軟體來表達我們的身份了。在技術飛速發展的大環境下，對使用合適的名稱、對精確術語的依賴，以及具有有機而可持續的發展就很有必要了。名稱反映了行業的質量和成熟度，使用不當會帶來混亂和誤解，有時會導致錯誤的期望。

架構——同時用於IT和建築業

在解釋架構在軟體中表示什麼之前，我將先來說說建築業中的兩個術語（相比軟體而言，建築業是個更為成熟的行業）：結構工程師（structural engineer）和架構工程師（architectural engineer）。結構工程師需要理解和計算建築的穩定性、強度和剛度，以確保它能承受是重力、風力和其他外力。他負責建築結構的完整性和一致性。另一方面，架構工程師負責基本的建築物特性，如照明、音響、通風、採暖、水暖、急救通道、消防和安全系統。他們需要把這些工作緊密結合在一起，使建築物牢固實用。

現在，讓我們回到軟體業。在這一背景下，架構表示的是什麼意思呢？

從ANSI / IEEE標準1471-2000定義來說，架構是「一個系統的基本組織，表現為組件、組件之間和組件與環境之間的關係以及設計和演變的指導原則。」。另一種定義，是我看到過的最短的，它最初是由Ralph Johnson提出的，後來被Martin Fowler所推崇，它將架構定義為「重要的東西（不管是什麼）」

基於與建築工程的類比，軟體架構師更像是結構工程師，而不是架構工程師。

也許，與建築領域保持一致，遵從同樣的術語會很好，但對於軟體人員來說，「架構（architecture）」這個詞的說法聽起來更具吸引力。

然而，有些人可能很難予以準確界定。在我的軟體架構職業生活中注意到，即使是經驗豐富的老手對軟體架構師的意義及其職責也有不同的理解。因此，在有些團隊中，軟體架構師的角色揉合了技術帶頭人的屬性；在這樣的情況下，前者（也就是軟體架構師）甚至是不存在的！技術帶頭人在架構方面所有東西的設計上都有所有權，包括結構、邊界、通信機制、整個系統與外部系統的介面，等等。這些混合的角色使技術分離模糊不清，可能會阻礙項目委派適當的職責給內部團隊中適當的人。還有一個額外的後果，它還會影響我們接受教育的方式，以及職業生涯的發展。

非功能需求和質量屬性

通常情況下，業務需求是對功能性和非功能性需求的深入挖掘。在這樣的背景下，非功能性需求是指性能、可用性、可擴展性、安全性、可用性等質量屬性。

但是，讓我們採用兩種方式去更好地了解一下隱藏在非功能性術語背後的是什麼：第一個方式是搜索詞典中的詞，第二個方式是達成它們的技術含義。

根據字典的解釋，「非」詞的意思是「不，沒有，不重要的，無價值的。」。基於這個定義，由此產生的問題是：因為它的語義含義是「毫無價值」，我們怎麼能把一些影響架構的東西稱之為「非」功能性呢？我們為什麼不應該把這些需求拋到一邊呢？因此，第一個解釋存在矛盾。

接下來使用第二種方法，所有的非功能性需求（如安全性、可用性）都是通過功能（如安全性通過加密功能，易用性通過嚮導功能）實現的，所以他們依賴於具體功能。這引出了第二個問題：如果一些東西是通過功能實現的，那麼我們如何把它們稱之為非功能呢？

如果參考產品的質量屬性（比如可管理性、可維護性、易用性和可用性等）與非技術性利益相關者討論非功能性需求會陷入困境，因為會出現一些混亂的情況，比如有些與可維護性相關的東西是通過可管理性實現的。這也是為架構師設的一個陷阱，為避免這種情況，他們必須進一步澄清的字面意思及其含義的細節，因為為實現一個質量屬性（如可維護性），可能意味著在產品設計需要對另一個質量屬性做出架構權衡（例如可管理性）。可能在產品的易用性和可用性上還會出現混亂的情況，它們經常被混用和濫用。

QA（質量保證）還是QC（質量控制）

幾乎在每個軟體團隊中都有稱之為「質量工程師」的成員。他們的角色主要是理解需求規格說明書並基於它們定義一組測試用例（比如，功能測試、接受測試、集成測試等），從而驗證產品和檢查可能的缺陷。如果我們通過定義來檢索QA和QC的含義，按照merriam-webster.com上給出的定義，會把QC理解為「旨在確保已制產品具備合格質量的一系列活動，比如設計分析和缺陷檢查」，而QA則理解為「系統化的評估程序和對產品、服務的全方位評估，或確認質量標準得以滿足的機制」。

基於這些定義，軟體開發團隊中負責定義測試用例和驗證產品的人多於QC工程師。這可能會導致問題。我就遇到過招聘人員把這搞混的情況，他按組織的QA職位檢索人才卻提供了QC工作，或者反之。有個朋友最近就遇到了這種情況，她受邀去討論QC的職位要求（比如定義測試用例和驗證產品），但其實她所具有的資質專用於QA（比如負責監控和確保公司過程符合ISO標準）。這兩個職位完全是兩碼事，他們可能在某種程度上會有所互補，但所有的知識和技能都是不同的。

不適當地使用QA和QC名稱還會導致團隊內對職責理解不到位或混亂的情況。

層——軟體和硬體的差異

層這個術語最初是在網路中引入的，此處的所有層旨在完成同一最終目的，它們只是處於不同的抽象層次：建立和支持網路中不同節點間適當的通信。例如，基於OSI棧，它們有七層（即物理層、數據鏈路層、網路層、傳輸層、會話層、表示層和應用層），每一層都服務於同一目標。抽象使每一層更恰當（比如，應用層的send()方法應基於多個更少的抽象和特定的API）。

在軟體中，層在每層抽象中不是互為補充的，不像網路中那樣。例如，數據訪問層（例如負責處理數據連接和CRUD操作）有特定的目的。其他層（比如業務層）不參與數據訪問層更高或更低層的抽象。他們主要的目的是隔離每層的職能，而不是用抽象的方式補完工作。Ralf Westphal就此主題做了一個很有意思的演講：「用軟體單元讓軟體設計充滿活力吧」。

微服務

近年來，微服務這個詞被在架構中得到了廣泛和大量的採用。它是自面向服務的體系結構（SOA）浮現出來的，因為遵循這個架構模式的應用遇到了一些問題。我喜歡引用Jonas Bonér的說法，「微服務其實只是穿上新衣服的SOA」。但是微服務這個術語的真正意思是什麼呢？按照字典的定義，它可能所談的是一個非常小的服務，或者「少量的」服務。在現實中，它是一個目標實現的服務，自成一體，獨立於其他實例和服務。現在的應用有著成百上千個服務，變得非常難以管理。一個可能的原因是，人們對實現微服務的方式有著不同的理解。沒有一個共同的、強大的定義，也沒有圍繞它們的最佳實踐。因為定義是有漏洞的，前綴的「微」加在「服務」上生硬牽強。我們一定要想出一個更好的詞來反映實際的需要。為了繞過SOA的問題，它在行業內得到了過多的關注和應用。Uber首席系統架構師在「微服務之後是什麼？」中描述了微服務暴露的許多現實問題。我個人認為，使用適當的定義以及強大的和標準化的指導（從架構的角度來看），我們會設計出更好的微服務架構。但從我們的錯誤中總結學習也不一定是壞事，因為錯誤並非不可逆轉，我們在未來再也不會重犯了。

組件

組件（像微服務一樣）是在定義這一方面存在問題的另一個術語。對於它有很多誤解，人們有時用包甚至對象來代替它。從軟體的觀點看，架構包含組件，但在代碼中這些組件實際表現為什麼呢，或類比為什麼呢？代碼級的任何實體都稱為組件？當然不是，因為這太含糊了。我喜歡Martin Fowler的定義：「組件是一個軟體的單位，它可以獨立更換和升級」。這個定義即沒有參考包，也沒有參考類，而是對組件自身的描述和及其自己的屬性。

當開發者在實現時遵從架構設計（例如使用組件圖）時，這種誤解就會產生重大影響了。如果「組件」這個術語是不精確規定（例如如何映射到代碼），實現較之最初的設計就會有缺失，可能會出現缺陷（例如以緊耦合、低內聚的組件，缺乏定義的API等而告終）。從一個軟體架構師的角度來看，當我在與其他技術上的利益相關者討論和使用組件這個術語時，我寧可從一開始就把它定義清楚：「在我們的上下文中組件代表的是什麼意思？在我們的架構中如何能清晰地識別一個組件？」否則，我們所指的就有可能是不同的事物。

弱代假說

在java虛擬機內，內存設計和垃圾收集器試探演算法是基於弱代假說的，它說的是：

絕大多數的對象不會被長時間引用，這些對象在其Young期間就會被回收。

很老的對象(生存時間很長)和很新的對象(生存時間很短)之間很少存在相互引用的情況。

但是，假說一詞表示什麼？從科學的角度看，它指的是一個想法或一個解釋，需要通過研究和實驗予以驗證。在科學領域之外，假說一詞用得更為寬鬆，它常常關於的是對一個假設的猜測或以該假設為依據，因為它無法被證明（如編程語言仍然不是科學）。可能在這種語境下，它更應該被稱之為猜測或前提條件，而不是假說，這可能不影響軟體開發人員使用和實現這個概念的方式，但使用正確的術語肯定有利而無害。

軟體應用命名

有些應用軟體可能因為它們的名字而令人困惑。例如，有一個應用程序命名為協議緩衝區（Protocol Buffers），對它的說明是：「針對序列化結構化數據的語言無關、平台無關、可擴展性的機制」。這裡的術語「協議」令人困惑，因為它（如網路協議）通常指的是設備發現、識別和相互聯繫的機制，以及定義在通信中如何包裝數據的一套規則。基於上述，我們可以很容易地發現協議緩衝區不是網路上的「協議」，而只是在應用層處理結構化數據一種方式。為避免混亂，遵循行業的命名標準可能會更好。

如何在你的組織中處理和改善不好的術語

為了克服這些矛盾，在聯想術語之前，我們可能需要搜索和閱讀更多有關的基礎知識（例如使用字典）。我們可以從我們的組織（團隊內）開始入手，可以創建語義指南/詞典（例如通過定義和例子）與各方分享，即一種從術語的立場去看的技術雷達，它可以為我們帶來更正確和更充分的理解。在我的項目中我就創建了一個，我用來與所有利益相關者交流，使我們彼此之間的溝通更容易了。例如，它改善了業務分析師和開發人員之間的溝通，尤其是在定義業務規格說明書時，因為分析師可能會增加些參考資料到這些指南中（例如在用戶故事的描述中）。同時在架構展示期間和內部技術文檔中，我們總會參考這個雷達，從而對我們的環境達成共識。擁有一個基線很重要，一起討論時有個共同的參考（如技術和非技術的利益相關者）會使交流更容易，最終它會加快整個開發過程。

另外，除了澄清術語的定義和例子，使用SMART目標也很重要（例如明確的、可衡量的、可實現的、現實的、與時間相關的），從而避免模糊的情況。例如，在你的項目或組織內部對於什麼是微服務有一個適當的定義是不錯的，但可能還不夠。最好能細化語境，在哪種情況下，微服務將是更好的選擇，如何衡量一個服務是否真的只實現了一個單一的目的，創建另一個微服務而不是擴展現有的那個有多麼的可行，如何驗證這個微服務與其他微服務之間的隔離和集成，增加新的服務對整體架構有怎樣的影響，開發和維護這個服務會有多少成本，等等。

在技術的環境下，遵循定量的、可衡量的、可測試的、可證偽的原則去捕捉和指定的一切。否則就難以開發，驗證和證明。

分布式團隊中的術語

在分布式團隊中工作是一個更大的挑戰，但在我看來，處理術語的技術也同樣如此。Eric Evans和之後的Martin Fowler提出了「通用語言」一詞（與特定領域無關），作為一種具有不同背景和來自不同文化的利益相關者之間的交流方式。我想說，在處理不佳的術語時，我們可以採用同樣的技術；我們需要定義在我們的環境中（經濟、政治、文化和技術）有意義的術語集（適當的定義，例子，等），並和不同的團隊分享。這些要作為一種內部辭彙來用，或作為一種有界限的語言，並又能適當表達我們的業務。

最終的結論

名字體現了我們看待事物和自我發展的方式的教育和影響。有適當的名稱，會帶來有機的產業演進；大家將停止使用不佳的術語，IT內的質量和標準化程度將持續提升。

關於作者

balosin Ionut是LUXOFT的軟體架構師，有10年的各種業務應用經驗，熱衷於性能調優和軟體架構的話題。他經常出席技術峰會並演講和進行技術指導。

查看英文原文：Article: Does IT Industry Need Better Namings?

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！