业务程序员不建议造轮子

不要问我是.net程序员还是java程序员，我是业务程序员。

工作多年，我觉得业务程序员，不应该造轮子。

多年以前，我就吃过造轮子的亏，有时，我工作大概60%的时间在造轮子、改轮子的BUG，40%的时间在写业务功能。

为什么要造轮子呢，为了学技术，为了不认输。但是造轮子的代价很大，也影响工作，写着业务代码呢，突然出现BUG，而且是轮子的BUG，程序跑不下去了，然后去改轮子的BUG，很浪费时间。

业务代码有BUG很正常，随手就改了。但轮子最好不要有BUG，因为容易坑人。

但BUG总是存在的，怎么才能尽量避免BUG呢？要有完善的单元测试。怎么才能及时发现BUG呢？要有一定的用户量。

但是我的单元测试不够专业不够完善，也没有什么用户，我总结出来一些适合我自己的经验，只要不写代码，就没有BUG，只要代码写的少，BUG就少，所以，我把脏活扔了，把它降级为一个Dapper扩展。即便如此，依然付出了很多时间代价，也非常折腾人。

前两天，发现了一个严重BUG，然后修改后重新发布了。本着负责的态度，觉得这个BUG比较严重，把自己不再维护的旧库也修复重新发布了。但新旧多个版本的维护真的很累人。

单元测试、其它测试工程都测试通过了，又静态检查了代码，觉得没有问题了。可是，使用该轮子的业务代码居然又报错了，是轮子的错误。然后修改重新发布，把各种流程又走了一遍，好在不再维护的旧库没有这个问题，省了一些时间。

这个BUG有点意思，单元测试考虑到了，但没有测出来，如果是业务代码，可能完全没有问题，但轮子要考虑各种情况。

有BUG的代码如下：

/// <summary>
/// 提交事务
/// </summary>
public void CommitTransaction()
{
    if (_tran == null) return; //防止重复提交

    try
    {
        _tran.Commit();
    }
    catch
    {
        RollbackTransaction();
        throw;
    }
    finally
    {
        if (_tran != null)
        {
            if (_tran.Connection.State != ConnectionState.Closed) _tran.Connection.Close();
            _tran.Dispose();
            _tran = null;
        }
    }
}

我的单元测试代码使用的是MySql.Data库，没有问题。但我的项目中使用的库是MySqlConnector库，报空指针异常，因为MySqlConnector库，成功提交事务后，事务的Connection属性就被置为null了。修复后的代码如下：

/// <summary>
/// 事务关联的数据库连接
/// </summary>
private DbConnection _connForTran;

/// <summary>
/// 开始事务
/// </summary>
public DbTransaction BeginTransaction()
{
    var conn = GetConnection();
    if (conn.State == ConnectionState.Closed) conn.Open();
    _tran = conn.BeginTransaction();
    _connForTran = _tran.Connection;
    return _tran;
}

/// <summary>
/// 提交事务
/// </summary>
public void CommitTransaction()
{
    if (_tran == null) return; //防止重复提交

    try
    {
        _tran.Commit();
    }
    catch
    {
        RollbackTransaction();
        throw;
    }
    finally
    {
        if (_tran != null)
        {
            if (_connForTran != null)
            {
                if (_connForTran.State != ConnectionState.Closed) _connForTran.Close();
                _connForTran = null;
            }
            _tran.Dispose();
            _tran = null;
        }
    }
}

业务程序员不建议造轮子，但这是很矛盾的事。造轮子确实可以学到写业务代码学不到的技术。