摘要：从个人的角度来看，漂亮的代码首先得满足这么一点，可读性强。 如何让自己写的代码变得可读性强呢？ 从最简单也是最难的做起，有意义的名称 + 减少方法的长度。 我看过很多遗留系统的代码，里面大都充斥着... 阅读全文

摘要：在一个老团队中，推行一项新的实践是非常不易的。 如果要求，每天10点站立会议增强团队成员之间沟通。大家会心里先衡量一下，恩，不就是每天站个十几分钟，自己说几句话，然后听别人说嘛，不难做到。 如果要求，要测试驱动开发，必须先写测试代码，才能开始写产品代码。这样大家肯定讨论像炸开了锅一样，各种各样的质疑都会提出来，大部分人都会反对。 如果要求，结对编程，写代码得两个人一起写。大家那一瞬间肯定都会反应：没有私人空间，没有时间做其他事情了。异口同声反对... 阅读全文

摘要： 今天下午给同事就自动化验收测试做了一个简单的介绍，引起了大家的阵阵讨论。同时还有其他Team的人来分享各自的经验，他们也都做得相当不错。 测试包括很多种，单元测试、集成测试、功能测试、验收测试、数据库测试等等。撇开大家都熟悉的单元测试、功能测试不谈，为什么这里要单独拿验收测试来说自动化呢？ 阅读全文

摘要：4天内不停的做spike，终于搞清楚了要用到的大部分工具、框架不好用。很多全新的技术，文档不丰富，能google出来的资料很少，没有一个人熟悉，技术风险很大。 在项目开发过程中，创新占据了重要的地位。如果发现现有工具或者框架不能满足需求，或者不能提高生产效率的话，就需要考虑引进新的技术来满足需求。 但是，当项目决定采用一个新技术、新工具或者新框架的时候， 风险就会随之而来（更何况多个新技术），是... 阅读全文

摘要：去年有半年时间我呆在客户现场做项目，一直到按时保量成功交付。在项目开发期间出现过不少插曲，很大一部分都是需求方面的变化，我们团队也曾经担心着急过，怕项目不能按计划完成。后来事实证明，这些担心是多余的，只要有良好的开发过程，就能做到拥抱变化。 阅读全文

摘要：想起我刚毕业后，进入一家以软件外包为主的外企做开发。它使用传统的瀑布式的软件开发流程，没有使用任何的敏捷实践。我每天上班打开电脑，拿到自己的任务，然后从版本控制更新代码，打开工程按下Build，准备进行今天的开发任务。突然发现Build失败（通常是编译不过），大喊一声“谁Break Build啦”，也没有人响应，自己一个人郁闷，接着查看是哪些文件导致编译失败，找到最后的提交人，让他去Fix Build。后来团队里如果某个人Break Build，其他某些团队成员就在MSN的签名上写着“XXX Break Build，今天要请客吃饭”等等。其实Build失败在软件开发过程中会经常出现，不同的程序员实现自己的模块，写单元测试，完成后提交代码，难免会造成冲突导致Build失败。但是对于开发者来说，应当能够最快的获得当前Build的反馈，如果该Build失败必须在最短的时间内修复它，以免它影响其他人的开发进度。 阅读全文

摘要：这两天听说了一个很不错的基于.NET平台的Web自动化测试框架WatiN，下载试用了一下，的确很好用。它的基本功能和Selenium有点像，但是不如Selenium强大，没有脚本录制，只支持IE6/7等。它基本功能包括自动操作大部分的HTML元素，多种查找方式，支持AJAX，支持frame/iframe，支持弹出框等等。现在用一个简单的例子来看看怎样使用WatiN来进行TDD。 阅读全文

摘要：我进项目学习也有几天了，花了三天时间和印度同事Pair完成了一个Story，这算是我在TW的第一个Story吧，呵呵其实也算不上，因为业务逻辑我还没有弄清楚，代码都是由他一边写一边给我讲解，我的参与就算是Review吧 ：）但还是体会到Pair的好处，遇到不清楚的地方就问来进行沟通，有时候一个人写代码也不一定能考虑周全，而与之Pair的人能提出自己的意见使之更加完善。但是几天下来，给我印象最深的是站立式会议。 阅读全文

摘要：本文主要介绍了敏捷开发的一些基本实践，说明了这些实践是什么，有什么好处以及是怎样来进行这些实践的。 阅读全文