到杭州已是中午，错过了上午大会。下午Robbin进行Java技术展望和RoR实现REST的演讲，既然是朋友，肯定是要捧场的。Robbin旁征博引，以其深厚的技术功底和对新技术的敏锐洞察赢得了听众。

晚上一堆人去聚会，各路豪杰纷至：有阿里巴巴的，有自己创业的，有技术大牛，还有媒体（Infoq），出版社（博文的周总领3员大将赴会）。大家互换名片，认识的不免寒暄几句，不认识的也很快就熟捻了，还不时有“原来你就是×××”的惊呼，原来网上就“互通心曲”，只是一直没机会认识罢了。

席间觥筹交错，具体内容暂且不表，只说一件令我感受颇深之事。一个阿里巴巴的员工表现出对公司的无比忠诚，讲起公司的奖惩制度，说是一个员工的绩效不仅跟所在项目相关，还与部门、其它部门甚至整个公司的业绩相关。所以只要是对公司有利的事情，即使与自己现在的工作无关，他们也会去做。按常理来说，这有点不公平，我只能努力做好自己的事情，而如果别人不努力，我就是白做。但如果大家都努力，又变成了共赢。

这里让我讲一个简单的博弈问题，就是“囚徒困境”。A和B两个同犯被抓，因为没有其它任何证据和证人，只能让2人分别交供。如果A和B都矢口否认，那么两人无罪释放。如果A承认，B不承认；A是坦白从宽，判1年；B抗拒从严，判5年，反之亦然。如果2人都承认，ok证据确凿，各判2年。如果2人都是理性人，且没有互通消息，按照博弈，每个人的最优解就是承认，也就是各判2年。其实对2人真正有利的就是打死不承认然后都无罪释放，而这种状态在理性人的假设下是很难实现的--除非有一个教父，一直灌输他们不要出卖同伙。

马云就是这个“教父”！

卡内基有篇文章，我总结成一句话就是：用崇高的理想打动别人。据说马云一直是以个人魅力及“创造中国电子商务的明天”类似的理想，激励员工的。有了统一的企业文化，员工都不计较个人得失，努力奋进，最终企业和所有员工取得共赢，这绝对是摆脱“囚徒困境”的典型案例。

话说回来，阿里巴巴能让你感受到团队的力量，一群精英在一块做很有价值的事情，对每个人也是很好的锻炼。个人认为，如果有吃苦耐劳的打算，眼光放长远点，又没有其它方面的束缚，阿里巴巴的确是不错的选择。（得向阿里巴巴收代言费，呵呵！）

第二天听了多场论道，主要是SAAS，搜索，分词方面。结合阿里巴巴的战略，我把几点融合起来讲一下。这个下篇再细细道来。

众所周知软件这行压力是很大的。各种各样的问题层出不穷，每天上班工作内容都是排的满满的，遇到突发问题就得加班。如果不及时进行疏解，积累到一定的程度，就可能产生一定的负面问题，比如上班精神状态差、注意力不能集中、遇事喜欢逃避等等。我就亲身经历了这样的状况，明知自己工作积极性差、效率很低，但也很难一下子找回自我。

一次偶然的出游让我从中很快走了出来。一个亲戚考上厦大的博士，我请了 2 天的假，利用周末时间顺便去厦门旅游。厦门依山傍海，的确是旅游的好去处。晚上到海边，凉风习习，光脚沿着沙滩走过，任起落的潮水在腿上脚上留下层层薄沙。内心也变得平静，能够感受到海的呼吸。天地间仿佛只剩下我和大海，在进行心灵的交流，俗世烦扰皆抛诸脑后，只剩下对海的依恋。白天去爬南普陀山，并不太高，慢慢爬到山顶，整个思明区尽收眼底，远处一艘快艇在海面掠过，留下一条美丽的浪花。然后顺山而下到植物园，途径无数奇花异草、层天老树，走得累了，找个湖边石凳休息一下，人也觉得轻松愉快。

