Trac 经验谈之（2）杂谈篇补遗
Trac 经验谈之（2）杂谈篇补遗
Trac 经验谈之（3）工作流篇
Trac 经验谈之（4）报表篇
Trac 经验谈之（5）插件篇
Trac 经验谈之（6 完）插件篇补遗
=================
Trac 经验谈之（2）杂谈篇补遗
赖勇浩（http://laiyonghao.com）
教训
一定要有模板
嗯，我说的是每一个任务单（ticket）的描述。如果没有一个描述模板，你得到的很大可能是一堆完全不知所云的文本。使用 TicketExtPlugin 可以很方便地做到这一点（见插件篇）。下面是我使用的模板，其中需求和改进的模板由我“抄袭”自禅道。
=======================改进========================= 建议参考的模板：作为一名<某种类型的用户>，我希望<某个功能的描述>更改为<另一个功能的描述>，这样可以<开发的价值>。 =======================需求========================== 建议参考的模板：作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<开发的价值>。 =======================缺陷========================== 缺陷表现： 重现步骤： 期望结果：
一定要定制报表
多问一下用户，比如老板、经理、制作人和测试人员，了解他们想要弄明白什么信息，然后建立起相关的报表给他们方便地使用。这样才能更好的让他们跟进项目的状态，推进项目的进展。
不要定义太多字段
因为 Trac 有 Custom Fields 概念，用户可以随意定义字段，事实证明过多的字段一点用处都没有。只有专业的测试人员会去设置类似功能组件、职能组件之类的选项，产品策划等人通常无视这些“小细节”，甚至优先级、里程都都是空的，或者默认的。
没有必要设置开始、结束日期
现在我们有这样的选项的，但在我们团队，超过 9 成的任务单没有设置两个字段，我相信设置了这两个字段了的任务单，也会有 9 成都没能在这个期间内完成。对于开发人员来说，能够在预设的里程碑里完成任务单，就相当不错了。
没有必要安装甘特图、日历图等插件
是的，在老板看来，盯着甘特图好像会有一种成竹在胸、一切尽在掌握的感觉。鼓起胆气跟老板说：放弃这自我良好的感觉吧，这玩意根本不准。另外霍夫斯塔特定律必须记在心头：软件开发的时间总是比想象的时间长，即使注意了霍夫斯塔特定律也是如此。出处：http://en.wikipedia.org/wiki/Hofstadter%27s_law。
搜索
Trac 的搜索相当不给力，比如你搜索“中文”两个字时，它会告诉你没有匹配的结果，并给出一条警告：
警告: 搜索查询太短。查询必须至少包含 3 字符。操蛋啊，尼玛啊，咱这是中文啊……两个字符可以表示整个世界了有木有！但是目前我还没有搜索到有效的解决方案，如果你有办法解决这个问题，请留言告知。谢谢。（2011年8月4日更新：flyinflash 朋友在本文后留言，提到了解决方案，我把它整合到了接下来的小技巧这一节中）。
小技巧
选择 owner
只要把 Trac.ini 的设置改一下即可：
[ticket] restrict_owner = true不过这不是完美的解决方案，因为 Trac 默认是显示注册的账号，这种英文字母+数字组合的名字对中国人太不友好了，比较好的方案是装插件，见“插件篇”。
继承 Trac.ini
经常要编辑 Trac.ini，容易出错。其实在 Trac.ini 加一个节 [inherit]，然后填好 file 设置，Trac.ini 就能从指定的 file 中继承设置。
[inherit] file = /path/to/global/trac.ini如果有多个配置文件，那么需要用逗号（,）隔开。如果 Trac.ini 中又有相同的节项的话，父配置就会被 override，所以最佳实践是 Trac.ini 只有 [inherit] 这一节，然后所有的具体设置都放在不同的文件中给 Trac.ini 继承。
wiki 转 html
有时候需要把纯文本格式的 Wiki 转成 HTML 页面，比如发表到博客什么的。这时候可以使用这个方案：http://trac.edgewall.org/wiki/CookBook/Scripts/StandaloneWiki2Html#no1
搜索（2011年8月4日更新）
把 trac.ini 中的 [search] 这一节进行设置，即可搜索较短的单词，如中文的“义乌”，解决上文说的搜索警告的问题（感谢 flyinflash 的贡献）。
[search] min_query_length = 0
Hacking
在这个系列发表之后，朋友 @SparkleZeng 在微博上评论说（见：http://weibo.com/1764732124/xeT2KivsG）：“trac最大的好处是你可以二次开发，最大的问题是你需要二次开发才用的比较舒服。”说得太对了！所以对于 Trac 用户来说，Hacking 是必经的阶段，可能只是翻开源码直接 hard code 几行，也可能是编写一个插件来增进体验或增加功能。
本来我计划独立地写一篇来讲 Hacking Trac 这个事的，但在写这个系列的过程中我认识到还是介绍“使用”经验为好，所以就把这一篇缩写成一节。与使用 Trac 不同，想要 Hack 它，至少要读 Trac Developer Documentation（http://trac.edgewall.org/wiki/TracDev），而且有不少代码必须要了解。简单地直接在源码那里 hard code 几行就不需多方了，只要用好 find/grep 这两条命令就差不多了。
对于想要编写插件（Plugin）的家伙来说，Trac Component Architecture（http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture）是必读的，通过这篇文档才能了解到 Trac 的心脏—— trac.core 是如何实现一个易于扩展微型的组件内核的（显然，这对于我们设计自己的应用也有很大的借鉴和启发作用）。
清楚 Trac 组件架构的内核机制以后，相信大家对如何编写插件实现自己的功能已经胸有成竹了。这时候需要了解 Trac 的 Request Handling 流程（http://trac.edgewall.org/wiki/TracDev/RequestHandling），这里有两个漂亮的时序图交待了整个请求处理的流程。
跃跃欲试的你现在想动手了吧，不着急，先看一下 Writing Plugins for Trac（http://trac.edgewall.org/wiki/TracDev/PluginDevelopment），你可以在这里看到基础代码模板，如何发布、调试，还有你必须了解的 Extension Points（http://trac.edgewall.org/wiki/TracDev/PluginDevelopment/ExtensionPoints）。
别以为你现在就可以开始了哦，如果你需要在数据库存储数据，那你还要了解清楚它的 Data Models（http://trac.edgewall.org/wiki/TracDev/DataModels）和Database Scheme（http://trac.edgewall.org/wiki/TracDev/DatabaseSchema）。
最后，为了让全世界人民都可以用上你编写的插件，你还需要了解一下它的本地化技术（http://trac.edgewall.org/wiki/TracL10N）。好吧，现在你可以动手了，最后送你一份 Trac API Docs一路伴随你（http://trac.edgewall.org/wiki/TracDev/ApiDocs）。
