盧偉冰長文解析K60至尊版 對Redmi有著里程碑式的意義
在今天的Redmi后性能時代戰略發布會結束之后，Redmi總經理盧偉冰又帶來了一篇長文，詳解了為什么 Redmi 要開啟后性能時代？為什么選擇和 MediaTek、Pixelworks 深度合作？以及后性
大家好，我是煎魚。
在 Go 語言中，我們一般會用模塊（Module）和包（Package）來組織我們的項目、庫的目錄和代碼結構。這也是官方所推薦的。
今天給大家分享一個面向包這塊的新提案，看看是否合適加進 Go 特性中？看看社區里不同人的想法。
具體來講，模塊（Module）就是 go mod 的應用。我們最常接觸到的是以下命令：
mkdir my-projectcd my-projectgo mod init github.com/eddycjy/my-project在執行了 go mod init 后會生成 go.mod 文件，如下所示：
// go.modmodule github.com/eddycjy/my-projectgo 1.21.1這就是這個項目的模塊。
對應到包（Package）中，會更加的直接和顯性。我們一般會創建類似如下的目錄結構：
<my-project> -<cli> --cli.go -<internals> --internals.go --go.mod --main.goGo 文件中的 package name，存在明確的約定俗成的標準，需要和目錄名稱保持一致。
例如：
// internals.gopackage internalsimport "fmt"func Hello() { fmt.Println("你好，煎魚！")}如果在其他地方中導入該包，則為：
import ( ... "github.com/eddycjy/my-project/internals")以上就是模塊和包的基礎前置知識。我們接下來正式進入提案的正題。
針對 Go 程序的代碼組織結構管理，最近社區有個同學提出了一個新提案：
圖片
在 Go 里文件夾默認與包（Package）的關系是劃等號的。雖然這很方便，但是提案作者反饋：在某些情況下，我們需要通過文件夾來實現純粹的組織和可讀性目的，而不想引入新的包。
為此提出了 “透明文件夾” 的概念，通過使用諸如 Next.js 應用程序路由器中看到的 (folder) 或 _folder 之類的語義來表示。
這些文件夾可以在不創建新軟件包的情況下組織軟件包內的文件。它們將與軟件包的根目錄保持關系。
例子如下：
myapp main.go myTypes.go (routes) handleRoot.go handleMultipart.go ... db connect.go dbTypes.go (auth) strategy1.go strategy2.go ...可以看到這個例子，他使用 (folder) 的方式來表示透明文件夾。例如：(routes) 和 (auth)，這樣他就不需要再細分不同的 package name，統一用 myapp 和 db 的包名就能進行引用。
簡單來講，該提案的實現方式是：通過將工程中 package name 和實體文件夾目錄的作用分割開，目的是：提供一種純粹的代碼組織方式。
其實類似的場景訴求，我有一個朋友曾經聽幾個同事吐槽過。但一般會是在比較大的 Go 項目中，例如出現以下場景：
myapp service a-service b-service c-service ...會認為這樣 package 切割的比較碎，但是不區分開。多了后在代碼結構上又很容易繁雜化。所以會想有一種純碎的代碼組織方式。
爭議也是有不少的。因為他對語言的 ROI 并不是太高，變動的東西（例如：工具、IDE、tests 等）會比較多。
只需將文件命名為：aaa-foo.go aaa-bar.go bbb-foo.go bbb-bar.go，而不是 aaa/foo.go aaa/bar.go bbb/foo.go bbb/bar.go。也能達到類似的效果。
也有表示添加透明子文件夾會讓一切變得更加復雜，卻沒有任何好處。把文件放在它們應該在的地方就可以了。現在已經在其他語言中看到過這種替代方法，很糟糕。
這個提案本身的出發點很常見，因為 package name 和代碼目錄結構綁定了，會導致在設計代碼結構時會有些受限，最終受此引導拆 package 來形成結構化。
如果盲目的添加透明文件夾，反而會出現一個尷尬的問題。因為 Go 語言在這塊是非常直接的，添加了這類模式，大家反而會沒法篤定，要去看看項目的代碼結構才能確定。
我認為反而會導致可讀性會有所下降。
本文鏈接：http://www.www897cc.com/showinfo-26-17381-0.htmlGo 透明文件夾的特性，有沒有必要加？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號