经过大自然的洗礼，回到单位，人的精神面貌焕然一新，抱着积极的心态处理事情，很多问题迎刃而解。压力测试做的很累，经常要熬夜，但通过一轮轮的测试，逐步定位到性能问题所在，自己也学了不少相关知识，想想也就没那么烦了。

做事的方式，也有了长进。我现在信奉人一时只做一件事效率最高的原则。事情再多，也是一件件做，每天安排好近日的工作，并排个优先级，什么是要亲自处理的，什么是让别人处理的，什么是需要预先通知他人的，需要什么资源，每件事情的预计时间如何，需要如何 check 等等。做好一件事就打个勾，做到心中有数。如果事情有延误，分析是什么原因，该如何补救，而不要有太大的心理负担，自己尽力了就好，是自己的责任就要勇敢扛下，死不了人的。这其实是很简单的原则，谁都能够学会，但的确很管用。

总结：压力是无处不在的，关键在于如何应对和排解。用积极的心态和恰当的方法面对，压力也就没那么大了。感觉压力积累到一定程度，在还未影响正常工作之前就先想办法排解，出去旅游、运动等都是缓解压力的好办法。

坏的代码就象揉面团，管什么接口什么实现全揉成一团，一个方法几百行，注释写再多也是面团（夹了些小纸条而已）。然后需要重用了，就是从中抓起一把面团，然后放到其它的面团里继续揉。这样重复代码一堆，什么易读性、扩展性、可维护性都是无从谈起。

好的代码就象堆积木，接口实现定义清清楚楚，每个接口只做一件事情，重复代码都是通过更细的接口来消除。重用就是把积木块往该放的地方堆，这样的代码，几个大块几个小块一目了然，只要方法命名规范，连注释都可以省去。这样耦合性低，易读性、扩展性、可维护性都可以得到保证。

把面团变成积木并不复杂，定义好模具，面团一团团往里面填充，待稳定下来，就成了一块块积木。这里关键就是模具的制作，推荐制作宝典： martin fowler 的那本重构。还得有模具的丈量工具，就非 junit 莫属了。

首先讲压力测试环境。这个很是关键，我们就是在这个上面吃了苦头。我们用的 loadrunner ，原理也很简单，一台主控机，控制多台客户机，模拟并发用户访问应用。然后需要能实时监控各相关应用服务器， ldap 服务器等的性能。这里每台客户机最好能使用同样的配置，使用足够带宽的网络，给予同样的负载（模拟同样数量的用户）。同时要注意监控客户机的 cpu 和网络状况，时刻保证 cpu 和网络利用率低于 100% 。我们犯的很大错误就是使用各自的笔记本，而且都使用的是一个 10M hub 牵出的网线，这样导致实际的网络阻塞，既没有给予服务器足够的负载，又导致报告的响应时间比实际更长，从而带来了后续很多的无用测试。

然后讲测试方法。用的较多的还是持续压力测试，就是持续给予服务器一段时间的并发量（一般为 5 到 10 分钟），然后看平均响应时间是否在可以接受的范围内。这个“可接受”要视应用类型和实际的并发用户而定，如何估计并发就要靠经验了。对于 portal 而言，由于要与众多的应用接口，如进行 SSO ，获取数据等，有很大程度也依赖于其它应用的性能，其性能要求不会太高。我们测试首页的性能，在放上全部的 portlet 的情况下， 100 个并发的平均响应时间就在 17s 左右，这肯定是不能接受的（ 10s 只能算勉强可以）。接下来就是发现性能瓶颈，并尝试进行优化了。

初步的发现瓶颈的方法也很简单，通过对 portlet 的增减，发现最影响性能的 portlet ，然后不断优化，直至达到可以接受范围。发现瓶颈所在了，就得进一步确定是什么原因：是我们本身程序的问题，还是其它应用接口性能不佳等等。这里光靠猜是不行的，要讲数据讲事实，记录时间日志就是简单有效的办法，我们对各个时间点打印了日志，比如 doview 方法的全部执行时间， jsp 的载入时间，具体接口的执行时间等。有些接口可能在压力较小的情况下性能不错，而在大压力情况下出现性能隐患，所以一定要在进行压力测试后查看日志。我们就是这样发现了性能隐患，同时更进一步对各方面进行优化，直至达到客户可以接受为止。

