开发常用工具箱

potian的软件开发常用工具箱 [转]
我说说自己开发一个Java程序常用的工具箱
我说说自己开发一个Java程序常用的工具箱（仅为个人习惯）：
准备篇
1。白板（白板笔）。
1)需求阶段和客户讨论问题时分析、设计、客户在这里自由交流大家对问题的看法
2)在项目分析和设计阶段用来进行头脑风暴，是设计的最重要的工具。白板上画的可以是UML图，但也可以是项目团队能够理解的任意图形，或者就是简单的线条、图形都可以
3)无处不在的讨论，任何时候对需求的理解和对设计的讨论都在白板上进行
一般公司里面经常会出现白板笔太久没用水用光的时候，所以我一般都要提醒后勤人员买好充足的笔，用完笔以后要盖好盖子。
2卡片（和图钉）
1） CRC是除了白板以外第二重要的设计工具，这种卡片在中国很难买到，所以一般用文摘卡代替，CRC的重要作用在于可以进行角色扮演，验证设计的准确性。CRC的前面分别写责任和协作，背面可以进行备注
2） 用户故事卡，我回去定制一个泥印，直接盖在空白的用户故事卡上，这个卡片在需求阶段可以任意传递、撕毁、重写、合、分裂，卡上有故事卡编号、优先级、风险评估和当前的迭代序号，用户故事卡订在一个大家都能看到的离开发位置较远的墙壁上
3） 任务卡，任务卡从故事卡分裂而来，用图钉钉在开发员的电脑旁边
4） 编码卡，主要纪录需要实现的测试，需要注意的事项，等等，开发人员不断增加条目、划去条目，是对一个人物而言的备忘录和todolist
卡片一定要硬的，方便传递，有质地感，有一定的厚度
***************
1。在CRC的扮演过程中，举起一张硬卡片和一张软软的纸感觉不同
2。在撕卡片的时候，要有声音有感觉，表示我们对需求的更改是非常欢迎的，不是说些下来的东西就完全算数了
3。在需求过程中，卡片需要在客户、程序员、分析人员之间传递，纸片太软
4。客户需要根据价值把卡片按优先级分堆，决定我们的迭代和发布，纸片不方便，容易遗漏和混淆，不太正式
5。故事卡可能一部分可能移到下一个迭代，不能在墙上贴了一段时间就变得破破烂烂
***************
3．大坐标纸（长的直尺、各种颜色的笔）
我通常会在项目的进行过程中记录各种度量，这包括有效代码增长率、测试代码增长率、功能测试通过率、故事卡完成率、测试覆盖率（具体工具在后面介绍），悬挂在比较高的位置，大家一眼能够看到的地方
另外每个迭代的每个理想天都会检查每个人任务完成的情况，延迟、提前、原因、重新估计时间、剩余实践，根据不同情况用不同的颜色表达，画在一张大白纸上，不够的话可以慢慢接长，贴在显而易见的墙壁上
*************************
对于第3部分而言，这又是一个交流问题，重在交流和整体感觉，而不是具体的数据
客户、老板、项目开发人员、管理人员各位都希望知道现在进行的情况，开发人员也需要对项目中其他人员地进行情况有所了解，所以最好把这些东西放在最显而易见的地方。每个相关人员都可以一眼感觉到项目的"温度"
一般来说，我检查和度量的时间是在一个理想天，也就是3-4天的时间，一般采用的工具是JavaNCSS ，我有编写一个小小的工具，利用Javancss计算出源代码的统计信息，按照时间为横轴，画出增长的曲线，然后手工画到墙上的大纸上。一些例子
1。产品代码增长率，这个增长率应该在项目前期比较高，且比较稳定，如果某段时间的增长率出现异常情况，可能在设计或实现过程中碰到了某些问题。在项目后期应该逐渐降低（但不意味着故事完成增长率的下降，相反体现在故事增长率和测试增长率的相对提高），这是我们对重用的一个期望。代码增长率也是项目管理人员比较关心的问题。
2。单元测试代码增长率，一直保持在比较稳定的增长率，不同阶段和产品代码的增长之间保持一个相对比率，例如从1：1到1.5：1到2：1，
3。代码覆盖率，用clover可以很方便地生成，CLover的历史信息和增长信息特别有用，当然还需要手工摘录最重要的几条曲线
4。用户故事完成率，这是客户需关心的东东，只有所有的用户故事完成，才能号称迭代正确完成，不然写了多少代码读是没有意义的
5。功能测试增长率和Bug密度，功能测试反应的未通过的bug，这个最好是分界面、WEb曾或者数据库层、模型层，统计在不同模块的密度，这个Bug率最好加上估计的时间，例如1小时、2小时，半天等等。功能测试没有100%通过是正常的，但是必须纪录BUg的相对密度。
至于开发人员的进度模板，这个就比较复杂了，不同的项目也有所调整，我曾经用XPPlanner产生过报表，但太灵水了，所以不得已用excel画的，每1理想天更新一次，这是很重要的一个掌控工具，一个迭代周期内必须尽早估计到可能需要的延迟、客户需求变化的调整、一些人提早或落后需要开发人员之间相互调剂等等，据说2003年生产力奖的XPOne非常好，但没有评估版本，我每次只能用手工做。
这个象20个人的团队大约要花上3-4个小时左右，所有人都要参加，要充分交流分析体现或落后的原因、要及时调整后面的估计，同时尽量让每个人发表自己的意见，例如可能需要交换任务，重新调整任务的时间、加入新的任务、把某些任务延迟到后一个迭代、解决本天内的一些新发现的公共问题等等。
当然，最后还是要抄到墙上去
*****************************
4、小桌子（香烟、绿茶、咖啡或水果）
工作一段时间，2个小时左右，开发人员可以三两成群地在小桌子（或者是吸烟区）旁边抽烟、喝茶、咖啡或者水果，交流相互的心得、讲讲笑话、谈谈碰到的问题。很多问题就在这里面谈出来、解决、得到线索等等，团队的气氛经常就是在这个时候变得慢慢融洽。
Wiki
我是Snipsnap的老用户，所以项目开发的时候还是用SnipSnap，SnipSnap的好处是使用简单，配置方便，涉及到项目开发的具体应用，通用词汇表的建立、概念的交流、工作方式的讨论我喜欢在Wiki上进行，Wiki也是一个项目知识库实现的最佳方式，包括项目所需要的配置说明、项目用到的书籍、文章和相关的讨论
第二个Wiki是Fitness，这是做功能测试最好的工具之一
关于Wiki，我自己有项目管理中的新想法，不过很多相关的产品都不是开源的，太贵，所以目前还没有应用起来，等我自己了，呵呵
IssuerTracker
Jira,这是我少数选用的商业产品，举我自己的感觉，这是Issuer里面No.1的产品，可惜和XP的项目计划偏差较大，对于时间估计和流程配合不够流畅。
为什么用Wiki的原因，我在另一个帖子已经有些说明，主要的问题是WIKI的形式比较自由，能够充分发挥想象力，不需要非常正式，但是又容易在开发的过程中积累起很有意义的思考、文档和模式。总而言之，是非常利于不拘形式的自由的交流。
Wiki的简单和目前很多WIKI的可扩展性，使得我们能够把Wiki和其他软件，例如Issuer，CVS等方便地结合起来。
Wiki软件和Eclipse的结合可以产生很多对项目开发有益的想法和帮助，虽然这一块目前还不时有很多公司在做，但我觉得一些小小的结合就能产生很好的交流效果和文档组织。
使用Jira的原因是它是面向开发人员的一个tracker工具，在开发阶段它的表现要胜于其他跟踪系统，它的灵活性和新近的插件机制也能够方便我更好的扩展何时佩。
JUnit,这个没什么好说的，当然用法上自然是最偏向于KentBeck的用法。用Cactus测试感觉不是很方便。由于struts已经不用了，用JUnit就能够测试Webwork的Action，所以Web层我基本上已经不测了。
Clover，虽然TDD的覆盖率肯定是非常高的，但很多项目不做TDD的，我自己有一个小小的工具，自己用用还可以，但项目中没办法用， JCoverage是开源的，红工厂也有产品，但是我没用过
用户测试，目前我在第二个小项目中用Fit和Fitnesse，但没有在大项目使用的经验。以前是自己写excel到数据库转换，用JUnit测的，比较麻烦
IDE，最早用的JBuilder，后来用的NetBean，在后来就是Idea，当初被Idea的refactoring功能之强大正酣，但有一次KentBeck在UMLChina聊天的时候说起Eclipse，自此就没有变过。吸引我的原因有很多，例如：
1）KentBeck为什么推荐Idea和Eclipse，而不推荐JBuilder，呵呵
2) EricGamma领导下做的，那还会有错？，哈哈
3）free.我已经被Borland公司的人搞得不行了
4) 界面风格，当初的SWT表现还是非常优异的
5）Eclipse的重构支持不弱于Idea
6） Eclipse对于程序员intention的理解稍稍弱于Idea，但确实也在不断进步
7) Eclipse很早就有内建的Ant和JUnit集成
Eclipse的CVS集成简直让WinCVS变成一场恶梦。能够让敏捷编程的配置管理策略非常容易地实现起来。CVS能够真正成为团队协作的一个基石。（这些策略我在自己的wiki上有很详细的描述。最近因为一些原因，暂时无法浏览。）Eclipse的CVS集成也让CVS和其他版本控制软件之间的区别变得不是那么重要。
第一个完全构造在微核心上的开发工具，做程序的好这一口，相信好的结构和体系有好的程序
综合起来，Eclipse的很多设施方便XP的很多规则执行，而且又是免费的，没理由不用呀
版本管理：CVS，当然CVS有很多多的问题，例如没有事务呀，不支持属性呀，不支持移动和重命名呀，但CVS是世界上用得最多的版本控制工具，那么多大小项目在用，那么多产品总是先在CVS上实现，再移植到其他软件上。又是免费的。CVS最重要的特点当然是non-lock方式的开发。Subversion可能会是我的下一个选择。
CVS上我偶尔用的是CVSSTAT，但最近Fisheye异军突起，可惜是要钱的。
构造：当然首先是ANT，一直想看看Maven，但好像太复杂了，试了一段时间，现在还是ANT.然后是集成构造的管理，我一开始就用的是CC，就没有再去想AntHill。CC除了可以用Email和Web通知之外，还可以用Jabber通知，我刚在用Jabber的eclipse插件，还没有什么感觉。实际项目中还是以Email为主。
画图工具：我好像很少画图，除了在白板上，倒是写文章的时候经常用Rose，画出来的图很漂亮，适合放在杂志上面或者放在网页上.设计文档里面的图基本上也是用visio画的，但通常很少，一般是针对整个项目核心的一些结构和设计。当然项目后期有的时候需要很多的图，我一般用Rose或者用JRefactory逆向出来。
数据库：数据库总是需要两个的，一个是production的，另外一个是workspace的，production的可不是我说了算，如果要我推荐那就是SAPDB和Postgres了，当然Oracle和SQLServer是主流，我们也没办法的，但最近一个项目还在用Sybase。
workspace的数据库是开发用的，如果我没有用Hibernate之类可以方便移植的数据库，那就只能是production数据库了。但最近一个项目就出现问题了，某公司当初是用Oracle开发的，但现在去买要花20万，一开始不想花这个钱，用SAPDB，不行,时间上也来不及了。如果是用ORM的，我一般现在用MYSQL