摆脱软件作坊

背景

作为一名从事软件开发六年的程序员. 我觉得软件开发方法论是我当下不得不面对和深思的问题. 自己是半路出家,也许对整个行业的认知也不如一些从业者那么敏感.
从业这几年中本人遇到不少公司,对开发的态度也是大相径庭. 但这与公司的规模并没有太直接的因果关系(当然我这里说的”公司”主要是中小型企业).在如今这个时代背景下,中国以及中国的IT企业正一步一步与世界接轨. 我不太清楚一个真正国际企业的状况, 但对当前我接触到的国内状态有一些失望.
我曾在一个人数不到30人的软件公司做过,核心的架构很有想法(由于待的时间不长,我了解得并不深入), 项目框架层次分明, 编码人员只需要组织业务即可,编码人员变动也影响不到系统, 培训班刚刚出来的完全能胜任其编码工作).很客观的说, 这一点不少所谓的”大企业”做不到 (当然我是读过某大企业的产品代码才敢这么说).
下面就说说这个大企业的产品吧,规模至少是上千人,而且这个产品也是获得不少荣誉. 从其专业领域来讲,此产品的确意义重大,而且非常实用,深受用户褒奖. 一个偶然的机会我接触到其源码. 结构其实也很简单,经典的c/s模型.然而界面一块写得一团糟.一个文件一不小心就是几千行, 一个cpp文件就包含了数据处理流程,UI交互逻辑, 复杂的显示逻辑等等. 我看到这里才恍然大悟, 难怪此产品的后续版本选择的是全部重写,这代码根本没法动!
大部分开发期望的项目代码应该层次分明,高聚合低耦合. 相信各位看到自己曾经的代码都会有现在来写一定会更好的感觉,但是想要重构又无从下手.或者是重构后的代码根本跑不起来. 一定会有更好方法解决这些问题, 在此我推荐单元测试.曾有人说,重构没有单元测试的代码就像在”裸奔”. 我不愿意裸奔,所以一定要单元测试.而测试驱动开发是单元测试的最佳应用.

TDD定义

TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。

现状

测试先行的实践意义与其存在的意义一样重要, 我不是什么完美主义或极端主义者. 在实际项目中我也并非完全使用TDD,而是在非常关键的环节与核心代码编写中才会真正用到.为什么用呢? 我认为使用的原因很简单,它能让代码更加可靠,更便于重构,而且测试优先的思想很容易让类之间的耦合降到最低.上述优点是很多完美主义者梦寐以求的.
那么我为什么不在全部开发过程中使用呢? 这个问题我认真考虑过后,总结了以下几点

• 时间因素 我所知的开发,都经常会被催着做紧急的事情,而这些紧急的事情,往往是无法控制的. 所以为了保证速度,我们就不得不牺牲质量.而众所周知,TDD方法在前期阶段是比较耗时的.
• 个人因素 并不是所有人都认可TDD的, 即使时间充裕,大家都有各种各样的理由不写单元测试. 甚至有过一次,我要求下面一位开发对核心库写单元测试的时候,还被认为是对他的刁难. 如果仅仅是开发不认同还不算什么大问题, 如果企业的领导层不认同那基本丧失了实施的可能性.
• 环境因素 此处所说的环境因数包含了很多方面,比如公司的内部环境. 国内软件行业的大环境. 我知道世界中的大多数事情充满哲理,但是还有很多实际的事情却不是这样.比如很多时候,一件简单不过的事情,我们之所以这样做,并不是因为这样有什么道理,而是因为大多数人都这样做. 划时代的东西,都是打破常规的人和习惯造成的.我们有时候需要这样的人出现,也需要能打破常规的人来推广.
• 物质因素 这其实大部分也与时间因素相关, 更多的时间意味着更多的人力成本,人力即money. 对一个不算大的公司来讲,当前利益比很多事情都重要.

我曾经听一位开发给新人讲过, 我们写代码应该先考虑怎么写测试, 那个时候我并没有听说过TDD,甚至从业两年,连一句单元测试的代码都没有写过. 现在想想真是羞愧. 我认为这也是行业缺乏规范的结果.

未来

软件行业是年轻的新兴行业,这个时代的宠儿.正因如此,它有着如同热血男儿一般的激情四射与躁动不安. 不少公司的项目开发如同”小作坊”一般,深陷技术债的泥潭.
这里与其说是TDD的未来,不如说成是中国软件行业的未来, 我希望有越来越多的人能认可软件方法论的重要性, 并在实践中使用.TDD只是软件方法论慢慢长路的开始,未来还有很多的路要走.