由于不是专门的测试人员，很多地方都是实际项目中的体会，也没什么理论基础。有什么不对的地方，大家多交流。

重用应该是高层的复用，逻辑的复用，接口的复用，而不是具体实现的复用。 我们项目开始讲复用，就是大家把别人的代码拿过来，可用的地方就用，不同的地方改改，结果问题一堆。说到底就是接口没有定义清楚的，很多该复用的逻辑隐藏在了具体的实现中。这样导致无法进行接口的复用，转而使用具体的实现复用。从程序员的角度看，他们总会使用成本最小的方法完成任务。所以我们要时刻思考如何能让最正确的方法在他们看来同时也是成本最小。

这里有一个较为简单的办法，就是尽量使用方法封装实现，使接口的粒度最小。如果一个实现需要几百行，且其中包含多个逻辑，就最好抽取出多个方法，然后在主体接口内进行调用。这样的代码逻辑清晰易读，可重用性也高。看看大师们对代码的不断重构，很大程度上就是重构出粒度最细，复用性最高的接口。

如何达到最大程度的复用，其实是非常复杂的问题，还需要在今后的项目中不断体会。

1.       开发流程尽量简化，采用迭代增量的模式，做适合项目需要的文档。很多时候千言不如一图，原型开发我认为也非常重要。

2.       采用成熟的框架， ssh 组合或更多 full-stack 的框架如 seam 等都是不错的选择。如果一定要用公司的框架，至少 SA 要非常熟悉这个框架，在出现问题时要能快速的解决。

3.       对业务的分析做到越细越好，如果有条件让更多的开发人员参与业务的分析，同时形成项目通用的业务语言（实在不行，精简的 user story 也可以）。对于每个达成共识的业务都要能记录下来，并能方便的进行查阅。业务模型和业务规则要始终与当前需求、代码和数据库保持一致。

4.       在团队的建设上，需要更多的投入。不要为了节约成本，让很多程序员老后面才加入团队。一个稳定、团结、有冲劲的团队能比松散而人数更多的团队，完成的更快更好。然后要加强沟通，比如每天开个小的茶话会，大家交流下各自的工作情况，有什么困惑和疑难，提出来大家一起解决，避免大家各自做相同的逻辑（很多东西经过抽象可能就是一个）。在工作之余大家一块吃吃饭，打打游戏等都是增进感情的好方法，大家彼此熟悉了，工作上也能更好的协作。

5.       对程序员要有更高的要求， SA 有责任让程序员了解更多的东西，如面向对象的 5 大原则、一些模式、 junit 、重构等，这些其实并不是什么高深的东西，仅仅是掌握一些方面也能对代码质量和开发中的愉悦度产生很大促进。要激发他们对技术的热爱和对代码质量的追求，因为最终受益的还是他们。 XP 所提倡的结对编程也是快速进行知识传递的好办法。

6.       采用 wiki 进行项目进度跟踪和一些文档的展示。这次用 excel+cvs 的方式感觉很是麻烦，在 spring 翻译中我们采用 wiki 的方式就感觉很好。

暂时先想到这么多，有更多体会，再来补充！

首先是开发流程。我是 xp 的坚定支持者，但在项目中由于外界原因还是采用了传统的开发流程，没有迭代，就是需求 -> 设计 -> 程序员进场开发 -> 改 bug 。由于程序员进场时间较晚，一上来就开始开发，没有时间进行培训和团队的融合。然后开发中缺少沟通，就是一个人负责一块，开发完了再做其它。结果开发到现在，还有人不清楚我们项目的全貌，到底是为了解决什么业务。

