透明思考

坦尼斯突然转过身，看着南方。为什么是我？他不停地问着自己。我对自己的未来毫无概念，大家却都希望我领导他们。我没有像史东一样有驱逐恶龙，成为修玛第二的理想。我也没有像伊力斯坦有着把真神的知识散布给每个人的神圣使命。我甚至不像雷斯林热衷于追逐强大的力量。

史东推推他，示意他往前看。一线低矮的山脉出现在地平线上。如果坎德人的地图是正确的，塔西斯城就在这些丘陵的后面。

塔西斯，有翼的白色天鹅船，白色闪耀的高塔。美丽之城塔西斯。

河里的青蛙从哪里来，是从那水田向河里游来。

这样的设计调整 遇到过多少次？

基本上，每个项目都有，一年两三次吧。

下次做复杂的功能之前多做点设计吧，免得还有类似这样的调整。

好的设计真的不是做出来的。它是长出来的。

测试驱动出来的高质量的代码基础就像土壤，平时的持续集成和重构就像精耕细作。播下问题的种子，你就看着它长出来。有时候自然长出来的设计不对，于是你调整它。好的设计就在不断不断的调整当中浮现出来了。

（所以，一开始的设计是好的固然好，但更重要的是调整的能力。有些项目，好的设计会慢慢浮现出来。有些项目，好的设计也会慢慢腐化。）

可是，什么时候该忍着，什么时候才该动手调整？

不知道。不过，程序员的鼻子（和胃）知道。所以，别烦他们，别拿进度之类的玩意吓唬他们。给他们轻松，他们就会做出正确的事。

不然，反正你也没办法知道什么是正确的事。

偶像切尔斯基：敏捷质疑: TDD

我认为工业界是时候严肃认真的考虑测试环境了, 最好在语言中内建对测试的支持, 一些为产品环境设计的语言特性, 应该在测试环境中关闭, 而在产品环境中生效. 其实之前很多编译器都支持 Release 和 Debug 两种环境, 也是从代码质量的方面考虑的. 现在毫无疑问证实单元测试比 Debug 更有效, 是时候与时俱进增加对 Test 的支持而逐渐罢黜对 Debug 的支持.

不过我认为工业界是时候严肃认真的考虑的不是内建对测试的支持而是对类型推导的重视。要让程序不出错，一大堆和更大的一堆错误侦测机制都解决不了这个问题，你应该写不会出错的程序。当然debugger本身就是一个鸡肋，在exception stack trace帮不了你的情况下，debugger也帮不了你。

（写出像 Erlang 那样不会出错的程序吧。写出像 Haskell 那样不会出错的程序吧。）

尤其是在并行计算的时代。当然就算不考虑并行计算，类型体系是能让程序不出错的严肃认真的办法。写得快并且具有类型推导的语言是应该被严肃认真的考虑的。

Rake::Task[:default].prerequisites.clear
task :default => %w(db:test:prepare unit functional)

From IEEE Software

... human-centricity, technical orientation, discipline, pragmatism, empiricism, experimentation, and value orientation.

I like this most:

A disciplined process applies its chosen technical practices CONSISTENTLY, if not BLINDLY. These practices may include coding standards, frequent builds, requirements modeling, architecting, informal design, code inspections, regressive unit testing, and exploratory testing. A disciplined process also consistently applies management practices to coordinate activities, share knowledge, and control product artifacts.

IE就瞎菜了…傻了吧唧的蹦出来问“好像浏览器上有个操作死菜了，咱把它干翻吧？”烦人还是小事，十有九个人会点“Yes”，然后就真干翻了…

（根本原因是IE6/7不支持XPath，于是只好遍历DOM来找东西，which is非常慢啊…从一个500K+的DOM里找到一堆东西，Firefox只要几十毫秒，IE6要用到1秒…）

（试了一下 JQuery的CSS selector ，搞了个折中，IE6和Firefox都一百多毫秒，然则还是不够…几组查询下来IE还是瞎菜了…）

于是用空间换时间，在page上建索引。然则还是不行，因为最耗时的操作不止这一个…

于是把耗时的操作摘出来，原本都在onload里做的事情放在DOM loading的过程中，变成几百个小块来做。最耗时的两个操作，组装过滤列表和查询，用setTimeout变成异步的。

（这个时候很得意的问 郑晔 ：“阻塞操作太长怎么办？”得到答案：“搞成异步的。”）

然后一边唱着“牛x闪闪放光芒”，一边就发现break了另一处的功能…这个组件是被很多地方以很多方式重用的…

紧接着伤心地发现这块JavaScript已经非常混乱而难以理解了…重构迫切需要中…多想用JavaScript搞出如同Erlang一般优雅的并行计算序列啊…

