程序員分層怎麼辦

㈠ java程序員，工作了快倆年了，現在不想做程序員了，太累了，怎麼辦，想改行做什麼好

程序員 就是累.如果其它的你還有比較感興趣的職業 ，你可以轉行

㈡ 軟體架構入門-分層架構、事件驅動、微服務架構和雲原生架構

軟體架構（software architecture）就是軟體的基本結構。

合適的架構是軟體成功的最重要因素之一。大型軟體公司通常有專門的架構師職位（architect），只有資深程序員才可以擔任。

O'Reilly 出版過一本免費的小冊子《Software Architecture Patterns》（PDF）， 介紹了五種最常見的軟體架構，是非常好的入門讀物。

軟體架構就是軟體的基本結構。架構的本質是管理復雜性。 如果你覺得架構不重要，可能是你做的事情不夠復雜，或者是你沒有管理好復雜性。架構模式雖多，經過抽象沉澱之後，也就那麼幾種：

1. 分層架構（比較傳統的單體架構）

2. 事件驅動架構 （一般適用於應用局部場景，用來實現非同步解耦）

3. 微核架構（又稱插件架構，開發難度較高，一般用來做工具軟體開發，如Eclipse，不太適合分布式業務場景）

4. 微服務架構（當前比較流行的服務化架構，解決單體架構面臨的問題，適合敏捷開發，快速迭代）

5. 雲架構（現在的說法是雲原生架構-Cloud Native，基於Docker、Kubernetes、Service Mesh 雲原生架構）

在原文的基礎上，我按照自己的想法，進行了小幅調整。

分層架構（ layered architecture ）是最常見的軟體架構，也是事實上的標准架構。如果你不知道要用什麼架構，那就用它。

這種架構將軟體分成若干個水平層，每一層都有清晰的角色和分工，不需要知道其他層的細節。層與層之間通過介面通信。

雖然沒有明確約定，軟體一定要分成多少層，但是四層的結構最常見。

有的軟體在邏輯層（business）和持久層（persistence）之間，加了一個服務層（service），提供不同業務邏輯需要的一些通用介面。

用戶的請求將依次通過這四層的處理，不能跳過其中任何一層。

優點

缺點

事件（event）是狀態發生變化時，軟體發出的通知。

事件驅動架構（event-driven architecture）就是通過事件進行通信的軟體架構。它分成四個部分。

事件驅動架構（event-driven architecture）核心組件：

對於簡單的項目，事件隊列、分發器和事件通道，可以合為一體，整個軟體就分成事件代理和事件處理器兩部分。

優點

缺點

事件驅動架構在通信產品中應用得也非常廣泛，典型的如狀態機處理。 事件驅動架構不適於做頂層架構，但適合做局部實現，幾乎遍布在通信軟體的各個角落。

微核架構（microkernel architecture）又稱為"插件架構"（plug-in architecture），指的是軟體的內核相對較小，主要功能和業務邏輯都通過插件實現。

內核（core）通常只包含系統運行的最小功能。插件則是互相獨立的，插件之間的通信，應該減少到最低，避免出現互相依賴的問題。

優點

缺點

微核架構的設計和開發難度較高，這就註定它在企業產品中用得不多，雖然它的優點還不少。

微服務架構（microservices architecture）是服務導向架構（service-oriented architecture，縮寫 SOA）的升級。

每一個服務就是一個獨立的部署單元（separately deployed unit）。這些單元都是分布式的，互相解耦，通過遠程通信協議（比如REST、SOAP）聯系。

微服務架構分成三種實現模式。

現在開源的微服務框架比較多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。

優點

缺點

雲架構（cloud architecture，現在的說法是雲原生-Cloud Native）主要解決擴展性和並發的問題，是最容易擴展的架構。

它的高擴展性，主要原因是可以基於雲上計算資源彈性伸縮。然後，業務處理能力封裝成一個個處理單元（prcessing unit）。訪問量增加，就新建處理單元（Docker容器）；訪問量減少，就關閉處理單元（Docker容器）。由於沒有中央資料庫，所以擴展性的最大瓶頸消失了。由於每個處理單元的數據都獨立分庫。

這個模式主要分成兩部分：處理單元（processing unit）和虛擬中間件（virtualized middleware）。

