半年来的项目实践--乱弹

最近关于TDD与Agile的话题似乎不少, 参与讨论的人也不在少数. 但一直有个疑问, 在讨论的这些人中间究竟有多少人真正的经历过这样的一个项目, 它长期坚持TDD, 一直追求最佳实践, 并且能够正确的实施Agile的理念.

有人可能会问, 什么是真正的敏捷; 有的人更会反问你了解敏捷多少. 每个人都对敏捷的理解都不一样, 看过同事的这篇博客---一句话的敏捷, 其中说敏捷就像<越狱>的拍摄过程, 根据观众的反馈及时的调整拍摄计划, 获取他们的关注, 达到提高收视率的目的; 还有形容敏捷持续交付的过程是河流流向大海的过程. 其实敏捷也好, 不敏捷也好, 项目做的舒服, 能够成功交付优秀的产品, 这才是软件最应有的产出. 软件是人类智慧的成果, 听牛人说过软件会代替书籍成为人类传承知识的载体, 刚听到也很惊诧, 不过后来的解释同样让人信服. 构建一个软件的过程是我们去了解,分享,分析,把握一个领域的过程, 知识的传承也正是建立在这些之上的. 

上面说了一些听起来似乎很大很远的话, 那么说说我这半年来的项目实践吧.

关于TDD

经历的第一个项目, 由于项目压力和开发语言的问题, 使得实施TDD有很多的困难. 在我们编写代码的过程中,或多或少引入的一些问题导致QA的压力越来越大. 越是临近上线, team就越是担心在回归中出现大量defect. 单元测试的缺失为整个项目的质量保证埋下了隐患, 一些问题都在support的阶段开始浮现出来. 当然, TDD绝不仅仅是单元测试.

在我的第二个项目中, 我对TDD这种模式有了更深的理解.

TDD加深了自己对业务的理解. 举个例子, 如果我们要去分配一个任务给另外一个人, 如果只是一个unit test, 我可能会写下面的代码

public void should_fail_given_assignee_id_is_null(){
}

public void should_fail_given_assignee_available_time_is_less_than_assignment_duration(){
}

但如果先去考虑业务然后再去写测试的话

public void should_fail_given_assignee_does_not_exist(){
}

public void should_fail_given_assignee_do_not_have_enough_time_to_finish_this_work(){
}

乍看一下会觉得差别不大, 可是下面的代码对业务的描述更趋近于它的本质. 

另外一个关于TDD的新认知是: 在项目开始的初期, 我们可能会尝试多种方式解决一些技术上的问题, 来验证解决方案是否可行. 在这个时候, 由于多方面压力的存在, 可以暂时放弃TDD的实践方式, 以最快的速度解决问题. 这个阶段过后, 我们要有勇气删除掉已经存在的代码, 去用TDD的方式去实现业务功能, 优化我们的代码设计.

关于测试

Unit Test, Integration Test, Functional Test, Cucumber. 初接触这些, 跟大多数人一样, 觉得写测试是一个负担. 由于工作在一个遗留系统上, 准备测试数据的复杂度往往要高于实现一个功能. 不过这种疑惑后来也在与周围人的交流中消失了. 测试带给我的感觉是心安, 由于每次代码的提交都伴随着一次CI构建, 完备的测试保证了我们能够尽快发现提交代码引入的问题, 金字塔型的测试体系更是对持续部署迭代发布所依赖环境的重要保证. 至于在写测试时间花费上的疑虑, 也在和同事的交流中得到一个较好的说法. 写测试耗费时间并不应该是考虑测试应不应该存在的原因, 而更应该是持续改进现有开发环境以得到一个更好的软件开发实践的动力.

关于Pair

对于我来讲, 进入一个新项目, Pair会使我在较短的时间内尽可能多的了解整个系统和它的代码风格. 如果项目采用的是自己没有接触过的新技术, pair是一种更加快速的学习过程, 编写代码的时候什么都可以去问, 这远远要比你自己看书做练习题快的多. Pair的另一个作用是知识分享, 这个最大的作用是保证项目不会在个别人员流失后无法进行, 额外带来的一点小好处是从来不用担心在休假的时候被同事打电话拉去工作. 此外pair也应该算是另一种形式的code review吧.

pair中也有一些问题, 长时间精神高度集中的pair会使人疲劳, 所以pair的效率并不能每天都保持在一个很高的水平.

关于交流

交流与技术同样重要, 技术是实现功能的基础, 交流是实现正确功能的基础. 项目中每个人对业务需求的理解不可能达到很一致的状态, 所以经常会发生的情况是, 客户想要的不是BA分析的, BA分析的不是Dev实现的, Dev实现的不是QA测试的, 整个流程下来期望的功能被实现的面目全非. 正是由于这种问题的存在, 项目中成员间快速有效的沟通就显得更加重要了. mini showcase, stand up这些沟通方式都能很好的帮助项目中的每个人在所做事情的各个阶段得到足够多的反馈, 保证业务实现的正确性. 对于Dev来讲, 每天少一点ticket和defect, qa不再追着你的屁股后面催, 开发也是一件很快乐的事情.

半年的一个小小总结.