（为什么每次感到很牛x的时候总会紧跟着很失落的发现有一大堆破事搞不定呢…这就是程序员的宿命吧…）

来自华为公司、负责软件质量和流程改进工作的周耀辉在第三届 敏捷中国 技术大会上介绍了 华为实践敏捷的经验

华为是偏重于流程为主的公司，多年之后市场环境不以公司为导向，在市场环境恶劣时候，华为公司发觉以流程为中心的环境很难应对这些要求，这是引入敏捷的原因。从2004年开始研究，在2007年步伐加快了，2007年下半年全面展开研究，今年年初开始全面进入试点阶段。

我曾经多次跟华为内外的朋友说到，华为的大问题有两点。第一是信息闭塞，公司内大部分员工不知道外面的世界（尤其是技术世界）在发生什么因此不知道很多已经被证明的最佳实践，公司外大部分人不知道华为里面是什么样子而导致华为被妖魔化。第二是基层员工极度缺乏决策权，大批只有执行力而没有微观决策权的员工使得持续改进难以成为整个组织的主旋律。

敏捷是改变这两个大问题的契机吗？看起来很像。一些好的现象已经开始出现。例如今天的演讲。一个华为的朋友说，在这种技术社区分享自己的经验，对于华为来说是第一次。

在保持执行力的基础上，给员工获取更多相关信息的渠道，使之具备足够的能力和空间进行微观决策，在全组织范围展开持续改进，并更加开放地与整个社区分享经验与收获。这样的一个华为，会是什么样子？

我说，它会是中国最好、最具吸引力的一家IT企业。

郭晓拍片 也挺上镜的，虽说有些紧张。

“精益思想就好比是做一批桌子，与其上午做好所有的桌子腿，中午做好所有的桌面，晚上组装，做流水线最后组装，不如以最快的速度出一批完整的桌子交付用户先使用” ─ Thoughtworks中国区总经理郭晓谈精益敏捷开发思想论方法

一个客户正在考虑用 Ruby on Rails 做他们的项目，但是又有些顾虑。其中一个问题颇有意思。

>> 4、网上搜索到的“初期入门，Ruby更容易，但一旦达到一定复杂度，那么Ruby的难度骤然加大。Python入门不容易，复杂的时候也不会太痛苦。rails有入门简单，深入难的问题。rails生成的目录是做什么用途？o/r mapping如何实现的？如何把数据从web中传递到数据库的。这些都是Ruby程序员早晚要面对的问题。 Python则不会这样，如果搞不清楚这些，大概根本没办法开始。集成度太高的快速开发工具都有这个特点，无论是VB、Delphi，还是.net，有多少使用了半年以内的开发人员可以说清楚工程目录下面所有的文件的用途、每个文件中的语法？我相信很多很有经验的用户也未必说的清楚。”你们怎么看？

第一，每个称职的程序员都必须了解那些“窗帘背后”的东西。做不出东西，和做出东西却不知道是怎么做的，两者没有区别。从某个角度，我并不认为Rails“入门简单”，因为有很多魔法需要去了解。而且使用Rails的新手们需要更严格、更紧密的指导，他们需要和有经验的程序员结对，不然他们很容易迷失而找不到最好的（或者说，最符合惯例的）解决办法。Rails程序员的高产是以初期的严格训练换来的，经过了这样的训练之后他们对项目有清晰的了解并且对代码有审美能力，所以我看不出有什么理由会“难度骤然加大”。

第二，Rails和“VB、Delphi和.NET”的最大区别在于Rails不做代码生成。代码生成是邪恶的，如果你需要维护自动生成的代码的话。而Rails不做代码生成的一个重要原因是Ruby的表达力，它能够在运行时变那些“传统语言”用代码生成才能变的一些魔术。有多少人能弄清楚一个Rails项目里所有的犄角旮旯呢？很多人都可以。因为这里没有自动生成的难懂的代码，并且每件事情都有约定俗成的惯例。不仅是自己的项目，就算别人的项目也很容易弄懂的，大家都用同样的惯例做这些事。

另一个 有趣的blog 这样说Ruby on Rails的缺点：

1.Ruby由日本人创造的，尽管ROR是丹麦的小伙子David开发的

如果我没理解错的话，这话的意思大概就是“Ruby on Rails没有缺点”。当然我并不这么认为，不过我确实认为它是目前看来最舒服的一个工具。

今天遇到两个tricky的东西，记下来。

1. 把十六进制数写到字符串里。

[0xEF, 0xBB, 0xBF].pack("C*")

（这个是 UTF8的BOM ，写在文本文件比如CSV的头上就可以让读取的软件比如Excel知道这是UTF8编码的文件。）

2. IE窗口的滚动条如果鼠标点下去也会触发 document.onclick 事件，而Firefox就不会。

（不明白为什么滚动条也可以算作document的一部分。）