虛擬中間件又包含四個組件：

隨著Docker、Kubernetes等容器化技術的快速發展，上述關於雲架構描述有點陳舊了。當前最新的雲原生架構，以Docker+Kubernetes為核心，尤其是容器編排Kubernetes 已經成為事實上的行業標准。

雲原生架構圖的主要特徵：

主要目標：

1. 讓開發人員聚焦業務邏輯的實現，其他交給容器雲平台來完成；

2. 支持業務系統的快速迭代，支撐業務的快速變化和發展；

3. 構建以共享服務體系為核心的業務中台；

下面是我針對某新零售企業設計的雲原生架構圖，以雲和微服務架構為基礎構建雲原生應用，這里雲可以是公有雲、私有雲、混合雲等等。

以上是從不同的視角，對架構進行了分類。實際應用中，各種架構並不是孤立的，可以根據業務環境和業務訴求，對各種架構進行綜合和嫁接。每種架構都有其優點和缺點。優點不必多說，缺點則幾乎都是通過工具工程（比如自動化發布工具、自動化測試等等）能力的方法來規避，工具工程對軟體架構非常重要。

㈢ 什麼是模式、框架軟體為什麼要分層

• 模式：就是解決某一類問題的方法論。把解決某類問題的方法總結歸納到理論高度，就是模式。

  Alexander有一個經典的定義，每個模式都描述了環境中不斷出現的問題，然後描述了該問題的解決方案的核心。通過這種方式，可以無數次地使用那些已有的解決方案，無需在重復相同的工作。模式有不同的領域，建築領域有建築模式，軟體設計領域也有設計模式。當一個領域逐漸成熟的時候，自然會出現很多模式。

• 框架：就是某種應用的半成品，是一組組件，供選用完成的系統。

• 軟體分層的原因是為了實現"高內聚、低耦合"。把問題劃分開來各個解決，易於控制，易於延展，易於分配資源。

  

• 需要注意的是，人雖然在創造性方面有絕對優勢，但是在精確性、持久性、效率、質量上是無法比擬機器的。所以我們希望在軟體系統構建過程中，人和機器發揮各自的長處，也就是說，讓人來扮演架構師的角色，而讓機器來扮演程序施工者的角色。
  

㈣ net程序員怎麼提升自己的技術能力

一、先列三個常見的開發場景：

1、拿到一個模塊詳細設計文檔，大部分程序員的通常做法就是開始搭建界面代碼，然後從第一個按鈕點擊事件或頁面Load事件開始寫第一行業務代碼。寫的差不多了，就運行一下，發現哪裡不是自己想的那樣，就改改，直到改到是自己預想的那樣。

2、做完了一個功能模塊或幾塊相關聯的功能模塊，輸入111asd，發現新建正常、保存正常，就提交給測試人員。測試員用測試用數據、測試場景用例來測試，發現有問題，就登記bug。對於嚴重的影響下一步測試的BUG，測試員就用內部IM通知這個開發人員。對於不影響繼續往下測試的BUG，測試員就登記下來，等程序員有空時處理。

3、程序員一般工作不希望大家打擾，所以開發起來就是開發。等手頭開發告一段落，就看看BUG庫。發現有與自己有關的BUG，就從第一個BUG開始看起。就開始通過IM和測試員掰扯起來（這不是個BUG啊、業務邏輯不是你想的那樣啊、我這里不能重現啊、你給的信息描述不清晰啊），於是IM幾來幾往，甚至跑過去當面交流一番，甚至會拉扯上產品經理一起討論，更甚者需要項目經理或產品經理發起一個會議來集體討論一下

這是不是很熟悉呢？這就是大部分程序員開發的三個步驟：寫代碼、自測、修復BUG。

二、說好的代碼設計、代碼測試呢？

代碼設計？那不是都有開發平台么，已經固化了啊。那不是維護舊功能做完善修改呢么，又不是寫新代碼，只能在現有代碼基礎上修改啊，你又不能大幅重構。

代碼測試？你丫需求討論期、產品設計期、設計評審期那麼長，都把研發項目時間佔光了，就留下2個星期讓我們寫代碼，我們哪裡有時間搞那麼深的測試。還想讓我們搞結對編程？還想讓我們搞測試驅動開發？

