国产亚洲精品久久久久动,亚洲欧洲一区二区天堂久久,欧美色视频一区

命名

# 命名

摘自：[警惕軟件復雜度困局][1]

軟件中的API、方法、變量的命名，對于理解代碼的邏輯、范圍非常重要，也是設計者清晰傳達意圖的關鍵。
然而，在很多的項目里我們沒有給Naming /命名足夠的重視。

我們的代碼一般會和一些項目關聯，但是需要注意的是項目是抽象的，而代碼是具體的。
項目或者產品可以隨意一些命名，如阿里云喜歡用中國古代神話（飛天、伏羲、女媧）命名系統，
K8s也是來自于希臘神話，這些都沒有問題。
而代碼中的API、變量、方法不能這樣命名。

一個不好的例子是前一段我們的Cluster API 被命名為Trident API（三叉戟），
設想一下代碼中的對象叫Trident時，我們如何理解在這個對象應該具備的行為？
再對比一下K8s中的資源：Pod, ReplicaSet, Service, ClusterIP，
我們會注意到都是清晰、簡單、直接符合其對象特征的命名。名實相符可以很大程度上降低理解該對象的成本。

有人說“Naming is the most difficult part of software engineering”，
或許也不完全是個玩笑話：Naming的難度在于對于模型的深入思考和抽象，而這往往確實是很難的。

需要注意的是：

（a）Intention vs what it is

需要避免用“是什么”來命名，要用“for what / intention”。“是什么”來命名是會很容易將實現細節。
比如我們用 LeakedBarrel做rate limiting，這個類最好叫 RateLimiter，而不是LeakedBarrel：
前者定義了意圖（做什么的），后者描述了具體實現，而具體實現可能會變化。
再比如 Cache vs FixedSizeHashMap，前者也是更好的命名。

（b）命名需要符合當前抽象的層級

首先我們軟件需要始終有清晰的抽象和分層。
事實上我們Naming時遇到困難，很多就是因為軟件已經缺乏明確的抽象和分層帶來的表象而已。

[1]https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247498895&idx=1&sn=35b1d00e367c18c3d4ed7d4b15b38996&chksm=e92ac180de5d4896fd5d789ffbe8c963986717b634f2dac09821c2b3ab2270a42f4a1c006ff5&scene=21#wechat_redirect

posted on 2020-12-31 09:45 金慶閱讀(351) 評論(0) 編輯收藏引用所屬分類: 5. 軟工與管理

只有注冊用戶登錄后才能發表評論。
【推薦】100%開源！大型工業跨平臺軟件C++源碼提供，建模，組態！

相關文章: TortoiseGit is OK but GitExtensions fails 命名 SVN重命名時不要更改內容刪除隱性的git submodule 用docker stack開啟redis集群 Lua區分公有私有接口 Lua53 premake ejabberd開發和部署 Windows運行GitStats CMake搜索Boost1.57失敗及解決

網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

金慶的專欄

公告

留言簿(12)

隨筆分類(502)

隨筆檔案(423)

相冊

搜索

積分與排名

最新評論

閱讀排行榜

評論排行榜