体制化
Posted on February 7, 2010
Filed Under essay, general | Leave a Comment
These walls are kind of funny like that. First you hate them, then you get used to them. Enough time passed, get so you depend on them. That’s institutionalizing
来自《肖申克的救赎》。
越来越觉得，所有的咨询工作，最终的目的，是唤醒被体制化的人，唤醒他们原本的认知，唤醒他们原本为之追求的希望，唤醒那些原本属于他们现在却不得不依赖于指令规则的直觉。
杂记：这乱乱的秋季
Posted on November 4, 2009
Filed Under essay, life | 2 Comments
1. 用上ubuntu 9.10了。感谢小罗，在我的刻录机坏了的情况下帮我下载好，然后把把ubuntu.iso文件直接刻进了光盘中，于是乎光盘中只有一个文件：ubuntu.iso. 我纳闷了好久，为什么光盘启动不来呢…
2. 说到换操作系统这个事情，我原来也以为会惊天地泣鬼神一把将所有文件该刻盘的刻盘，该保存的保存，结果发现什么都不需要。大多数的稍微有点价值的东西都在公司的svn里；在dropbox中，在Google Doc中，在slideshare里，在DreamHost的虚拟主机的Mercurial里，于是乎，毫不犹豫的Format整个磁盘重装。Ubuntu 9.10比起以前配置简单太多了，配上cn99的源，安装上无线和显卡驱动，半小时搞定……散热问题：遥想6.04的时候，写两个小时代码左手中指小指无名指就该烫熟了。ibus比SCIM输入那个舒服啊。以后PC笔记本就Ubuntu了。。。
3. IDEA开源了。终于可以堂而皇之的干掉eclipse这个不思进取的东西了。我仍然记得三年前Shane说，Eclipse的快捷键命名比IDEA容易记忆，例如绝大多数的重构都是Alt+Shift+XXX, 而IDEA则F5, F6, Alt-Shift全上。然而为什么这个不规则的快捷键没有成为IDEA的阻碍呢？也许，也许只是在“好用”与“合理”之间，“好用”带来的非理性稍占上风。
4. 到了11月天气迅速冷了下来。记起很久以前穿着破了两个大洞的牛仔裤，凉风肆无忌惮的灌进来，凉飕飕的感觉
5. 最近在阅读《第五项修炼》，建议咨询工作者都读一下，特别是OT相关的。对我而言，几乎是字字珠玑；书也挺厚，晚上在床上敲键盘垫上，避免烫到大腿。
6. 儿子明天满两个月，好动，很不老实，话多，真是集他爹妈之大成。
7. 新闻版署要终止网易《魔兽世界》审批，并酌情处罚。不说什么了，”互联网数据中心主任胡延平表示，这是网络游戏管理乃至整个互联网治理历程中极为荒唐的一个事件。本来国务院已经明确了管辖权和管辖范围问题，文化部主导网游管理，但是新闻出版署在十一前后的一些举措以及针对网易的惩罚动作，使得局面又一次陷入混乱。惩治网易，杀鸡给猴看、明示管辖权的意思远远大于个案本身。” 丢人。丢人。丢人。
8. 这个年代，破坏权威的东西一般来说是好的。
我们所不知道的Code Review
Posted on September 29, 2009
Filed Under agile, essay | 9 Comments
也许是待得太久，就像被一桶草莓酱从头浇到脚，尝哪里都是甜味一样，当初次看到Code Review成为一个如此重型并且低效的活动的时候，我才知道，草莓酱的外面，是空气，裹着大地的气息，大部分无味，又或者是烟草味，或者汽车的尾气。
先看一看我们看到的一个代码审查过程：
- 开发人员领到任务。
- 一周之后，代码写完了。他觉得没底，需要找业务专家技术专家来评审一下。这个时候他代码还没有提交。于是他把本地所有没有提交的、修改过后的文件，放到一起，压缩成rar包。找到他认为的技术高手业务高手（们），定会议室，发邮件通知。2小时过去了。
- 技术专家业务专家收到了邮件，由于缺乏上下文理解，以及长达数千行的源代码，这类邮件一般不看——因为看了也是白看。
- 终于到了Code Review的那一天。七七八八的来了几个人。一般来不全。因为高手之所以是高手，表现之一就是超级忙。
- 于是代码的作者开始，一行一行的将代码讲下去。前几十分钟高手们也没办法理解——毕竟是一个星期的工作沉淀，哪有那么快理解的。大约30分钟之后，专家开始提出建议意见。这些意见一般涵盖了语法、编码规范、可能的业务错误、模块间关系等。专家们毕竟是专家。2个小时之后，专家们离去。
- 开发人员虚心的把这些意见、建议写到小本子上。
- 开发人员可能根据专家的建议进行相应的代码修改并且提交，也可能不；可能改对了，也可能不。评审过后，后续的实施成为黑洞……
没了。
先思考一下，这个过程中的问题。
======== 思考的分割线 ========
首先必须承认Code Review的价值。经验丰富的专家们在做代码审查的时候，能够根据以往经验，规避重大缺陷的发生，对开发人员给予有价值的指导。然而，这个过程，太冗长，太低效。
- Code Review必须基于事实。这里的事实，就是，源代码库。SVN Repository, 或者HG/Git Repository. 在多人协作环境中，对于一份不在源代码库代码是基本不可信的 —— 你无法预知，他是否将会成为最终可工作软件的一部分。
- 积攒下来众多的代码修改，使得产生重型、低效的沟通方式成为必然。这类众型的沟通方式往往成本惊人 – 需要占用最好的人很长时间。
- 过分夸大专家的作用。根据以往经验，许多最终发现问题，回溯上来，其实是一些简单的逻辑问题。这些问题如果分散在平时结对或者更频繁的过程中，则更容易发现。很多情况下，是开发人员对常见的bad smell了解和修炼不足，而这些bad smell常常是导致问题的地方。例如在一个已经有3重循环的方法中加入了新的判断而没有测试；修改了函数的返回值而没有任何说明；if 判断中包含了多达4-5个变量的比较判断而没有抽象为一个更具业务含义的方法，等等。
- Review手段的原始落后。Review必须基于变化。会看报表的人都知道，看报表只需要看两个东西：趋势和拐点。Code Review也一样，只需要看变化。SVN/Hg/Git这类现代化的工具给我们提供了丰富的，基于changeset的compare工具。查看一天，整个团队的check in情况，顶多只需要10分钟-15分钟。
在敏捷过程中，Code Review几乎是一个被忽视的环节——不是不做，而是时时在做。结对时，我们会对结对伙伴的编码习惯、新写的类、变量表示质疑；提交之后，有代码静态检查工具、单元测试工具、覆盖率工具帮助我们检查有没有犯简单愚蠢的错误、有没有破坏既有功能；持续集成服务器则中立、不知疲倦的在每次我们提交之后运行所有的过程。
Code Review不是一个审查环节。不是一个考核环节。它是交流和反馈环节。
闲话：关于敏捷
Posted on September 23, 2009
Filed Under general | 6 Comments
(10:09:50 PM) Stephen H. Wang: 好像很久没看到你上网了。:)
(10:10:52 PM) Michael: 最近白天都不用电脑
(10:10:58 PM) Michael: 工作原因
(10:11:06 PM) Stephen H. Wang: 哦，不用电脑？太神气了。
(10:11:11 PM) Stephen H. Wang: 神奇
(10:11:22 PM) Stephen H. Wang: IT业居然不用电脑*-)
(10:11:45 PM) Michael: 做咨询了…主要靠说话
(10:11:59 PM) Stephen H. Wang: 我们领导明天准备给我们安排一个讲座：Refactoring – Martin Fowler的书。
(10:12:04 PM) Michael: 哦
(10:12:08 PM) Stephen H. Wang: 哦~~~~原来如此，好工作！
(10:12:12 PM) Michael: 谁来讲
(10:12:17 PM) Stephen H. Wang: 内部安排的。
(10:12:28 PM) Stephen H. Wang: 可是就是这个领导，居然不认可你们公司的工作流程…
(10:12:33 PM) Stephen H. Wang: 我只有无语了。
(10:13:04 PM) Stephen H. Wang: 我第一次看这个书，说实在的，收获太大了。
(10:13:20 PM) Stephen H. Wang: 越接触敏捷，越觉得你们公司厉害。
(10:13:54 PM) Michael: 哈哈
(10:14:00 PM) Stephen H. Wang: 越来越觉得ISO，CMMI那一套似乎说得好，行不通。 – 软件还是人写的。不是过程写的。
(10:14:17 PM) Michael: 。。。
(10:14:21 PM) Stephen H. Wang: 除非有无限的资源，否则，初级程序员写出的代码质量不高。
(10:14:22 PM) Michael: 你不是现在才了解吧…
(10:14:41 PM) Stephen H. Wang: 第一次接触敏捷的时候知道这个概念，但是现在是实践出真知。
(10:15:06 PM) Stephen H. Wang: Daily Build, Night Release….
(10:15:37 PM) Stephen H. Wang: 而采用瀑布式根本做不到，怎么应对市场变化。
(10:16:00 PM) Stephen H. Wang: 不过，近期也有疑问，就是敏捷如何做测量。
(10:16:21 PM) Stephen H. Wang: 怎么判定软件的质量好坏。例如，以前提到的千行代码缺陷率。
(10:16:42 PM) Michael: 。。。
(10:16:45 PM) Michael: 你自己觉得呢
(10:16:51 PM) Stephen H. Wang: 不知道
(10:16:54 PM) Stephen H. Wang: 所以才疑惑
(10:16:57 PM) Michael: 我们的客户前一阶段就问了这个问题
(10:17:12 PM) Michael: 我的回答是 — 这就是一个扯蛋的指标
(10:17:12 PM) Stephen H. Wang: 我想转型的时候都会有此一问。
(10:17:24 PM) Michael: 当然没这么说…
(10:17:27 PM) Stephen H. Wang: 那么，如何判定敏捷以后的质量呢？
(10:17:38 PM) Michael: 按照Story来
(10:17:46 PM) Stephen H. Wang: 是因为自动测试 – All passed 所以就是质量过关了吗？
(10:17:47 PM) Michael: 每个Story的缺陷数量
(10:18:00 PM) Stephen H. Wang: 可是，每天一个发布，如何统计缺陷数量？
(10:18:22 PM) Michael: 你要想到 缺陷率是典型的后置式检查
(10:18:32 PM) Stephen H. Wang: 对！完全同意
(10:18:37 PM) Michael: 而敏捷里面所有的实践，质量是隐含的，不可侵犯的
(10:18:49 PM) Michael: 这就是我们所说的Built Quality In
(10:19:09 PM) Stephen H. Wang: 嗯，这个概念的确是很好。
(10:19:12 PM) Michael: 从项目的一开始，质量检测环节就贯穿始终
(10:20:11 PM) Michael: 比如，刚开始写Story, 就要和测试人员定义验收条件；开发Story采用TDD的方式，通过测试来检验功能，类似于砌墙的时候先扯水平线，然后开始铺砖
(10:20:27 PM) Stephen H. Wang: 嗯。
(10:20:34 PM) Michael: 一般的敏捷项目，测试代码与开发代码的比例至少是1:1。我们的项目一般是2:1甚至3:1
(10:20:50 PM) Michael: 千行代码缺陷率对于敏捷项目而言是个笑话
(10:20:57 PM) Michael: 因为代码行数是个很扯淡的指标
(10:21:16 PM) Stephen H. Wang: 呵呵，这个指标是针对以前的过程式开发而设立的。
(10:21:20 PM) Michael: 分母都没意义，分子除以分母更没意义
(10:21:50 PM) Michael: 比如说，你用2000行写了一个功能，发现了1个bug；我只用了20行，也发现了同样的bug. 是不是说你就比我厉害呢
(10:22:07 PM) Stephen H. Wang: 同意。
(10:22:49 PM) Stephen H. Wang: 可是 – 社会平均生产率这个词总还是能够说明一些问题的吧。
(10:22:50 PM) Michael: 开发软件是一项艺术活动。代码行导向的指标完全将其视作计件工人。
(10:23:13 PM) Stephen H. Wang: 是的，即使MS，也有Software Factory一说。
(10:23:23 PM) Stephen H. Wang: 日企更是大行其道。
(10:23:44 PM) Stephen H. Wang: 所以，有一个词：软件蓝领就应运而生了。
(10:23:56 PM) Michael: 软件的生产率仅仅取决于可工作的软件。所谓的生产率应该是产生可工作的软件的效率。代码行只是手段
(10:25:27 PM) Michael: 比如，你每天写1000行代码，没有可工作的软件，因为你只写数据库后台了；我每天只写50行，数据库弄一点，前台加一点，当天发布，第二天客户就能用。按照代码行统计，你的工作效率是我的20倍；但按照可工作软件的角度，你的效率是0
(10:25:52 PM) Stephen H. Wang: 换个贴切的词，我的效果是0
(10:26:34 PM) Stephen H. Wang: 也就是说，我每天都给客户发一个“可用的”软件，永远的beta是这个意思吗？
(10:27:20 PM) Stephen H. Wang: 那么你研究过ISO关于质量的6个特性吗？
(10:28:13 PM) Stephen H. Wang: 错了，是ANSI/IEEE
(10:28:39 PM) Michael: 没..
(10:28:41 PM) Michael: 啥特性
(10:28:57 PM) Stephen H. Wang: Functionality, Reliability, Usability, Effetioncy, Maintenability, Portablity.
(10:29:11 PM) Stephen H. Wang: 他们还分解成20几个小的特性。
(10:29:15 PM) Michael: 这个没错啊
(10:29:37 PM) Stephen H. Wang: 我们的测试人员在担心，如果不用手工测试，无法确保这些特性都达到预期的指标。
(10:29:51 PM) Stephen H. Wang: 这个就是我疑惑的地方。
(10:30:16 PM) Stephen H. Wang: 当然，我也在想，他们是为了保住饭碗，拼命地证明自动测试工具无法全面达到测试目的。
(10:30:33 PM) Stephen H. Wang: 但是Agile的团队，会不考虑这些吗？我想不会的。
(10:31:41 PM) Stephen H. Wang: 比如说吧，一个B/S的系统，应该能够运行在,windows 2000/xp/vista + IE 6,7,8 or Linux + FF or Chrome or Mac + Safari…
(10:32:01 PM) Stephen H. Wang: 可是这些全测试的话，人工测试会花开发几倍的时间。…..
(10:32:22 PM) Michael: 保住饭碗是个很正常的需求。正视这个需求，Agile有更好的办法解决
(10:32:50 PM) Michael: 那就是，测试人员与开发人员属于同一个团队，在一张桌子上一起工作
(10:33:36 PM) Michael: 测试人员的手工测试有价值，但正因如此，所以要将那些无价值的人肉回归测试纳入到自动化中，让测试人员有时间做更有价值的手工测试
(10:34:01 PM) Stephen H. Wang: 我知道Agile的这个做法，可是这正是CMMI最反对的地方。他们认为开发和测试应该分属两个不同团队，测试人员的工资，奖金，评定等都不受开发经理的制约，这样他们才能有勇气去测试并公开全部的bug.
(10:34:23 PM) Michael: 你觉得合理么…
(10:34:30 PM) Stephen H. Wang: 似乎两者都合理。
(10:34:40 PM) Michael: 开发人员跟测试人员彼此仇恨就对来两者都好吗
(10:34:40 PM) Stephen H. Wang: 所以我最近一直在迷惘着。
(10:34:50 PM) Michael: follow your heart…
(10:35:17 PM) Stephen H. Wang: 而那个做法正是规避仇恨的方法。如果归于同一团队（非Agile模式下），测试人员真的没有勇气提出Bug。
(10:35:37 PM) Stephen H. Wang: 所以，我想Agile肯定有另外的理由，使得测试人员勇于提出自己的见解。
(10:35:42 PM) Michael: 勇气是敏捷基本价值观之一
(10:35:54 PM) Michael: 你不提bug, 是对开发活动的不贡献
(10:36:03 PM) Michael: 这只是个假设
(10:36:30 PM) Michael: 事实上，敏捷团队里面，测试人员的成长比普通测试团队里面的成长更快
(10:36:39 PM) Michael: 而且开发人员的测试观念也成长更快
(10:36:40 PM) Stephen H. Wang: 比如：刚才提到的千行代码缺陷率，这个可能才是真正的引起开发和测试之间有矛盾的地方？ – 因为Bug率直接影响了对开发人员的评价。
(10:36:58 PM) Michael: 其实从根本上说，就是个绩效问题
(10:37:09 PM) Michael: 按bug数量基本上是没戏的
(10:37:47 PM) Stephen H. Wang: 可否这么理解，开发团队和测试团队在一起，组成一个新的Agile团队，他们在一起，为了一个共同的目标而奋斗，一荣俱荣，一损俱损，才是能够让测试人员勇于提出Bug的根本原因？
(10:37:54 PM) Michael: 程序员产生代码行，测试人员消费代码行并提出bug, 这个貌似完美的生态系统粗鲁的无视软件开发完整性的客观规律
(10:38:00 PM) Michael: 没错
(10:38:13 PM) Michael: 整个团队只有一个目标：产生高质量的交付
(10:38:45 PM) Michael: 在此目标之下，以尊重 交流 反馈 勇气 简单为基本做事价值观和原则
(10:38:55 PM) Stephen H. Wang: okay，Quality和Delivery你都提到了，那么Cost呢，前两天听到一个老实说，敏捷是高成本的。我就更疑惑了。…
(10:39:06 PM) Michael: 谁说的…
(10:39:12 PM) Michael: 胡扯
(10:39:17 PM) Stephen H. Wang: 一个搞ISO/CMMI的老师…
(10:39:30 PM) Stephen H. Wang: 来跟我们讲如何进行软件的QA活动和Measure活动。
(10:39:50 PM) Michael: 靠，这样的话，如果没有充分的根据，会被喷的不像样子
(10:40:21 PM) Stephen H. Wang: 是啊，可是听课的大部分都是CMMI的忠实粉丝，所以我就没有多言，但是心里却很鄙视她的说法。
(10:40:53 PM) Michael: 你读过精益相关的书吧
(10:41:08 PM) Stephen H. Wang: 没有读过，只是听过TW的讲座。初步了解一点。
(10:41:24 PM) Stephen H. Wang: 知道这是起源于Toyota的一个生产汽车的思想。
(10:41:27 PM) Michael: 精益里面的核心观念：价值 价值流 流动 拉动 尽善尽美 这个你应该略有所知…
(10:42:32 PM) Michael: 核心思想是分析所有经营活动，找出其中的价值，找出价值流及其浪费点，使其流动，通过前端市场拉动，并让整个过程尽善尽美
(10:43:17 PM) Michael: 例如，软件开发中有价值的活动有 需求分析，架构设计，编码，测试，部署，客户演示等
(10:43:32 PM) Michael: 价值流基本与上述过程类似
(10:44:08 PM) Michael: 然而，这个价值流存在巨大的浪费：从需求分析到最终客户演示，在CMMI中需要几个月甚至一年的时间
(10:44:12 PM) Michael: 这是流不动的
(10:44:42 PM) Michael: 而敏捷里面，消除了漫长的等待而状态转换
(10:45:01 PM) Michael: 在一个短短的2周迭代开发中，上述所有活动都有一个完整的闭环
(10:45:23 PM) Michael: 客户可以在最多2周的时间里，得到一个完整可用的应用
(10:45:34 PM) Stephen H. Wang: 嗯，看来还是这个说法，就是非常多的瀑布迭代组成了一个敏捷整体。
(10:45:59 PM) Michael: 嗯
(10:46:01 PM) Stephen H. Wang: 那我有个故事要跟你分享一下。
(10:46:11 PM) Stephen H. Wang: 我去年到今年做了一个项目。
(10:46:24 PM) Stephen H. Wang: B/S的，java +jsp + DB2 + websphere
(10:46:33 PM) Stephen H. Wang: 采用了CMMI的开发方式。
(10:46:55 PM) Stephen H. Wang: 大约有100个左右的story（不知道你们的story是以什么级别划分的）
(10:47:10 PM) Stephen H. Wang: 最终制作了130多个页面。
(10:47:44 PM) Stephen H. Wang: 我的做法是这样的，先进行需求分析，彻底的分析，将每个细节都分析透彻，没有遗漏，没有二义性，没有错误….
(10:47:51 PM) Stephen H. Wang: 然后，组织开发团队进行开发。
(10:48:13 PM) Michael: 嗯…
(10:48:17 PM) Stephen H. Wang: 在我们公司几近变态的测试下，1次性通过测试。（这是以往没有的经历）
(10:48:33 PM) Stephen H. Wang: 我想知道，如果用敏捷的话，这么大规模的系统，你们大概需要多少个人月。
(10:49:03 PM) Stephen H. Wang: 我现在已经收到客户的需求变更要求。 – 我知道，如果用敏捷，那么这些要求将会在中间出现。而不是现在。
(10:49:22 PM) Michael: 我们不会这样估计。
(10:49:36 PM) Stephen H. Wang: 是的，我了解，这正是不同之处。
(10:49:59 PM) Michael: 我们会每个迭代给出一个交付版本，一般每两周给客户看一次
(10:50:05 PM) Michael: 让客户决定优先级
(10:50:25 PM) Michael: 当然在这之前，有一个大约2-4周的需求全面分析和优先级排序阶段
(10:51:13 PM) Stephen H. Wang: 我的需求分析投入了4个人，2个月。也制作了Demo和上千页的文档。我跟客户用了3整天，确认了所有细节。
(10:51:34 PM) Stephen H. Wang: 然后客户签字，这个就作为开发的依据 （当然，我这次的做法和以前比已经改革了许多）
(10:52:40 PM) Stephen H. Wang: 状态图，流程图，ER图….这些都是辅助我对需求进行分析的工具
(10:53:07 PM) Stephen H. Wang: Demo做的和成品都差不多了。就是数据是假的。
(10:53:38 PM) Michael: 这种做法叫lofi-prototype
(10:53:50 PM) Michael: 俗称原型法
(10:53:53 PM) Michael: 也不错
(10:54:13 PM) Stephen H. Wang: 正是如此，惭愧的说一句，我是在本公司第一个这么做的人。
(10:54:33 PM) Stephen H. Wang: 之前的系统更糟糕。质量不如意 – 这也是我一直探究如何解决的问题。
(10:54:51 PM) Stephen H. Wang: 举例来说，你们的测试人员会不会对左对齐右对齐，进行定义？
(10:55:31 PM) Stephen H. Wang: 就如这MSN的IM框，显示的log一定是左对齐的。
(10:55:31 PM) Michael: …啥叫左对齐？
(10:55:39 PM) Michael: 有啥用呢？
(10:55:49 PM) Stephen H. Wang: 并且，换行的时候必须根据窗口的大小自动调整。
(10:55:57 PM) Stephen H. Wang: 这是Usability的一项。
(10:56:10 PM) Michael: 如果客户需要，我们就做
(10:56:13 PM) Stephen H. Wang: 试想一下，如果Log都是右对齐的，我们看起来会是什么效果？
(10:56:28 PM) Stephen H. Wang: 可是如果客户没提呢？你们会主动的询问客户吗？
(10:56:33 PM) Michael: 当然会了
(10:56:43 PM) Michael: 但…这个左对齐是常识吧
(10:56:50 PM) Michael: 我们不做决定
(10:57:04 PM) Stephen H. Wang: 呵呵，这个不是常识……这个是技术。
(10:57:26 PM) Michael: 通过每个迭代的客户showcase, 让他们来提。然后统一放到剩下的，没有开发完的需求中，进行估计和优先级排序
(10:57:54 PM) Stephen H. Wang: 金额怎么对齐？日期怎么对齐？页面太宽了，HTML不能对每一列都设置固定宽度，如果这么做，等于对所有的都没有设置。
(10:58:37 PM) Stephen H. Wang: 所以，需要空一列不设置宽度。这样才能够在窗口缩放的时候自动适应大小。并且，可以适应多种分辨率，从1024*768 ~ 1280*1024都可以
(10:58:55 PM) Michael: 。。。你想说啥
(10:59:16 PM) Stephen H. Wang: 那么，空出的那一列，基本上都是显示内容最多的那列，okay,我们通常会对齐进行截断字符串，并且以tooltip的形式显示出来。
(10:59:24 PM) Stephen H. Wang: 那么截多长呢？
(10:59:29 PM) Stephen H. Wang: 这个也要问客户吗？
(11:00:15 PM) Stephen H. Wang: 我想，客户不会像我这么细，连这个问题都一一说明的。
(11:00:49 PM) Stephen H. Wang: 所以，我们的做法是，主动提案。这个地方左对齐，那个地方右对齐….并且有一套我们自己的标准（这是CMMI的常见词），然后经客户认可就行。
(11:01:41 PM) Michael: 核心思想是一样的，就是多与客户交流
(11:02:07 PM) Stephen H. Wang: 可是，CMMI的缺点也在于此。
(11:02:27 PM) Stephen H. Wang: 就是做事的是人，虽然有标准，但是遵守的程度却无从判定。
(11:02:40 PM) Stephen H. Wang: 于是，就出现了千奇百怪的现象。
(11:02:44 PM) Michael: 哈哈
(11:02:46 PM) Michael: 没错
(11:02:54 PM) Michael: 这边的客户提了一个观点
(11:03:27 PM) Michael: CMM的规矩多，但大多数都是用来破坏的；Agile的纪律少，但是要求绝对遵循的
(11:03:41 PM) Stephen H. Wang: 比如：那个截断字符串，有人认为应该写一个java函数，然后，讲显示的内容截成20个字符固定长度，结果中英文不一样长……
(11:04:11 PM) Stephen H. Wang: 而CMM中不会规定，截断字符串应该怎么截断。编码规范当中也没有写，于是就有了余地。
(11:04:26 PM) Michael: 呵呵
(11:04:48 PM) Stephen H. Wang: 然而这样的程序交到客户那里，客户说不合格。
(11:05:43 PM) Stephen H. Wang: 而Agile用的都是高手吧？
(11:05:58 PM) Stephen H. Wang: 所以，不会出现这样的问题也会出现错误的情况吧？
(11:08:13 PM) Stephen H. Wang: 我最近在写一套新的系统，准备采用Agile的方式，（可惜，还是我一个人，扮演n个角色）。
(11:09:23 PM) Michael: Agile对人的要求确实很高
(11:09:36 PM) Michael: 不仅仅是技术层面
(11:09:46 PM) Michael: 态度和人品也有相对较高的要求
(11:10:36 PM) Stephen H. Wang: 我觉得知识范畴需要的太广了。
(11:11:20 PM) Stephen H. Wang: 光页面布局就非常多的知识。
(11:11:35 PM) Stephen H. Wang: 你看过那本书没 《Don’t meke me think》
(11:11:51 PM) Michael: 看过
(11:12:01 PM) Michael: 这类的书多了
(11:12:06 PM) Michael: About Face 2.0也不错
(11:12:29 PM) Stephen H. Wang: 可是我所看过的软件，大多数都是左右结构，上下结构，或者上左右结构，左上下结构….
……
文化的风化与侵蚀
Posted on September 20, 2009
Filed Under essay, general | 3 Comments
常常听说，一个团队的文化就是团队负责人的文化; 一个公司的文化就是公司领导人的文化。究其原因，就是因为领导人的喜好和评判标准极大的影响着团队成员的荣誉感与价值观。这些观念和标准是在长期的工作和合作工程中不断碰撞不断沉淀下来最终得到的一个利益博弈的结果，表现出来的形式就是形式各异的企业文化，或者公司文化。
企业文化具备强大的同化能力。它是超越规章制度之外的一个做事方式、价值观的基本指导。许多公司的新员工培训采取的各种各样的方式，无不是想尽快让新员工适应这个公司这个大团体，与其他成员一起，向同一个方向使力。在《额尔古纳河右岸》中，年迈老人采用眩晕、饥饿、清洗肠胃等方法来训练原本桀骜不驯的老鹰称为帮手的过程，与这种文化上的趋同手段并无本质不同。
当在一个环境中已经具备一些文化认同的人，到了另外一个环境，有哪些行为会使得原本坚信的东西觉得恍惚？哪些事情会导致原本坚定的信仰开始动摇？哪些则会干脆彻底的重建原有的行事方式？
首先是寂寞。在东西方的神话中这类的例子屡试不爽。比如西游记里面各式各样的妖怪，大多是寂寞的发疯，逐渐忘记了规矩，成精之后下凡找点乐子。甚至是魔兽世界中众神的代表，泰坦萨格拉斯，在长达数万年的孤身与恶魔斗争中的，逐渐丧失了对正义的信仰，结果导向了恶魔的一方，称为整个世界的敌人。电影《无间道》中的卧底，长时间在正义与邪恶之间游走，最终也恍惚的分不清正义与邪恶。将一个人或者一个团队扔到孤立的地步是使其受到侵蚀的最简单的方式。有些人意志坚定，能撑较长的时间，有些人意志薄弱或者干脆正处于文化成型期，此时的寂寞很有可能直接导致文化上的风化、孤立与重塑。
随之而来的是诱惑。西方的哲学体系里面，人是有原罪的——例如贪婪、背叛。当有足够多的诱惑来临的时候，诱惑带来的好处、守护带来的艰辛，使得人的原罪发挥作用，原本坚信的东西开始逐渐动摇。
在实际的工作中，这些首先能看到的好处就是荣耀的来源。例如，在公司里面，人人崇尚敏捷，尊重事实，注重实效。做到这些能够得到同事、领导的赞赏。而当进行长期咨询工作的时候，发现客户对面面俱到的计划、华丽的图表等表面的东西更加赞赏。长期下去，工作的中心出现偏移，获得认可与赞赏的诱惑使得行事方式发生变化，长期下去，当这些行事方式成为思维习惯，带来的文化的变迁使得返回到原来的工作岗位时觉得陌生。
与荣耀相对的是惩罚。我们都是在正确与错误的事情中不断获得反馈和成长。一旦得到某些惩罚，很有可能对心灵造成很长时间的创伤，并且在长时间内处于敏感戒备状态，无论是新的环境还是旧的环境，都处于不信任状态。例如，派一个来公司不久的人，接受了公司文化培训，去处理客户现场问题，结果被客户大骂一顿。这位新员工可能在很长时间内萎靡不振，并且对公司和客户处于非常不信任的心理状态。
趋同心理则是最后一个效果最缓慢的因素，它的表现最快但是影响最慢。每当我们到一个新环境我们总想表现的跟当地的人一样，以获得最大程度的认同——起码从外表上——那些妖精都知道变成人形呢——如果客户西装领带，我们也不好短袖T恤；如果客户习惯在每个周五举办酒会，我们也乐于参与，等等。这些都是外观上的，但长时间的趋同很容易让人从外观上和内心上逐渐妥协并转换——就像中药，虽然见效慢，但终究是见效的，而且有可能是最能根治的。
< 请谨慎理解这篇文章——我没有在这片文章中给出任何防御性或者建设性的建议，甚至你都有可能无法看出我的立场。文化的变迁很大程度上是主观的，根据原因不同，我所经历过的文化沙漠的形成大多数组织领导在既得利益与文化建设之间的平衡不足造成。>
请理解交付
Posted on June 6, 2009
Filed Under essay | 8 Comments
不知不觉间，似乎我可以开始归类一类程序员：他们有着相当厉害的编程功底，熟悉数据结构、算法、设计模式，能够熟练应用这些模式；在项目开发中承担主要编码职责，并守护着代码质量和设计的纯粹。然而，由于种种原因，他们没能参与最终项目的交付，而被调到别的项目，等等等等。在他们的经验体系中，交付，是个很遥远的词。
世界并不完美。我不得不这么说。因此当完美并具革命性的重构、设计遭遇到无法修改的却不能不做的实际业务功能时，我遗憾的看到，这类天才的程序员并没有表现出应有的职业素养。他们消极的抵挡着这些需求，并期待着有某些更富于承担责任的人来承担这些看起来无聊无趣的任务。与在开发阶段相比，在交付阶段，他们的贡献显得如此暗淡。
请理解交付。完美的项目几乎不存在。在开发阶段出现的问题，部署阶段会放大无数倍：环境的不确定性，以及人们对新事物的怀疑，以及对失败、错误记得比较牢固的天性，使得一个新项目的成功交付显得希望飘渺。要认识到，这个阶段没有人能逃离。保持坚定不移的勇气，和以交付为目的的广阔视野来度过这一阶段，才是真正为了交付而做出的努力。
侬今葬花人笑痴，他年葬侬知是谁
Posted on April 18, 2009
Filed Under general | 3 Comments
不清楚要为什么取这个标题，事实上我要说的只是关于一个名叫魔兽世界的游戏，在九城运营近4年之后，丢掉了代理权，被网易夺走的商业故事。
新闻链接：九城与暴雪谈判破裂 网易拿下魔兽世界代理
1. 变，与不变
小的时候我总在看，好像好多东西都是长久不变的。每天要上的学，要见的老师，要走的路；每学期要放的假，每个季度要干的农活，每年要变冷的冬天，要发大水的夏天。从05年公测开始的时候就开始玩的魔兽世界，在我看来从开始就天经地义。不只是我，还有几百万拥趸的玩家。我们习惯了在游戏中交互，习惯了在半夜喊着OOXX强力队一边鄙视着一边M过去，习惯了跟朋友一起大呼小叫，习惯了25人乃至40人开荒灭到装备红，当然，也习惯了在服务器卡，红延迟，宕机的时候大骂着九城，的机器，的客服，的老板。这一切似乎不会变。
从合约的解除几个月后，这一切都变。未来是不是变得更好我不知道，NGA上大多数的玩家居然更倾向于不要换代理。因为担心几十万分钟的点卡，因为这是第一个游戏，因为这个游戏带来了太多的换了。
我在想，我们抱怨只是因为，我们习惯了抱怨吧，这么大的用户基数，出错的哪怕是万分之一，虽然宏观数量不大，但摊到自己头上都不好受。我自己就遇到过一天不能登录的情况，然而事后证明不是服务器的问题，是某省网络切割的问题。我不在网吧玩，不用简单密码，不跟别人共享帐号，号也没丢过，也没有麻烦过GM。平心而论，九城代理的魔兽给我带来的更多的是欢乐而不是痛苦。
2. 真的是香饽饽？
在4年的代理时间里，魔兽世界给九城带来了无比的财富：上市，大量的现金储备，几百人的研发团队，丰富的运营经验。“离开了魔兽世界的九城，是没有魔兽世界的九城”，这是一种姿态。不得不说商业是残酷的。魔兽世界占据九城90%以上的收入来源，这使得他谈判完全没有筹码。魔兽的成功又进一步刺激暴雪的胃口，下一轮谈判的筹码只会越来越高。魔兽真的会给网易带来更多的收入？我完全不这么想。魔兽世界对我而言早已没什么吸引力，游戏体制的僵化，游戏创意的枯竭，换不换代理商我都不会继续玩了。这款游戏已经进入了老年期。就像一根甘蔗，九城已经咀嚼了精华的部分的60%，剩下的头和根的一点点：要么有水分却没甜头，要么有甜头却很难啃。
3. 闲聊扯淡
这世界已经扁平。看看NGA或者游侠网，你会感叹玩家的探索能力和创造能力：汉化的，做音乐的，绘图的，写同人小说的。玩家的品味在这个国际化的舞台下已经提升。与此同时，只有约莫10年历史的中国游戏产业却再挣扎。GameRes上每一年的总结评估都让人沮丧。“人傻钱多”的玩家逐渐成为曾经有追求的游戏策划者要娱乐的对象，并一再挑战着玩家的智商。我玩过一些现在流行的免费游戏。我老婆看见的时候说，跟魔兽相比，他们就像玩具。玩家的品味是国际水平的；国内开发商的开发能力却差了好大的档次。因此我钦佩能够真正自主研发并且做出来的，比如剑网三。这是一个最好的时代，这是一个最糟糕的时代。很多人把游戏当作商业，特别是资本人。但在更多人眼里，游戏是艺术。真正的艺术品的产生需要你拥有崇高的信仰，以及不被俗世侵蚀的决心。
RichClient最佳实践在InfoQ发表
Posted on March 21, 2009
Filed Under general | 5 Comments
基本上就是过去两年做RichClient的总结，谈到了异步、事件管理、视图、缓存等。内容相对来说有点小高端，面向读者是至少有几年分层Web开发经验的开发者；或者正在做RichClient/RIA开发的开发者。
RichClient/RIA原则与实践（上），谈到异步和视图；
RichClient/RIA原则与实践（下），谈到事件、线程、缓存。
PS. 春节前就写完的东西，到现在才墨墨迹迹的发完，这样算来，一年也写不了几篇像样的东西。
专注，在写作室
Posted on March 7, 2009
Filed Under general | 9 Comments
从功能上说，这只是一个简单的文本编辑工具。他甚至不支持任何高级的编辑功能，例如加粗。
他甚至没有菜单、工具条、状态栏。
我为什么要做这个“在写作室”呢？
因为，每当我打开一个庞大的文本编辑工具的时候，除非我特别专心，否则很容易被分心：那些颜色，那些不同的工具条，菜单。
当又一次我的写作因为这个原因中断的时候，我决定做这个“在写作室”。它只需要完成两个功能：
- 自动保存。不仅仅是文字。还包括光标位置、滚动条位置。下次我继续写的时候，他能完全恢复上一次的状态。
- 保护注意力。
现在，如果你 在写作室 ，你会发现，你只看见纯黑的背景，和白色的光标。没有任何多余的信息。开始写吧。放心，它会自动记录你写的每一个字。只需要无聊的时候晃动鼠标，你会发现这个应用的所有功能。简单到不需要帮助文件。
为什么这个名字？因为我在新加坡的公寓里，44楼有FreeWiFi的阅读室，很安静。我通常在那里写代码写到很晚。
点到这里开始使用吧>>
分享你的写作体验，豆瓣线上活动：在黑暗中写作>>
另外说一下，IE可能会有意向不到的错误。Firefox/Safari完全测试。如果你在使用Mac, 那么最好不过了。
常见问题解答
Q: 这个。。。到底是个啥东西？除了写东西还能干啥？
A: 简单的回答：除了写东西，啥也不能干。甚至，它只是一个纯文本的编写工具，不支持任何格式化、图片等。它的不同之处在于，打开就能用，极其简单的界面（默认情况下没有任何菜单、按钮）和强烈的视觉反差（黑底，大白字），让你在在想写东西的时候能够真正专注在写，而不是其他。在现在这个信息淹没人的时代，注意力是最珍贵的资源。在写作室，尝试着通过更极致的方式来保护你的注意力。
Q: 好黑啊。。好空旷啊。。好孤单啊。。。
A: 嗯，是的。它不是twitter/google doc/开心网/facebook，热闹到你干点啥别人都能看见。从某种意义上说，它是一个相当私有的空间，专注于给出更高质量的产出。为了避免过于强烈的反差，它并不是纯黑和纯白。有些人觉得很刺眼…有些人觉得很爽。也许在以后会添加更多的配色。但…空旷将会是常态。忍受寂寞是成就高质量必经之路。
Q: 为啥子要用google帐号登录呢？不会记录我的密码吧？
A：inwritingroom托管在Google Appengine平台上，所有的程序和数据都在Google的服务器群中。每个人都有google帐号，登录的过程只是告诉google，你要使用这个应用程序即可。inwritingroom不可能持有任何跟密码相关的隐私信息。当然，为了保存每个人的文章，需要将文章与google帐号关联起来。
Q: 我的文件会丢吗？需要保存吗？
A: 一般情况下，你只需要专注的写就行。inwritingroom会随时保存下来你的修改。取决于网络情况，保存可能会延迟几秒。它保存的不仅仅是你写的文章，还包含你当前编辑的位置信息，这样当你下一次进来写的时候，它会自动跳转到你上一次的编辑位置。
Q: 多文件支持吗？
A: 如果你写累了，将鼠标移动到页面的顶端，你会发现一个工具条：保存，文件列表，全屏三个按钮。点击文件列表，你会看到写新文章的按钮。
Q: 全屏。。。好像有bug
A: 嗯，是的。有时候全屏模式和普通模式之间切换的时候内容不能同步。请少用这个功能，我正在考虑采用其他技术实现真正的全屏。
Q: 嗯，再问一次，你为啥要做这个，未来计划？
A: 出差的时候，忙起来很累，闲起来很无聊。想写点什么的时候太容易分心。花了大概4个晚上的时间写了这个（Python忘的差不多了，不然能更快些）。这些文字就是在写作室写的。除了自己用之外，我也很想看到有类似经历的用户。未来打算的功能，主要是两方面吧，配色的多样化，页面功能继续精简。现在功能还是太多了。
单纯的威力
Posted on December 8, 2008
Filed Under essay | 1 Comment
有时候哲学、理论、学派、认知真是一个很古怪的东西：他可以在任何时候，以任何形式来激励你，或者摧毁你。《蝙蝠侠：黑暗骑士》中那个小丑，成功的腐蚀了高贵正直的检察官。小丑近乎无懈可击的理论，瞬间摧毁了刚刚失去爱人的检察官，也近乎摧毁了我这个观众的情绪。
昨天去看了《梅兰芳》──现在评论已经是铺天盖地了。我最有感悟的是，邱如白气呼呼的跟孟小东说：“从一开始，梅兰芳心里都是孤独的，这份孤独一直陪伴他走到了今天，直到遇见了你。谁毁了梅兰芳的孤独，谁就毁了梅兰芳”；另在片尾，
头发花白的邱如白，烧着一封封的信件，说：我逼走你（梅兰芳）最爱的女人，不让你穿的花哨，不让参加各种活动，是因为只有活得真实，才能演得真实。
好单纯。
中午的时候跟公司的销售出去吃饭，闲间聊天，他问我，Craig Larman给国内某公司做咨询，报价多少。我猜了数次之后才猜到。相对同样做IT咨询，显然比我们高太多。我又问把老马弄出去能报价多少？销售不屑一顾：他现场经验差远了。作为一个软件从业者，听到这样的评论心理确实不爽。将Craig与Martin的书做下比较，就会看到两人专注的方向差异之大了。
显然人们对其他人的评价都是从自己的经验范畴里面进行的。正如梅兰芳，正如Martin. 如果他们不像我们知道的这样成功，或者就如大多数人一样伤仲永，一次次爬起时被现实打翻在地然后索性倒地不起，也就无所谓大师，无所谓伟大。
晚上的《鲁豫有约》，谈到了罗大佑。与其同台的居然还有陈楚生。说实话我很诧异陈楚生能够出现在这样的场合：因为像陈楚生这样很自我几乎没有了──被鲜花、粉丝、掌声包围的陈楚生，在一首《有没有人告诉你》之后，再无新的创意了。活得不真实，感情自然也不会充实。自我型的歌手，当不再有自我，还哪会有歌呢。这个太快的时代，快得以山寨为荣耀的时代，不知道有多少人能够坚持下来。有听说江苏台《绝对唱响》（仿超级女生的选秀节目）的冠军第一名是长得很像小胖的女孩，还是被评委否决、被观众投票拉上去的。我听了她的演唱，也就那样了──作为19岁的女孩，算是不错的，但至少在我这个外行人听来离出众还有不少距离。因此这个结果，要么是听众欣赏水平不高，从造星的角度来说，更注重外型与实力的落差；要么就是，我侥幸的想，人们真的感受到了那份执着追求音乐的单纯。
《追风筝的人》讲述的几乎是现代的战争故事。小说中反复提到的白沙岗，前天刚刚被炸过，死了几十个人。小说中的主角，在自己最亲密的仆人，朋友，兄弟，在遭受最耻辱的对待的时候，反复犹豫，恐惧，冲动，退缩，最后屈辱的跑回去，用更极端的方式来维护自己的那小小的恐惧。而这给他带来的，是数十年良心的煎熬，以及来自上帝的惩罚──无法生育。最终他决定赎罪的时候，为时已晚。他的兄弟却毫不犹豫：“为你，千百遍。”
似是而非、模棱两可的中国式说法太多了：三十年河东，三十年河西；此一时彼一时；与理不容、情有可原；兼收并用……真正操作起来，做起来，却变成了“存在即合理”，一定也可以找到对应的解释。“我们不能取悦所有人”，那么不喜欢我们的人就是我们不屑去取悦的人。
是为记，随便写写。
keep looking »