Bill的故事（1）

Tina总容易让我气急败坏，她已经不止一次的指出了在我的程序中所出现的错误，有的属于代码级的Bug，而有的则是设计上的问题。在她面前我总试图以经验丰富的大拿自居，因为我时常可以在她的幼稚的代码中发觉显见的错误，嗅到潜在的错误。可我又时常被她搞得灰头土脸，一个菜鸟也可以令大拿哑口无言，实在是很能说明问题的。最近燥热的天气很容易让人动火，还好她是女士，否则我怕我真的会出言不逊的。当然，我至今还没有犯过这样一时失控的错误，还保留着一点大拿们一般所要具备的“谦逊”的气质，证明自己还算半个大拿——一个技术不过硬但品行还凑合的大拿。

当冷静下来开始仔细考虑这些错误时，我发现很多问题都可以归结到一个更为本质的问题上来。在我做出设计决策和随后的代码实施的过程中，不少地方都存在草率的痕迹。没有反复推敲就下了决定，以致这个系统在很多地方缺乏自圆其说的能力，有些功能甚至是自相矛盾的。我奇怪自己为什么会犯这样的错误，也许是太轻视这个任务了（我对ASP项目一向都有一点不屑），也许自己还未完全理解需求。

不过说到需求，我到是可以有所推卸，因为我相信，Tina和我还有其他人都没有真正彻底的搞懂过这个任务里的所有需求。我们总是认为，至少应该等有一个可供评估的Prototype出现，一些问题才可以澄清，需求才会逐渐变得明晰起来。我想这一点应该是正确无疑的，这种作法尤其适合小型系统的快速开发。

但是，我的漫不经心和自以为是，还是让我为此付出了代价，虽然不影响大局，但至少让我失去了作为大拿的沾沾自喜。问题在于，当Prototype成形后，我对它所作的改动却是缺乏思量的。由于，没有足够的思想准备，在一个系统缺乏统一的若干约定、规则的前提下，我就开始凭借以往的经验，对之进行了随心所欲的改动，而这些改动却引入了新的约定和规则，不同于前次的约定和规则，这就是那些问题的始作俑者，另我大失掩面的根源所在，而这一切却被“聪明”的Tina给抓住了。

关于系统内规则和约定的不统一，我记得Frederick Brooks在他的《The Mythical Man-month》一书中涉及“外科手术队伍”时曾经有所提及，不过那里的混乱是由于存在对系统具有同等主导力量的多个专家而导致的。从效果来看，我似乎在扮演多人角色，多个不同风格的“专家”。

Prototype形成之前的草率设计＋Prototype形成之后的草率修改＝我的在Tina面前的灰头土脸

这就是我从这一事件中总结出来的公式。