然后是开发框架。使用了公司的框架，而我们作为 SA （我们是双 SA ），都是第一次接触，程序员也就一个人用过。我们最早是达成共识采用 SSH 的组合（我至少还算是了解吧，其它人也都用过），但由于上层因素没有实施（这也导致我好长一段时间进入不了状态）。开发前期大家都在探索这个框架（的确很难用，出错机制较差，配置文件很多，耦合较强 ... ），在一堆莫名奇妙的问题中摸索前行，花费大量的精力。而比较搞笑的是，在大家开始学习这个框架之时，我作为 SA ，因为要写一堆只为应付客户的设计文档（后面就没人看过），错过了和大家共同进步的机会，后面总是感觉“低人一等”。

在业务方面也存在很多问题。很多业务逻辑并没有以很好的载体保存下来，在需求文档中很多逻辑并没有体现。我维护了一套 pd 的业务模型，从概念模型 -> 物理模型 -> 数据库，这解决了后面的一些沟通问题，但由于更多体现的是静态的实体及关联，对于一些动态的业务流程没法体现。我们 SA 之间有时在一些问题上的理解还存在分歧（讨论过也达成过共识，但没有记录下来，后面可能就忘了），程序员就更是无所适从。谈到这，我更感受到 DDD 这本书的价值，他所提倡的开发人员参加模型的讨论，形成项目的模型语言，并不断随着业务进行演化。。。好多理念都是项目经验的结晶啊。

在开发管理上我也是无所作为。 Junit 都没有推广下去，更别说 TDD 了，这也与框架相关，它就没提供写 test case 的地方，等我搞明白一堆配置文件，做出脱离 web 容器的 test 框架，都开发一大半了，说起 test 的好处，大家也表示不理解（或者表示理解但没时间 = 没理解），就让他们慢慢 debug 吧！代码的质量也没有保证，程序员不明白代码的味道，更别说理解重构的意义以及进行恰当的重构了。一个函数写上 100 多行，什么逻辑都混在一块，但由于时间较紧，我也只好睁一只眼闭一只眼“功能完成就行吧！也不是我一个人在管”，到现在很多代码混成一团，展现层直接调用 dao （又是框架惹得祸），相同的逻辑 copy 到 n 处，我也是后悔莫及。

今天先写失误，明天写从中学到的东西，从错误中学到的也许更多！

那么这个模型应该是什么样的？书我没有细看，只说说自己的体会。关于设计，很早就有数据驱动和对象驱动的提法。在 Without EJB 里， Rod 也有讲：数据驱动或者说面向数据库设计更成熟，工具更多；而对象驱动更符合面向对象程序的特性，但由于掌握的人较少，风险较大。而通过模型驱动，我认为很大程度填补了 2 种方式的鸿沟，核心是模型，具体是对象模型还是数据模型并不重要，重要的是这个模型能够与需求、代码、数据库保持一致。

说到这里，顺便谈一谈我对文档的理解。我一直是 XP 的坚定支持者，甚至有点偏执。而由于文档不易阅读和沟通，且经常会出现与设计和代码的脱节，导致其可读性更差，所以我一向对文档不大感冒，更倾向于使用代码说话。但在目前的公司项目中，由于更多采用传统的软件过程，我也写了很多的文档，包括需求规格说明书、概要设计文档、详细设计文档等等。从对项目的帮助来看，文档作用并不太大，或者说是付出收益比太低，更多的是给客户写的，而不是给程序员写的。从程序员的需要来看，他关心的是每个实体的属性和关联，核心的接口、输入和输出，页面间的跳转和数据流，然后有一个统一的框架和编程模式。我的体会是：如果以文档为核心，很难描述清楚这些东西，且难以应对变化。

而通过以模型为核心（项目现在采用的 power designer 的概念模型为基础），辅以适当的描述，既能够加快大家对项目的认识（程序员是后面才加入），又能够节省一些写文档的时间，更早投入开发。

