工作中的“熵”

熵,是信息论中对消息中包含信息的平均值,简单的说就是:一件事的不确定性的大小。

增熵,代表信息量增大,即一件事的不确定性变大;相应地,减熵,代表信息量减小,事情的不确定性变小。

在团队中,我们经历的很多事情不外乎三件事:

1. 增熵

2. 减熵

3. 不增熵也不减熵

增熵,通常是提出一个新的方向或者思路,常见于所谓领导者给出一个问题。比较有代表性的就是愿景(vision),是需要去执行的。

而执行的过程,就是减熵,将方向细化为方案/项目/任务/时间截点几个维度。

第三种,熵没有变化,常见如开会中,某人说了一个大家都知道的观点,或者仅仅是转述。“大家都知道” 这个几个字很重要,如果受众中有某些人还不知道,那么从应该知道的受众维度来说,也是“减熵”的。

从信息论角度来思考,我们可以试着解释一些事例。

  1. 某些人热衷开会,说一些无关痛痒,或者干脆一言不发,只会夸夸其他,说些常识。或者将一些常识换个名词反复提出。那么这种人就是对团队无益的。
  2. 通常情况下,上级提出问题,下级解决。如果你发现,你给下级提出一个问题后,他会提出另一个问题来问你。那么就是下级在领导你。
  3. 我们日常工作中,一般情况下来说,除了最顶级的老板和从事最基础工作的人,大多数的人都是既做增熵的事,又做减熵的事。比例的不同,决定了你是否适合这个团队。
  4. 如果团队里大多数人的大多数时间都在减熵(比如外包公司),而你期望做增熵的事,那么就不适合在这个团队。如果团队里大多数人都在做增熵(比如广告公司,设计公司),而你在做减熵的事情,那么你在这个团队里就不是那么重要的。
  5. 最怕的就是增熵和减熵能力都弱的人,也就是既无法落地,又缺乏思路的人。

团队持续集成手记

早就想试试持续集成.终于有机会了.
刚开始用cruise-control但是免费版有使用限制,而且界面似乎也不是很友好.没用的信息比较多.所以在忍受了1周以后废弃,改用hudson.
hudson比想象中的简单.安装和配置过程不说了.没什么难的东西,多尝试几次即可.
我们的项目用到的是ivy和ant,据说如果项目使用了maven的话就更简单了.”因为hudson和maven的搭配几乎可以用天衣无缝来形容”.
在使用了hudson将我们的所有模块导入后,整个构建越来越稳定了.而且build fail总是可以在第一时间捕捉并消灭掉.团队初尝ci的好处.
之后我们在构建过程中加入了自动化单元测试和覆盖率工具,当我们发现项目中broken的测试时,团队成员居然自发的去修复他们.在引入单元测试和覆盖率工具3天后,所有单元测试都pass,测试通过率100%.但团队对覆盖率这个东东还不是很了解.似乎也没有多少动力去提高他.此时,覆盖率只有40%左右.
之后我们又引入了findbugs和PMD,发现代码中存在的大量坏味道.此时ci-game插件起了作用.因为每改一个相应的”bug”都会有相应的分数.整个团队掀起了”打怪”狂潮.甚至加班打怪的情况.1周后,我们消灭了90%的不良代码.期间虽然会出现一些改错的地方.但基本上通过持续的代码review(因为所有团队成员都在不停的review代码),即便少有的几次改错的地方也是在第一时间发现并纠正了.
此时,似乎没有什么”怪”可以打了,但ci-game的竞争仍然激烈.此时团队发起了覆盖率提升行动,通过将不同的模块划拨给不同的小组,然后设置一个预期的目标(比如让aaa模块的测试行覆盖率从50%提升到70%.并且每提升1%都可以有5分.ci-game再一次大显神威.覆盖率行动成功并按照计划达到目标.
其实所有这些自动化的事情都可以在每ci工具的情况做到,也可以有类似ci-game这样的机制来提高团队对提高代码质量的积极性.但hudson提供的对代码的”透明”,让所有人都可以随时看到代码有哪些问题,改进的如何,更重要的是意识到自己写的代码是会被别人看到的!
hudson,很和谐!

早就想试试持续集成.终于有机会了.

刚开始用cruise-control但是免费版有使用限制,而且界面似乎也不是很友好.没用的信息比较多.所以在忍受了1周以后废弃,改用hudson.

hudson比想象中的简单.安装和配置过程不说了.没什么难的东西,多尝试几次即可.

我们的项目用到的是ivy和ant,据说如果项目使用了maven的话就更简单了.”因为hudson和maven的搭配几乎可以用天衣无缝来形容”.

在使用了hudson将我们的所有模块导入后,整个构建越来越稳定了.而且build fail总是可以在第一时间捕捉并消灭掉.团队初尝ci的好处.

之后我们在构建过程中加入了自动化单元测试和覆盖率工具,当我们发现项目中broken的测试时,团队成员居然自发的去修复他们.在引入单元测试和覆盖率工具3天后,所有单元测试都pass,测试通过率100%.但团队对覆盖率这个东东还不是很了解.似乎也没有多少动力去提高他.此时,覆盖率只有40%左右.

之后我们又引入了findbugs和PMD,发现代码中存在的大量坏味道.此时ci-game插件起了作用.因为每改一个相应的”bug”都会有相应的分数.整个团队掀起了”打怪”狂潮.甚至加班打怪的情况.1周后,我们消灭了90%的不良代码.期间虽然会出现一些改错的地方.但基本上通过持续的代码review(因为所有团队成员都在不停的review代码),即便少有的几次改错的地方也是在第一时间发现并纠正了.

此时,似乎没有什么”怪”可以打了,但ci-game的竞争仍然激烈.此时团队发起了覆盖率提升行动,通过将不同的模块划拨给不同的小组,然后设置一个预期的目标(比如让aaa模块的测试行覆盖率从50%提升到70%.并且每提升1%都可以有5分.ci-game再一次大显神威.覆盖率行动成功并按照计划达到目标.

其实所有这些自动化的事情都可以在每ci工具的情况做到,也可以有类似ci-game这样的机制来提高团队对提高代码质量的积极性.但hudson提供的对代码的”透明”,让所有人都可以随时看到代码有哪些问题,改进的如何,更重要的是意识到自己写的代码是会被别人看到的!

当基础模块部分基本稳定后,我们将应用模块也做到自动化构建和发布到开发集成环境.每小时进行一次发布.确保了我们集成开发环境始终都有最新的版本. 后续我们准备将自动化smoke test也做一些,也许不需要很彻底,只需要基本的接口可用即可.

hudson,不,持续集成,很和谐!