业务程序员不建议造轮子
不要问我是.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;
}
}
}
业务程序员不建议造轮子，但这是很矛盾的事。造轮子确实可以学到写业务代码学不到的技术。