说到 power designer ，我也比较惭愧。用了好久，一直只是把它当成看数据库的工具。项目一开始就是从物理模型入手，结果举步维艰。后面从概念模型入手，就感受到了它的好处。使用概念模型，不用考虑太多关联表、外键什么的，而是从实体出发，然后确定相互间的关联，是一对一、一对多还是多对多。然后自动转成物理模型，并直接与相应的数据库挂钩。从这点上看与从对象设计出发真的非常相似。其实这也是合情合理的，正体现了这个世界的统一性吧（物理学界不也在搞什么统一场理论的证明吗）。 Power designer 也做了 conceptual model, physical model, object-oriented model 和 xml model 的自动转换，我现在还没全部摸熟。

openfans 则是从对象入手，并通过 hibernate 建立与数据库的联系，也体现了一定的方便灵活性。但比较糟糕的是，只有代码和配置文件，没有清晰的便于交流的模型，谁要想参与只能先去慢慢看代码。所以我先通过 together reverse 出来一个类图，然后适当加以文字进行说明。类图已经做好，但比较乱，还需要更多的图例加以说明。文字说明就是下一篇 blog 的工作了。也算是预告吧！

首先是不适应。要参与需求阶段，因为需求初期并不确定，客户都不清楚他们需要什么东西，只是有一个很模糊的概念。我们得不断调研、讨论、出方案、出原型 …… 而这都是我比较不擅长的。还好有个职务较高的老大带着我们，才能逐渐把需求理顺。我也从他身上学到不少，准备写一篇“如何做需求”，但毕竟是第一次做较大的需求，理解还不很深刻，怕贻笑大方，所以只拿 MindManager 列了个提纲。

其次还是不适应。项目开始好几个月，没写过一行代码。项目没有采用 XP 的方式，而是普通的瀑布。需求就做了几个月，然后做概设、详设。我是 XP 的支持者，所以对这种方式持反对态度，但老大不同意，没办法！写文档，我也是很不情愿，但转念一想： Rod 写 Without EJB ，但他 ejb 的理解比谁都深，什么方式都实践下可能更好。由于同时在看 Joel on software ，他对需求规格说明书却很是强调，我也就听听大师的话，好好写需求，顺便把他的一招用上了 ------- 写的有趣点，就当写故事吧。

最后还是不适应。以前做程序员，可以好好研究很多东西，现在不行了。有个 xml 与 bean 转换的技术要解决，我能研究不？不行，我得写文档，这种比较 detail 的事情得给程序员做。看着程序员兴高采烈的比较各种开源工具，最后选定 JIBX （ openfans 发挥了一定的作用），然后跟我讲这个如何如何好，我只有附和的份。

讲到这里，让我想到一则小故事：有一个学钢琴的拜一个牛人为师。牛人交给他一个曲谱，说：“回去练好，一个月再过来。”他好歹把这个曲练熟了，还想展示一下，牛人又交给他一个更难的曲谱，又是同样的话。他只好回去继续苦练，每次都感觉不适应。这样往返多次，他忍不住了，问牛人：“你是不是故意整我，每次都给我更难的，还不给我表现的机会”。牛人让他把上次的曲弹弹，他感觉不错，让弹再上次的，更是轻松，最后弹第一次，他弹的是出神入化。他明白了！

大家都明白没：只有不断的感到不适应，才能进步。如果一切感觉良好，没什么挑战，就该考虑。。。。。。（此处省略 2 字）了。

一共 3 个 speaker ，第一个是 thoughtworks 的资深顾问，讲了些 xp 要注意的地方，并配了些照片和图表，讲如何实施 xp ，还是有些收获的。第二个是阿里巴巴的性能测试专家，讲了如何进行性能测试，如模拟用户，确定负载等等。人挺牛的，但想想阿里巴巴每天 1 个亿的 pv(page view) ，他都搞得定，咱也没话说。

第三个出场的就是这篇文章的重点了，讲的的确很好，而且很有新意。这位是红工厂的老板，在中国工作几年，然后去加拿大开始了他的 xper 之路，回国后做出了自己的 JDO 实现。他的主题就是结合自己的经历，讲授一个 xper 的成长过程。因为是亲身所感，他讲出来很是实在，加上时不时幽它一默，如：上班让打游戏感觉很爽，跟印度美媚 pair programmer 却感觉很累。。。。。。让人在会意的微笑中体味他当时的感受和成长，同时加深对 xp 的一些实践的实际认识。

