这次的 OpenParty 上自己听到的话题都是期待已久的，所以对于记录这些话题有着精心的准备，随身携带的记录本基本上留住了绝大多数我想要了解的细节。以下的文章包含了我在敏捷项目咨询、X-Moto开源游戏以及wxPython编写的个人财务管理软件三个话题中的如实记录，个别部分是当时演讲话题的细节呈现，整体可能略微缺乏条理，还望大家海涵。如果对于本次OpenParty "溪窗听雨"活动还不甚了解，欢迎您访问本次活动的介绍页面。
首先听的第一个话题是ThoughtWorks带来的 一次敏捷的咨询经历。整个话题中牵扯到了一个软件项目开发和管理中的太多方面，同时现场还有不少热心的听众参与讨论，毕竟敏捷是一个十分热门的话题。下面我就根据自己记住的内容分要点罗列一下。
首先听的第一个话题是ThoughtWorks带来的 一次敏捷的咨询经历。整个话题中牵扯到了一个软件项目开发和管理中的太多方面，同时现场还有不少热心的听众参与讨论，毕竟敏捷是一个十分热门的话题。下面我就根据自己记住的内容分要点罗列一下。
对于项目持续集成的改进：
实施多阶段的持续集成方案，从底层组件起逐步集成，这种方式适合于大型项目，上百人的团队。
对于项目测试的改进
自动化测试部分，在该咨询项目中，原本几乎没有什么正规的测试流程，TW的咨询师们首先加入功能测试，选用了Selenium作为解决方案。但是有一个问题是，进行功能测试的部分，应该由谁来撰写？是开发人员？还是测试人员？（在这个咨询案例中，TW认为应该该由开发人员撰写，此问题也引发了在场几位听众的讨论，最终没有一个压倒性的结果，应该说还是根据项目的需要而有所不同）
通常情况下，自动化的测试流程覆盖了软件测试中的大多数功能，那么测试人员的角色究竟是什么呢？TW的一位测试人员说，通常在测试中会把相关的一个行为作为一个可以被识别并评估的Story，逐一进行测试。测试人员所做的，应该说是从一个真正软件用户的角度，来使用并尝试发现问题。因为程序各种功能的测试，可以说只是最核心的功能实现，但是要注意软件最后打交道的是人，一些需要由人在使用中在识别和认知方面引起的偏差和错误，是必须经过实际使用的测试才能够保证相当高的质量。
通常情况下，自动化的测试流程覆盖了软件测试中的大多数功能，那么测试人员的角色究竟是什么呢？TW的一位测试人员说，通常在测试中会把相关的一个行为作为一个可以被识别并评估的Story，逐一进行测试。测试人员所做的，应该说是从一个真正软件用户的角度，来使用并尝试发现问题。因为程序各种功能的测试，可以说只是最核心的功能实现，但是要注意软件最后打交道的是人，一些需要由人在使用中在识别和认知方面引起的偏差和错误，是必须经过实际使用的测试才能够保证相当高的质量。
程序员管理中暴露的问题：
程序员是否一直很忙？在这个测试项目中，TW咨询师发现，在开始在客户处工作之后，提交代码最多的居然是TW的人员！而通过查询版本库显示，发现这个100个人的团队中，经常贡献代码的开发人员仅为20个左右，而这些贡献的人的平均代码量仅为10几行/每周！对程序员团队的管理不当，有可能是整个流程存在的最大的隐患。
ThoughtWorks的工作方式，
敏捷的目标，不是实施敏捷。一个问题所需要的解决方案从来不是解决方法本身。在推动一个问题解决的过程中，我们脑海中首先要谨记的是，我们的目标究竟是什么？不为敏捷而敏捷，我们的真正目标是提高效率。而借由这些方法、工具、理念来推动我们工作的过程中，我们原有的一些观点，是要被替换掉的，比如计算程序员的生产力水平的标尺，就不应该再使用代码行数这样的标准了。TW 举了一个例子，在某个咨询项目的过程中，经过两个月的工作，若说代码行数的变动，实际上是负值，因为整个团队在致力于将原来复杂的八个模块重构和精简为四个，大大提高了代码的可维护性，但是这样的工作的成效，就不能简单地用代码行数来衡量的。有一个可以值得考虑的标准是价值点的评估，即完成的这些工作，可以为最终的、客户满意的交付提供多少作用。只要是在朝着面向客户的最终交付这个方向上进行的努力，均可以认为是积极地完成了工作。
可以进行些梳理的是第三条，敏捷作为一个涵盖企业管理的概念，在很多情况下应用起来都会对组织结构的改变提出要求。但是我们应该怎么去作？如何去推动？上来就大刀阔斧地推动是完全不切合实际的，这些改变究竟是不是必须的？我们需要有相应的数据来支持。如果你能够有相应的证据可以表明，现有的一些体制，确实制约了我们在提高效率，和生产力上的努力，那么组织结构上的变化也并不是不可以的。
ThoughtWorks的大牛提到了"响应式设计"这个系统设计理念对于他个人的一个启示，即当所有的需求和限制摆在你面前时，你又尝试去完全考虑他们，那么此题目必是无解的。敏捷问题也是这样，很多时候的很多项目，都存在非常多的问题，但是我们始终要明确目标、以及要做的是什么东西，抓住重点来出发解决。错误是允许的，不允许错误就没有成功，
-----
而在这个游戏背后的技术，有一些也值得一提：
SDL 技术几乎已经是跨平台游戏的一种基础技术了，Vincent使用一个实例程序对使用SDL进行了简单的讲解。
ODE(Open Dynamics Engine)是一个开源的物理引擎，不只可以在游戏环境中使用，还可以应用于其它应用领域，如工程模拟等。采用BSD授权。现场展示了一个ODE设计者对于这个引擎的简介slide，有兴趣的朋友可以去看看。有一些商业游戏也使用了ODE引擎，包括 Bloodrayne 2, 还有 Resident Evil: Umbrella Chronicles(来源)
最终在这个项目中，应用了如下的解决方案：
- 实践、分阶段的持续集成
- 测试（Ant, Selenuim, Badboy)
- 代码规范检查 StateSVN
ThoughtWorks的工作方式，
- 结对编程，两个头脑并行工作有利于保证工作的高质量。在场很多同仁也纷纷表示，结对编程带来的好处是效率非常高，虽然在形式上看上去是降低了人员利用率，但实际上通过保证高质量所节约的成本是非常显著的。
- 迭代、日报(给项目经理以上的领导汇报使用)、ShowCase
- 站立会议：减少会议时间，绝对不拘泥于形式，注重解决问题。
- 沟通、沟通、再沟通
ThoughtWorks的敏捷原则：
- 不为敏捷而敏捷
- 只有领导支持是不够的
- 敏捷推进必然有组织结构的改变
敏捷的目标，不是实施敏捷。一个问题所需要的解决方案从来不是解决方法本身。在推动一个问题解决的过程中，我们脑海中首先要谨记的是，我们的目标究竟是什么？不为敏捷而敏捷，我们的真正目标是提高效率。而借由这些方法、工具、理念来推动我们工作的过程中，我们原有的一些观点，是要被替换掉的，比如计算程序员的生产力水平的标尺，就不应该再使用代码行数这样的标准了。TW 举了一个例子，在某个咨询项目的过程中，经过两个月的工作，若说代码行数的变动，实际上是负值，因为整个团队在致力于将原来复杂的八个模块重构和精简为四个，大大提高了代码的可维护性，但是这样的工作的成效，就不能简单地用代码行数来衡量的。有一个可以值得考虑的标准是价值点的评估，即完成的这些工作，可以为最终的、客户满意的交付提供多少作用。只要是在朝着面向客户的最终交付这个方向上进行的努力，均可以认为是积极地完成了工作。
可以进行些梳理的是第三条，敏捷作为一个涵盖企业管理的概念，在很多情况下应用起来都会对组织结构的改变提出要求。但是我们应该怎么去作？如何去推动？上来就大刀阔斧地推动是完全不切合实际的，这些改变究竟是不是必须的？我们需要有相应的数据来支持。如果你能够有相应的证据可以表明，现有的一些体制，确实制约了我们在提高效率，和生产力上的努力，那么组织结构上的变化也并不是不可以的。
ThoughtWorks的大牛提到了"响应式设计"这个系统设计理念对于他个人的一个启示，即当所有的需求和限制摆在你面前时，你又尝试去完全考虑他们，那么此题目必是无解的。敏捷问题也是这样，很多时候的很多项目，都存在非常多的问题，但是我们始终要明确目标、以及要做的是什么东西，抓住重点来出发解决。错误是允许的，不允许错误就没有成功，
-----
接下来 Vincent Du 介绍的 X-Moto游戏话题。X-Moto 这个游戏是 Elasto Mania 类型的游戏（商业游戏的最新对应是在Xbox 360 Arcade Live上的 Trials HD），玩法很有趣。
这是一个需要很多技巧的游戏，完全免费，开源。游戏画面的感觉，是很有趣的"皮影戏"感觉，尤其是按下空格键控制摩托转向的时候，在场大家都在感叹："哇，皮影耶"。游戏画面还有一个更加简洁的Ugly版，适用于低配置的机器。这个版本的画面，完全是用线条来表现的 :)
这是一个需要很多技巧的游戏，完全免费，开源。游戏画面的感觉，是很有趣的"皮影戏"感觉，尤其是按下空格键控制摩托转向的时候，在场大家都在感叹："哇，皮影耶"。游戏画面还有一个更加简洁的Ugly版，适用于低配置的机器。这个版本的画面，完全是用线条来表现的 :)
游戏很细致，我开始一直认为这就是个核心如NES游戏的那种游戏，没想到物理引擎的设计贯穿了整个游戏（虽然物理整个的感觉并不完全要展示显示世界的情况，如在游戏中为了达到很多特殊效果，引力偏小）。规则的设置也很细致，玩家的角色不能碰触任何物体，而摩托车则可以。游戏有着现代竞速和技巧类的游戏都具备的元素，录像功能，Ghost鬼影功能，更有一个成熟的网上社区，玩家可以交流游戏技巧，比拼游戏技术（世界排名），单账户的多点信息同步、更可以交流自制地图。
游戏的地图编辑器技术十分有趣，使用了InkScape 这款自由的矢量绘图软件，游戏的编辑器功能被设计成了此款软件的一个插件。这是一个巧妙的、典型的自由化设计。试想对于游戏设计者来说，只要开发一个小插件，就可以拥有一个用户繁多的全功能编辑器可以使用，而对于用户来说，为一个游戏或软件做出些创意性的设计也变得不再复杂，只需使用自己熟悉的编辑工具即可。
而在这个游戏背后的技术，有一些也值得一提：
SDL 技术几乎已经是跨平台游戏的一种基础技术了，Vincent使用一个实例程序对使用SDL进行了简单的讲解。
ODE(Open Dynamics Engine)是一个开源的物理引擎，不只可以在游戏环境中使用，还可以应用于其它应用领域，如工程模拟等。采用BSD授权。现场展示了一个ODE设计者对于这个引擎的简介slide，有兴趣的朋友可以去看看。有一些商业游戏也使用了ODE引擎，包括 Bloodrayne 2, 还有 Resident Evil: Umbrella Chronicles(来源)
-----
由JiaKuan朋友带来的"用wxPython开发并理财"，这个话题本来就是我关注的重点，因为我打算使用wx来开发一些GUI程序，想要学习些技巧。不过最终这个话题带给我的收获远远不限于wxPython技术，而是多方面的收获。
Jiakuan在开发这个软件之前，已经使用Java技术开发了三个版本，但都遇到了效率、可维护性等的问题。决定开始一个更好的版本。
为什么选择wxWidgets 而不是QT? QT也是不错的选择。进行过简单的比较，感觉wx的原生控件会给用户更好的体验，而且整个库打包起来会比较方便。正是因为存在这些问题，在确定了使用wx库进行开发之后，所要实现的目标都十分简单，使用wxPython版本要实现的几个目标：10M大小以内的安装包 。
接下来JiaKuan分段落讲解了一下整个软件在几个不同部分中遇到的技术问题和解决方式。
程序的国际化部分：
GUI设计
自动化发布
DB应用及大数据量测试
自动生成站点
接着JiaKuan谈了很多和这个软件理念上的东西。如何利用科学的会计管理方法来管理你个人的财务信息。我简单地记录了如下要点：
在个人会计、理财方面，数据记录是为了分析，而分析是为了观察是否在哪里存在问题。如果你希望通过数字来证明自己的生活水平至少是从帐面上看是逐步提高的，那么一个增长的财务分析曲线可以帮助你更清晰地来看到你目前的情况。从报表统计中发现规律，从而发现问题。
不了解会计怎么办？会计是一种规则，不需要什么创造性和灵活性，只要遵循这个规则来操作就可以了，并不是很难掌握。
还不明白软件中与会计术语相关的条目？软件内建的大众模式可以用普通用户很好理解的模式来录入信息，同时软件将数据映射到与理解会计相关知识的用户使用的专业模式一致，最终都可以生成符合会计原理的报表，同时在接触这些报表中，不太理解的用户可以学习其中更多的概念。
关于这个软件的更多信息，欢迎访问官方网站 : 家宽理财
----
关于每次OpenParty回顾文章规模的问题：我开始使用一个笔记本来记录所有一切我认为值得记录的细节，便于自己回忆和理解。但是写下来之后，发现最终总结到文章的很多东西都是简单的堆砌。一般来讲，自己选择去听的项目都有着相应的准备和充分的理解，所以即使是细节积累的记录，都是于自己比较有意义的。但是我不清楚对于一个对此话题不甚理解的读者，这样的意义是否还重要。这样的方式还有一个缺点就是文章会非常地长，文章会长到我的众多朋友实际上都很少看完我写的整篇文章......
除此篇幅本身的结构以外，我能想象到的一个形式上的改进就是适当分清主次，着重针对一个话题梳理出脉络，随后进行延展，而其它的话题则可以忽略掉一些细节，只着力于主题即可。这样也避免了自己对于某些技术了解的不甚深入（譬如本篇的敏捷话题部分，我于此的实际经验要小于书面上的理解，如果有误欢迎指出），而堆砌细节反而可能弄巧成拙的情况。
自己也考虑在未来多多尝试几种风格，尽量让大家更有效率地获取知识。既不是迷失在字数近乎无限的冗长的细节迷宫中，又不是在精简到渺渺几行的语录体文章中揣摩技术细节的痛苦，这个介于两者之间的程度，我会努力找到更适合的方案。
所以我很希望听听大家的意见，这样的细节大餐或者主次分清的形式你更喜欢哪种？如果有什么更好的建议欢迎提出，谢谢！
由JiaKuan朋友带来的"用wxPython开发并理财"，这个话题本来就是我关注的重点，因为我打算使用wx来开发一些GUI程序，想要学习些技巧。不过最终这个话题带给我的收获远远不限于wxPython技术，而是多方面的收获。
Jiakuan在开发这个软件之前，已经使用Java技术开发了三个版本，但都遇到了效率、可维护性等的问题。决定开始一个更好的版本。
为什么选择wxWidgets 而不是QT? QT也是不错的选择。进行过简单的比较，感觉wx的原生控件会给用户更好的体验，而且整个库打包起来会比较方便。正是因为存在这些问题，在确定了使用wx库进行开发之后，所要实现的目标都十分简单，使用wxPython版本要实现的几个目标：10M大小以内的安装包 。
接下来JiaKuan分段落讲解了一下整个软件在几个不同部分中遇到的技术问题和解决方式。
程序的国际化部分：
使用了Python的 getText模块
PO/MO 国际化部分翻译 应用程序的字符串，使得程序可以支持多种语言
自己写了一个小脚本在每次发布的时候对翻译的字符串文件进行合并，自动处理好之前存在的翻译，这样每次只需处理新的翻译就可以了
PO/MO 国际化部分翻译 应用程序的字符串，使得程序可以支持多种语言
自己写了一个小脚本在每次发布的时候对翻译的字符串文件进行合并，自动处理好之前存在的翻译，这样每次只需处理新的翻译就可以了
GUI设计
我自己(CNBorn)在开始GUI项目的时候，而令我最为头痛的是wxPython的界面设计。我使用过wxGlade来进行设计，但是真是感觉很难用。虽然去年的Gnome Asia 08峰会上专门有一个话题来帮助大家学习使用Glade，但是时间长了以后，这个软件又变得很难用了。JiaKuan在设计这个软件时，先使用的是Sizer，后来变成了使用XRC方式进行构建，即先使用程序生成XML代码，然后根据XMl代码来生成wx的窗体代码。wxFormBuilder这个工具使得设计工作更为简单直观。使得设计流程更加快捷。
在界面设计上，JiaKuan使用了一个叫做GUI Design的软件来生成界面原型，十分漂亮，不过显然这个软件是个商业软件。
在界面设计上，JiaKuan使用了一个叫做GUI Design的软件来生成界面原型，十分漂亮，不过显然这个软件是个商业软件。
自动化发布
使用了PyInstall来生成发布文件夹，这个工具十分方便，可以自动复制相关的依赖库直接到文件夹里。然后在通过脚本调用来生成安装程序。这整个过程完全来通过脚本执行，完全自动（的确是《卓有成效的程序员》所推崇的观点：让计算机来完成重复的工作。）
封装时的脚本做了一个Hack：有打包和生成的过程中，一些地方需要输出日志信息，但是无法同时在屏幕输出，又向日志文件输出，于是就自己写了个函数，来通过另一个线程来判断日志文件的增量，基本达到同步输出。设计时考虑到可能会有效率问题，但是实际使用中发现不明显。
单元测试封装时的脚本做了一个Hack：有打包和生成的过程中，一些地方需要输出日志信息，但是无法同时在屏幕输出，又向日志文件输出，于是就自己写了个函数，来通过另一个线程来判断日志文件的增量，基本达到同步输出。设计时考虑到可能会有效率问题，但是实际使用中发现不明显。
应用了不少的Unittest，主要都集中在程序的核心部分，作为一个需要严谨的技术软件，核心部分的质量必须过硬。一般来讲，先写出单元测试，然后在与其结果进行调试，这种做法符合TDD的要求。单元测试也是逐步增多的。
DB应用及大数据量测试
很多问题只有在大数据量的时候才能够暴露出来，那么如何进行大数据量测试？大数据量有两个来源，一个是JiaKuan细心记账的几年间积攒的数据，还有就是写了一个机器人，基本根据人们消费、收入的习惯生成了一个7万条左右的数据。
数据库使用SQLite。基本上，在大数据量的情况下，程序会暴露出问题，如果没有问题，说明测试可能有问题 ：)
在几万条的情况下，有些功能速度明显特别慢。如何优化？优化SQLite，索引的使用很关键，如果你在一个表中建立了多个索引，那么通常其实只有一个索引是有效的，要注意这点。另一个就是在一个非常复杂的查询语句中，尽量保证所有的Condition都有效地运用到索引，这样可以大幅度提高速度。应用了这些之后，软件中有一个查询的速度从39秒提高到0.29秒。
程序中实现了一个简单的ORM，这个并不是本意，本来是打算采用SQL语句进行操作，随后在系统逐渐变化的过程中，数据库操作也逐步复杂，在把相关部分的处理重构以提高复用性以后，就成为了一个简单的ORM，传入的是对象，输出的也是对象。
数据库使用SQLite。基本上，在大数据量的情况下，程序会暴露出问题，如果没有问题，说明测试可能有问题 ：)
在几万条的情况下，有些功能速度明显特别慢。如何优化？优化SQLite，索引的使用很关键，如果你在一个表中建立了多个索引，那么通常其实只有一个索引是有效的，要注意这点。另一个就是在一个非常复杂的查询语句中，尽量保证所有的Condition都有效地运用到索引，这样可以大幅度提高速度。应用了这些之后，软件中有一个查询的速度从39秒提高到0.29秒。
程序中实现了一个简单的ORM，这个并不是本意，本来是打算采用SQL语句进行操作，随后在系统逐渐变化的过程中，数据库操作也逐步复杂，在把相关部分的处理重构以提高复用性以后，就成为了一个简单的ORM，传入的是对象，输出的也是对象。
自动生成站点
生成静态文件供用户展示。采用Maven+Python，使用了自己设计的类似模板的技术来生成静态文件。
接着JiaKuan谈了很多和这个软件理念上的东西。如何利用科学的会计管理方法来管理你个人的财务信息。我简单地记录了如下要点：
在个人会计、理财方面，数据记录是为了分析，而分析是为了观察是否在哪里存在问题。如果你希望通过数字来证明自己的生活水平至少是从帐面上看是逐步提高的，那么一个增长的财务分析曲线可以帮助你更清晰地来看到你目前的情况。从报表统计中发现规律，从而发现问题。
不了解会计怎么办？会计是一种规则，不需要什么创造性和灵活性，只要遵循这个规则来操作就可以了，并不是很难掌握。
还不明白软件中与会计术语相关的条目？软件内建的大众模式可以用普通用户很好理解的模式来录入信息，同时软件将数据映射到与理解会计相关知识的用户使用的专业模式一致，最终都可以生成符合会计原理的报表，同时在接触这些报表中，不太理解的用户可以学习其中更多的概念。
关于这个软件的更多信息，欢迎访问官方网站 : 家宽理财
----
关于每次OpenParty回顾文章规模的问题：我开始使用一个笔记本来记录所有一切我认为值得记录的细节，便于自己回忆和理解。但是写下来之后，发现最终总结到文章的很多东西都是简单的堆砌。一般来讲，自己选择去听的项目都有着相应的准备和充分的理解，所以即使是细节积累的记录，都是于自己比较有意义的。但是我不清楚对于一个对此话题不甚理解的读者，这样的意义是否还重要。这样的方式还有一个缺点就是文章会非常地长，文章会长到我的众多朋友实际上都很少看完我写的整篇文章......
除此篇幅本身的结构以外，我能想象到的一个形式上的改进就是适当分清主次，着重针对一个话题梳理出脉络，随后进行延展，而其它的话题则可以忽略掉一些细节，只着力于主题即可。这样也避免了自己对于某些技术了解的不甚深入（譬如本篇的敏捷话题部分，我于此的实际经验要小于书面上的理解，如果有误欢迎指出），而堆砌细节反而可能弄巧成拙的情况。
自己也考虑在未来多多尝试几种风格，尽量让大家更有效率地获取知识。既不是迷失在字数近乎无限的冗长的细节迷宫中，又不是在精简到渺渺几行的语录体文章中揣摩技术细节的痛苦，这个介于两者之间的程度，我会努力找到更适合的方案。
所以我很希望听听大家的意见，这样的细节大餐或者主次分清的形式你更喜欢哪种？如果有什么更好的建议欢迎提出，谢谢！
写的很详细，仿佛重新过了一遍这三个话题，赞一个。
感谢！记录水平直逼司马迁啊！重要的还有是具有国家地理频道式的真实性。