而且你看測試，什麼功能測試、集成測試、性能測試、安全測試、安裝部署測試、升級測試、遷移測試、UAT測試，一大堆測試，測試也需要很多時間。

一個項目，需求討論、產品范圍規劃與評審、產品設計與設計評審佔了一個半月，開發+自測就一個月，測試佔了一個半月，這就4個月了啊。

三、為啥程序員寫代碼總是寫寫測測？

剛才大家也都看到了，大部分程序員都是從界面代碼開始寫起，而且寫一寫，就運行一下看看。為什麼會是這種開發方式？

那是因為大部分程序員缺乏在腦子中的整體建模能力。只能做出來一點，真實的感覺一下，然後再往下。

有些是產品經理的上游就有問題，沒給出業務流程圖（因為產品經理也沒做過業務），也沒畫清楚產品功能操作流程圖。

為啥沒給出業務流程圖？因為產品經理不熟悉業務，另外，產品經理也沒有流程建模能力啊。為啥沒畫清楚產品功能操作流程圖啊？因為不會清晰表達流程啊。

很多產品經理、程序員，都缺乏分類、分層、相關、先後能力，更別說總結、洞察能力。

這是基本訓練，是一個做事頭腦清醒的人必備的技能，這不是一個程序員或產品經理或測試員的特定技能要求。

我經常看書就梳理書的脈絡，每看一本就寫一篇總結。我過去閑扯淡還梳理過水滸傳、紅樓夢的人物關系圖呢，其實就在事事上訓練自己的關聯性、層次性、洞察性。

我經常面試一個人時，我會問這樣的問題：「你把我剛才說的話復述一遍，另外你再回答一下我為什麼會這樣？」，其實，我就在看一個人的細心記憶、完整梳理、重現能力，我也在看一個人的梳理、總結、洞察能力。

我個人寫代碼就喜歡先理解業務流，然後理解數據表關系，然後理解產品功能操作流，大致對功能為何這樣設計、功能這樣操作會取什麼表、插入或更新哪些表，哪些表的狀態欄位是關鍵。

然後我寫代碼的時候，就根據我所理解的業務流、功能操作流、數據輸入輸出流，定義函數，定義函數的輸入與輸出。

然後，我會給函數的輸入值，賦上一些固定值，跑下來看看能否跑通這幾個關聯函數，看看還需要怎樣的新增函數，或者看看函數的輸入輸出參數是否滿足跑通。

剩下的事，就是我填肉寫詳細邏輯代碼了。

當然，大部分人沒我這樣的邏輯建模能力。怎麼閱讀理解也想像不出來，也沒法定義函數。畢竟有邏輯建模能力的程序員都很少，100個人里有10個，已經是求爺爺告奶奶好幸運了。

那怎麼辦呢？

我建議是分離分工配合，這就是現實中沒辦法的辦法。讓有邏輯建模能力的人來設計函數框架、來設計工具來設計代碼模板，然後讓沒有邏輯建模能力的人來填肉寫詳細邏輯代碼。

我們可以先從最緊要的模塊開始這么做。不緊要的模塊，還讓它放任自流，讓熟練手程序員繼續塗抹。

我曾經還讓有頭腦的程序員做榜樣，給大家分享他是怎麼規劃函數的，怎麼做維護性代碼的代碼結構改善的。但是發現效果並不佳，其他人並沒有因此能做代碼設計。可能邏輯建模能力是個人的基本素質，是從小到大訓練成型的，不是你一個大學已經幾年的人能夠短時間內可以訓練的。

所以啊，還是讓能走的人先走，讓從最緊要的模塊開始這么做。

不必擔心這樣做後，因為過去一件事被分工（一個做代碼框架一個填肉）成兩個人做了會降低工作效率。我們很多的工作效率低就是因為半瓶子醋搞出來的，來回反復修改。

真是應了劉德華在電影里說的那句話：說你又不聽，聽又聽不懂，聽懂了又不做，做又做不好，做不好還不服氣。

四、為什麼大部分程序員不做代碼測試或白盒測試或單元測試呢？