他并没有讲 xp 所涉及的所有要素，只是强调了 pp 和沟通的重要性以及测试优先和重构是程序员的基本素质这几个方面。他很是关注沟通的精神甚至一个人的性格要素，他认为好的 programmer 应该乐于去沟通，勇于承认不足，并能主动去向同伴或团队寻求解答（而不是首先去 google ）。同时他对 xp 的精神提出了自己的看法，也是以人为本，但是另一种意义上的以人为本。他半开玩笑的说，以人为本并不是给你更多的工资，让你上班打游戏，让你 happy 的工作，而是把以前对流程的关注更多转到开发人员上面，让开发人员具备一个 xper 应有的素质。他通过亲身体验说明了一个好的 xper 即使不在 xp 的团队中，也能创造更快的开发效率，更高的代码质量和更少的加班。关于这点我也很是认同并有一些亲身的实践：通过测试先行，不断重构和努力消除重复代码，是能大大优化代码结构，提高代码质量，减少 bug 率的，而相应的反而会提高开发效率。

也许目前国内还较少有真正能实施 xp 的团队，我们也很难真的在项目中进行 xp 的完整实践。但只要我们接受 xp 的思想，在平时的实践中就采用一些 xp 推荐的方式，如测试优先、重构、持续集成、乐于沟通等等，先把自己变成一个合格的 xper ，那么在真的有机会实施 xp 的时候，我们就能更快的融入团队，更好的用 xp 的精髓指引项目走向成功。

出了大楼，师弟带我们到新建好的南门去看看。这不是凯旋门的模仿吗？厚重的大理石砌出中间一大两边一小的空透长门，再加上一些简单的雕饰，中间的下面却立了很大石碑，刻上学校的名字，再围上一些花，阻止人的通行，顿时减少了很多宏伟的气势。但这样却便于照相，好多同学三五成群往石碑前一站，然后很好取景：人面鲜花相映，加上“凯旋门”的气势和石碑的明喻，很有纪念意义。“凯旋门”两旁是弧形的长廊，仿欧洲古典主义建筑风格，一排排石柱过去，凭添了不少文化气息。

从“凯旋门”往校园里走，眼前一片开阔，是一大片草坪，有几个足球场大。草坪上有不少学生，或站成一圈玩飞盘，或几个人围坐打扑克，或几个人乱卧其上感受草的气息。我们走进看看，一块块醒目的小牌上都有一句颇有意味的话语“小草在休息，请勿打扰”。本意大家都明白，但看这么多人在上面，也就暂且从众一把。我们也打扰了一下小草，我还忍不住在上面打了个滚。同时在想：这么大的一块草坪，花费不菲，如果只是看看，未免可惜了点，好像国外的草坪也并不禁止人踩踏的，只要不在上面做剧烈运动，如踢足球之类，应该也不会带来很大的影响。

沿着路往东走，右边都是新建的教学区和学院大楼，风格很是统一。经过一座小桥，往下看去，河水缓缓流过，旁边一个小的岸边广场，河岸边有沿河走道，一直往远方延续。在草坪的绿色基调下又多出一些点缀，真是风景这边独好。我又在心底感叹：真是适合谈情说爱的好地方，可惜我们那时没有，只有西边一个小的人工湖，晚上拥挤的很。再往东就看到一个红漆的仿古大门，是把老校区的大门 copy 过来了。照样门前一对石狮，也是适合摄影留恋的地方。

大家到这也就慢慢散去了，大部分打的走了。我的爱车还在学院门口停着呢，于是又跟几个同学往里走。一边聊聊工作的事情，一边大家好像有默契的往以前的宿舍楼所在走去。走了好远，过了一个地道，来到以前的宿舍楼下。又翻新了，涂上浅黄色涂料，加上四角的红砖墙装饰。可惜原本就整体感觉不佳，就好像一个丑媳妇，涂上再多胭脂水粉也变不成美女一样。忍不住从下往上张量以前我住的宿舍，阳台挂了件运动衫，里面还是有位运动健将的。

