Golang开发中该选用CLI还是包管理？

Golang开发中该选用CLI还是包管理？ 大家好，

我一直在考虑发布我正在进行的项目（我的博士毕业项目），但我有一些疑问/问题。如果你们中的任何人能给我一些想法（链接、关键词等），我将不胜感激。

该项目是一个并发测试框架。它以 Go 源代码作为输入，自动进行插装并收集一组跟踪信息，然后对收集（存储）的数据进行一些分析。其最终重点是探索交错空间并覆盖一些并发覆盖标准。

为了实现这一点，我向运行时注入了一些额外的代码（通过预先编写的补丁），连接到 SQL 数据库并查询数据库进行分析。因此，它不是一个可以通过包直接使用的简单 API。然而，我一直在考虑通过 Go 内置的 “testing” 包来构建这个项目。这样，用户可以在单元测试的基础上增强一些并发测试；但我不确定这有多可行。

综上所述，您认为哪种是更好的选择？对于这样的工具，CLI 还是包更合适？做出这样的决定需要考虑哪些因素？非常感谢任何意见。如果您有任何问题，我非常乐意澄清。

祝好


更多关于Golang开发中该选用CLI还是包管理？的实战教程也可以访问 https://www.itying.com/category-94-b0.html

3 回复

感谢这些想法。我非常喜欢同时拥有命令行界面和包的设计（命令行界面使用该包）。

这将是一个研究工具，而非用于生产环境。虽然我同意您关于SQL是一个巨大依赖项的说法，但我认为研究人员不会介意尝试这个工具或在它之上进行构建。数据及其关系（以及随之而来的查询）可能会变得极其庞大和复杂。

更多关于Golang开发中该选用CLI还是包管理？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


几点想法，或许能帮助你思考这个问题……

  1. 引入 SQL 数据库会带来严重的依赖问题。我建议重新考虑如何在不使用数据库的情况下管理数据。
  2. 目前 Go 的测试有 Test* 和 Benchmark*；我想你可以添加第三种（Analyze*？）。但是为了使用这个功能而去修改 Go 源代码，似乎代价太大了。

我建议先创建一个包，然后利用这个包提供一个命令行界面。这将为用户提供一个如何使用它的具体示例。

祝你好运！

对于你的并发测试框架项目，选择CLI还是包管理主要取决于使用场景和集成方式。以下是具体分析：

1. CLI的优势和示例： 如果你的工具需要独立运行、处理文件系统操作或与外部系统交互，CLI是更合适的选择。特别是涉及源代码插装、数据库连接等操作时。

// 示例CLI结构
package main

import (
    "flag"
    "log"
)

func main() {
    inputDir := flag.String("input", ".", "输入Go源代码目录")
    outputDir := flag.String("output", "./instrumented", "插装后代码输出目录")
    dbConn := flag.String("db", "", "数据库连接字符串")
    
    flag.Parse()
    
    // 执行插装和分析流程
    if err := instrumentAndAnalyze(*inputDir, *outputDir, *dbConn); err != nil {
        log.Fatal(err)
    }
}

func instrumentAndAnalyze(inputDir, outputDir, dbConn string) error {
    // 实现插装、数据库连接和分析逻辑
    return nil
}

2. 与testing包集成的方案： 如果你想与Go测试框架深度集成，可以创建测试辅助包。用户通过go test命令触发并发测试：

// 示例测试辅助包
package concurrencytest

import (
    "testing"
    "database/sql"
)

func EnableConcurrencyTesting(t *testing.T, db *sql.DB) {
    // 在测试开始时注入代码
    t.Helper()
    // 实现跟踪收集逻辑
}

// 用户使用示例
func TestConcurrentOperation(t *testing.T) {
    db, _ := sql.Open("postgres", "connection_string")
    defer db.Close()
    
    EnableConcurrencyTesting(t, db)
    
    // 用户的并发测试代码
}

3. 混合方案： 考虑同时提供CLI和包。CLI用于初始化和配置，包用于测试运行时集成：

// CLI部分负责初始设置
func initProject(configPath string) {
    // 生成配置文件、建立数据库等
}

// 包部分提供测试接口
type TestHarness struct {
    db *sql.DB
}

func NewTestHarness(dbConn string) (*TestHarness, error) {
    // 初始化测试环境
    return &TestHarness{}, nil
}

func (h *TestHarness) RunTest(testFunc func()) error {
    // 执行测试并收集跟踪数据
    return nil
}

关键考虑因素：

  • 如果用户需要频繁在CI/CD流水线中运行，CLI更合适
  • 如果需要与现有测试代码深度集成，包方案更好
  • 涉及源代码修改和外部依赖的操作更适合CLI
  • 考虑提供两种方式：CLI进行环境准备，包进行测试执行

根据你的描述，由于涉及运行时代码注入和数据库操作，建议以CLI为主要接口，同时提供有限的包API供高级用户集成到测试流程中。

回到顶部