還是因為沒有代碼設計。因為沒有函數啊。所以，一個按鈕功能有多復雜，代碼就有多長。我見過2000行的函數，我也見過1000多行的存儲過程和視圖SQL。怎麼做白盒測試啊，這些代碼都粘在一起呢，要測，就得從頭到尾都得測。

所以啊，先學會設計函數，先寫好函數，這就求爺爺告奶奶了。很多開發了5年的熟練手程序員，可能都未必會寫函數。

函數的輸入輸出值就很有講究。很多人都寫死了，隨著版本迭代，發現過去定義的函數參數不夠用了，於是就新增了一個參數。然後，相關性異常就爆發了，其他關聯的地方忘改了，到底哪些有關聯，怎麼查啊，本系統沒有，沒准其他系統就調用你了，你根本不知道哪個神經人曾經COPY過你的代碼修吧修吧就改成了他的功能呢，而且裡面的很多代碼他看不懂也不敢刪，只要他實現的功能正常了他也不管了。於是，你改了你這個函數，他的系統就莫名出錯了。

所以，我一般會定義幾個對象來做參數。另外，我也很注重函數的日誌、函數的異常保護、異常拋出、異常返回。另外，我也很注重參數輸入值的合法性校驗。

所以啊，應該開發Leader們先制定函數編寫規范最佳實踐，輸入輸出參數怎麼定義比較好，函數的返回值如何定義比較好，函數的日誌記錄應該怎麼寫比較好，函數的異常保護、異常拋出、異常返回如何寫比較好。先教會一般程序員，先從會寫函數開始啊。

當然，你光有一份規范，程序員們還是不理解、不實際應用啊。所以，還得Leader們做好典型的代碼模板，裡面是符合函數規范的代碼框架，只有這樣，一般程序員們才會照貓畫虎適應了函數設計的編程習慣。

所以啊，我專門重新定義了leader的明確職責，其中第一個重要職責就是：負責工具/框架/模板/規范的制定，並且負責推廣且普及應用落地。

你不明確定義Leader的這個重要職責，你不對這個職責做明確的KPI考核，誰尿你啊。你以為好的工具/框架/模板/規范是靠人們的熱情、自發產生的么？我們還沒有那麼自覺高尚啊。

五、為什麼大部分程序員不寫注釋啊？

我經常說一句話，千萬別多寫注釋。為啥？

因為我們經常遇到的問題不是沒有注釋，而是更糟的是，注釋和事實代碼邏輯是不相符的。這就出現常見問題了：殘存下來的設計文檔是一個邏輯、注釋是一個邏輯說明、真實代碼邏輯又是一個，鍾表多了，你也不知道正確時間了。

所以啊，產品文檔、注釋、真實代碼，三者總是很難一致同步。我為了幾百人研發團隊能做到這個同步花了大量心血和辦法，但我最終也沒解決了這個問題，還把Leader們、總監們、我都搞的精疲力盡。

索性回歸到一切一切的本源，代碼，就是程序員的唯一產出，是最有效的產出。那麼，讓代碼寫的不用注釋也能看懂，咱得奔著這個目的走啊。

為啥看不懂，不就是義大利面條式代碼么，又長又互相交雜。

OK，我就規定了，每個函數不能超過50行。用這一個簡單規定和靜態代碼檢查插件，來逼迫大家嘗試著寫函數。有的函數屬於流程函數，是串起其他函數的，有的函數就是詳細實現函數，實現一個且唯一一個明確作用的。

有了流程函數和功能函數，而且每個函數不超過50行，這就比過去容易看懂了。

六、為什麼大部分程序員不抽象公共函數啊？

我經常說一句話：千萬別抽象公共函數啊。為啥？

因為大部分程序員缺乏抽象洞察能力。特別是有些積極熱情有餘、愛學習愛看書、半瓶子醋晃悠的二桿子，看了幾本UML、重構、設計模式、整潔代碼之道，就躍躍欲試了，還真敢給你抽象公共函數了。

一開始，他覺得80%相似，20%不相似，於是在公共函數裡面簡單寫幾個if..else做個區隔就可以。沒想到，越隨著版本迭代，這些功能漸漸越變越不一樣了，但是這個代碼已經幾經人手了，而且這是一個公共函數，誰也不知道牽扯多少，所以誰也不敢大改，發現問題了就加一個if..else判斷。