又得睡觉了，还没写完，明天继续。

因为赶时间去聚会，所以也无心流连，骑车直奔饭店。老同学好久不见，免不了一些客套寒暄， 2 年时间毕竟太短，大家也没有太大的变化，没有谁一下飞黄腾达的。席间觥筹交错，自不必说。有 2 个研二的师弟，便吃完带我们四处走走，首先就去看我们毕业后才落成的软件大楼。

这时我的车发挥优势了，他们得做校内巴士，绕好大一圈的，我就沿着一条直线直接骑过去。根据师弟的描述，来到一座银灰色玻璃幕墙的大楼前，停好车，他们还没到，便在外面转悠转悠。五层楼高，挺现代的设计，对一些细部处理的也不错，有挑台，凹进，凸出，显得整个立面挺丰满。这里插一句：我本科是在这学建筑设计的，可惜没天赋，学了个半吊子，只好改行。

等了会，他们才姗姗来迟，大家一块进去看看。厅很大，展出了很多学生的成果，挺不错的，有自己开发的工作流，有拿 spring+hibernate+velocity 做的项目，有自己做的负载均衡服务器。。。。。。二点感受，一是学校教的还不错，是在培养学生的实际能力，跟社会接轨；二是开源软件深入人心，在校的学生也都在使用了。看了他们的实验室，全 dell 的液晶，空间按公司的 cube 方式布置，大家议论说比他们的办公环境还好，于是纷纷感叹，生不逢时，晚来几年就好了。

得睡觉了，先写这么多，明天接着写。

躺了会，的确有点刺背，就坐起身来。目光所及，前面草地上有只不知名的小鸟，白头黑身，长长的尾巴，正在草中寻虫吃吧，走几步小嘴一啄，尾巴也上下颤动，可爱的很。它漫无目的的走着，大体向我靠近了，我心中一阵高兴，幻想着它能来到身边，我伸出手掌让它停在上面。我屏住呼吸，尽量不弄出一点动作和声音，只是静静的看着它，欣赏它的美丽。可它又慢慢走远了，可能发现了我，头也不回的一摇一摆的往前走去。小鸟终究是怕人的。

于是我便站起身来。草坪旁边是一个人工湖，湖边是一座叠石流水，水绕着叠石，向下流淌到湖中，倒也别具匠心。叠石不高，顶上好像能上去的样子，我生性好动，就想往上爬。难度不大，但也得手脚并用，看准落脚点，手上抓牢，很快就站在最高点了。可以俯瞰湖面，波光粼粼，水上还有一些睡莲，不由浮想起：“鱼戏莲叶东，鱼戏莲叶西，鱼戏莲叶南，鱼戏莲叶北”的诗句来。但好像没有鱼的动静，也许这个湖也刚建不久，还未长成吧。湖岸对面一个老者，拿根小竹竿在忙活着，应该不是钓鱼吧，鱼都没长大呢！带着一丝好奇，我又爬下叠石，转到对岸去看看。

他旁边放了个盛水的小盒子，里面一些非常小的鱼在游着，我以为是鱼苗呢，就上去问：“你是要把这些鱼放进湖里吗？”他没抬头，旁边又来了几个民工样的人，也凑上身来，其中一个问：“鱼这么小，有什么用？”老者这下答话了：“我去喂小乌龟。”“小乌龟不吃小鱼吧”……原来他是用小网兜把可怜的小鱼捞上来，然后装回家喂小乌龟。我很快走开了，好的心情一下荡然无存。这么小的鱼，好不容易才在这片池塘出生，却因为某人家里不知道吃不吃它的小乌龟，被装到盒子里，注定其灭亡的命运。而我只能幻想鱼群在莲叶下游过的景象。我忽然想起为什么我是走开，而不是将鱼放到湖里去。那样会得罪人，是啊，“少管闲事”的观念已经深入骨髓了。但我也只是想想，头也不回的往公司走去。