沒想到啊沒想到，這個本來當初公共的函數，現在變成了系統最大的毒瘤，最復雜的地方，誰也不敢動，除非實在萬不得已，手起刀落。

所以，我平時告誡程序員，純技術的、純通用的，你們可以嘗試搞搞抽象公共函數，對於業務的，你們還是簡單粗暴的根據Leader們做的代碼模板代碼框架，乖乖的復制、修改、填肉吧。

你們啊，先從做模板做代碼片段開始吧，咱們放到咱們內部代碼片段開源庫里，看誰的代碼片段被別人復制的多，說明你的代碼抽象設計能力越好了。那時候，我就大膽放心讓你撒丫子跑了。在沒有學會跑之前，給老子乖乖的復制、修改、填肉吧。

㈤ 什麼是典型的軟體三層結構軟體設計為什麼要分層軟體分層有什麼好處

軟體的三層結構一般指的是 MVC
M 是model的簡稱是指實體層
V是view的簡稱是指視圖層
C是Controller的簡稱是指控制層
具體可查看網路http://ke..com/link?url=_7Iy6spb037lZr5nJHHv-jGRFhxpmck4PCHz6mrXF_-_6M
MVC的優點
1.低耦合性
視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。
2.高重用性和可適用性
隨著技術的不斷進步，現在需要用越來越多的方式來訪問應用程序。MVC模式允許你使用各種不同樣式的視圖來訪問同一個伺服器端的代碼。它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面使用。例如，很多數據可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實現方式，而控制層和模型層無需做任何改變。
3.較低的生命周期成本
MVC使開發和維護用戶介面的技術含量降低。
4.快速的部署
使用MVC模式使開發時間得到相當大的縮減，它使程序員（Java開發人員）集中精力於業務邏輯，界面程序員（HTML和JSP開發人員）集中精力於表現形式上。
5.可維護性
分離視圖層和業務邏輯層也使得WEB應用更易於維護和修改。
6.有利於軟體工程化管理
由於不同的層各司其職，每一層不同的應用具有某些相同的特徵，有利於通過工程化、工具化管理程序代碼。

㈥ 我們如何使用分層的編程思想提升程序的可移植性和可維護性 百度網盤

隨著plc控制技術的不斷發展和成熟。plc在水電站腹肌系統得到了廣泛的應用。模塊化編程編程思想在浮動負積系統中的運用提高了編程的效率，增加了程序的可移植性和。可維護性。程序設計追求的是代碼的通用性。可移植性可維護性。功能可擴展性。那麼如何才能實現呢？首先需要大量的實踐經驗，其次對面向對象編制思想的深入了解。隨著信息化技術的發展，我國政府根據我國經濟和社會發展的要求。提出了要大力開展信息化建設開發和推廣各類信息系統。政府信息系統作為政府部門工作和對外的窗口。造成三層架結構的可維護性和可移植性比較差。另外一方面三層架結構中的持久層的資料庫的工作量，同時還可以使程序員能夠隨心所欲的使用。面向對象編制思想來操作。

㈦ 一個標準的程序員，它的代碼應該是怎樣分層次的

每個代碼的層次都是不一樣的，都是非常縝密的，除此之外，不光是要會寫代碼，還要成為一個好的程序員才是最重要的。

程序員，隨著計算機和軟體行業的發展，基數越來越大。如何在茫茫的程序員中脫穎而出呢，來看看作為一個好的程序員的標准你都佔了幾條？

1.經常和其他的人交流

什麼時間做什麼事情，做事情按照一定步驟來，好的程序員從來不會在時間緊任務多的時候手忙腳亂。

7. 保持謙虛

技術永無止境，技術范圍很廣，技術水很深。即使在一個領域是專家，到了其他領域還是需要其他人的指點。好的程序員總是把姿態放低，虛心請教。

㈧ 有的程序員30多歲還在投簡歷找工作，三十歲沒做到管理層，未來該怎麼辦

程序員是一個特殊的工作。並且這個工作，需要具備一定的專業知識，也比較枯燥。程序員的工作也是競爭非常激烈的，因為每一年都會推陳出新，不斷有新的程序員加入到這個工作行列。有更多的年輕人會選擇這個工種。程序員隨著年齡的增長，具體應該何去何從，確實是每一個年長的程序員所憂慮的問題。

很多公司做久了都會變相的加班無休止的工作。我表弟非常喜歡小發明小製作。在工作的空閑時間，申請了幾個專利，都是節能環保型的專利。結果這幾個專利都賣了不少錢加起來已經超過了百萬。要知道，這是在2006年。

現在他已經買了房子，並且在很多大公司都有著豐富的經驗，現在有很多公司爭相邀請他去做程序設計。所以並非要做到管理層，才能證明你的能力，你需要不斷的充實和完善自己，有的時候你可以選擇其他的方式，實現自己的人生價值。

㈨ 單片機程序裡面，經常聽說底層，中間層，應用層，什麼意思 51單片機也需要這么分層嗎

一般當程序比較大、功能比較繁多，需要進行結構化程序設計的時候，才會進行分層。分層的好處是可以將應用與硬體剝離，當硬體發生變更（移植，設計更改）時只需改動底層以及少量中間層；當需求發生變更時只需改動上層以及少量中間層。

底層一般是直接訪問硬體的介面，以串口而言如寄存器操作函數；中間層一般是在底層與上層之間進行數據及信息的轉換，以串口而言如封包/拆包/消息產生/消息響應；上層一般面向應用，在很少考慮硬體實現的前提下以通用的方式實現所需的功能，以串口而言如printf。

分這么多層是為了不同程度的開發人員可以同期工作的原因。比如說，底層就僱傭一個特別熟悉晶元和硬體的人做，中間層大概要找比較熟悉應用的人來把硬體功能來做擴展，應用層就隨便抓一把人來開發了。

這樣，多個項目可以公用一個硬體層，有兩到三組中間層的支持工程師，然後每個項目各有一組應用工程師就好了。51也可以這樣做，這和效率無關，層做得好，執行效率不會影響很大，開發效率提高很多。

(9)程序員分層怎麼辦擴展閱讀：

單片機的應用：

1，通用專用：

這是按單片機適用范圍來區分的。例如，80C51是通用型單片機，它不是為某種專用途設計的；專用型單片機是針對一類產品甚至某一個產品設計生產的，例如為了滿足電子體溫計的要求，在片內集成ADC介面等功能的溫度測量控制電路。

2，線型應用：

這是按單片機是否提供並行匯流排來區分的。匯流排型單片機普遍設置有並行地址匯流排、數據匯流排、控制匯流排，這些引腳用以擴展並行外圍器件都可通過串列口與單片機連接，另外，許多單片機已把所需要的外圍器件及外設介面集成一片內，因此在許多情況下可以不要並行擴展匯流排，大大減省封裝成本和晶元體積。

3，控制型應用：

這是按照單片機大致應用的領域進行區分的。一般而言，工控型定址范圍大，運算能力強；用於家電的單片機多為專用型，通常是小封裝、低價格，外圍器件和外設介面集成度高。 顯然，上述分類並不是唯一的和嚴格的。例如，80C51類單片機既是通用型又是匯流排型，還可以作工控用。

㈩ 分層體系結構的注意

低層為高層提供服務。
每一層都提供一些服務。
服務由協議定義。
程序員只需關心與他的工作直接相關的那些層的協議，它們向高層提供服務，並由低層提供服務。
當系統通信時，在每個系統中的協議棧的每一層的對等協議協調完成通信過程。例如，一個系統的運輸層將根據另一個系統的運輸層的情況協調它的活動。打個比方，設想在兩個使館之間需要安排一次正式會議，在表面上，兩位大使簽署正式協議，而在背後，外交官和官員們整理文件，制定日程，並進行其他活動。外交官具有級別，每個級別的外交官為更高級的官員做一些服務。在最高級別的大使向低級外交官下達命令，並使用外交官提供的服務。同時，大使級以下的外交官會與另一個使館的同等級別的外交官進行協調工作。每個外交官都按照為他們這個級別制定的外交慣例執行。例如，在特定級別的一個外交官員可能提供語言服務或技術文件。根據翻譯和歸檔過程，這個官員與另一個使館的同等官員進行通信。