109

我们有一个初级程序员,他根本没有编写足够的测试。
我必须每两个小时唠叨他一次,“你写过考试吗?”
我们尝试过:

  • 表明设计变得更简单
  • 展示它可以防止缺陷
  • 让它成为一种自我的事情,只说糟糕的程序员不会
  • 这个周末有 2 个团队成员必须来上班,因为他的代码有一个 NULL 引用,而他没有测试它

我的工作需要高质量的稳定代码,而且通常每个人都“明白”并且没有必要推动测试。我们知道我们可以让他编写测试,但我们都知道有用的测试是在你投入其中时编写的。

你知道更多的动机吗?

4

24 回答 24

128

这是最难做的事情之一。让你的人得到它

有时,帮助初级程序员“掌握”并从高级程序员那里学习正确技术的最佳方法之一就是进行一些结对编程。

试试这个:在即将到来的项目中,将初级人员与你自己或另一位高级程序员配对。他们应该一起工作,轮流“开车”(在他们的键盘上打字)和“指导”(看着司机的肩膀,边走边指出建议、错误等)。这似乎是一种资源浪费,但你会发现:

  1. 这些人一起可以快速生成更高质量的代码。
  2. 如果您的初级人员学到了足够的知识,可以在高级人员的指导下沿着正确的道路“得到它”(例如,“好的,现在在我们继续之前,让我们在测试中编写此功能。”)这将非常值得您提供资源致力于它。

也许你的团队中也有人提供了 Kate Rhodes 的单元测试 101演示文稿,我认为这是让人们对测试感到兴奋的好方法,如果交付得好的话。

您可以做的另一件事是让您的 Jr. Devs 练习保龄球游戏 Kata,这将帮助他们学习测试驱动开发。它在 java 中,但可以很容易地适应任何语言。

于 2008-08-10T18:17:34.983 回答
21

在每次提交之前进行代码审查(即使是 1 分钟“我已经更改了这个变量名”),并且作为代码审查的一部分,审查任何单元测试。

在测试到位之前,不要在提交上签字。

(另外——如果他的工作没有经过测试——为什么一开始就在生产环境中?如果没有经过测试,不要让它进来,那么你就不必在周末工作)

于 2008-08-10T22:59:14.383 回答
20

对于我自己,我已经开始坚持将我发现和修复的每一个错误都表达为一个测试:

  1. “嗯,这样不对……”
  2. 发现可能的问题
  3. 写个测试,显示代码失败
  4. 解决问题
  5. 显示新代码通过
  6. 如果原始问题仍然存在,则循环

即使在敲打东西的时候,我也会尝试这样做,而且我几乎在同一时间完成了,只是已经有了部分测试套件。

(我并不生活在商业编程环境中,并且通常是唯一一个从事特定项目的编码人员。)

于 2008-08-22T15:46:16.663 回答
16

想象一下,我是一个模拟程序员,名叫... Marco。想象一下,我不久前刚从学校毕业,从来没有真正需要写过测试。想象一下,我在一家没有真正执行或要求这样做的公司工作。好的?好的!现在想象一下,该公司正在转向使用测试,他们正试图让我参与其中。我会对到目前为止提到的项目做出一些刻薄的反应,就好像我没有对此进行任何研究一样。

让我们从创建者开始:

表明设计变得更简单。

怎样才能写得更多,让事情变得更简单。我现在必须密切关注获得更多案件等。如果你问我,这会让事情变得更加复杂。给我详细的信息。

展示它可以防止缺陷。

我知道。这就是为什么它们被称为测试。我的代码很好,我检查了它是否有问题,所以我看不出这些测试有什么帮助。

让它成为一种自负的事情,说只有糟糕的程序员才不会。

哦,所以你认为我是一个糟糕的程序员,只是因为我没有做太多常用的测试。我被侮辱了,对你很生气。我宁愿得到帮助和支持,而不是空谈。

@贾斯汀标准:在新项目开始时,将初级人员与您自己或其他高级程序员配对。

哦,这非常重要,以至于将花费资源确保我了解事情是如何完成的,并在事情如何完成方面帮助我。这很有帮助,我可能会开始做更多。

@Justin Standard:阅读Kate Rhodes 的单元测试 101演示文稿。

啊,那是一个有趣的演示,它让我想到了测试。它敲定了一些我应该考虑的观点,它可能会稍微改变我的观点。

我希望看到更多引人入胜的文章和其他工具来帮助我坚持认为这是做事的正确方式。

@Dominic Cooney:花点时间分享一下测试技巧。

啊,这有助于我了解对技术的期望,它在我的知识包里放了更多的东西,我可能会再次使用。

@Dominic Cooney:回答问题、例子和书籍。

有一个重要的人(人)来回答问题很有帮助,它可能会让我更有可能尝试。好的例子很棒,它给了我一些目标,以及一些可供参考的东西。与此直接相关的书籍是很好的参考。

@亚当海尔:惊喜评论。

说什么,你突然出现了我完全没有准备好的东西。我对此感到不舒服,但会尽力而为。我现在会对再次出现这种情况感到害怕和轻微的担心,谢谢。然而,恐吓策略可能奏效了,但它确实是有代价的。但是,如果没有其他方法,这可能只是需要的推动。

@ Rytmis:项目只有在有测试用例时才被认为已完成。

哦,有趣。我知道我现在真的必须这样做,否则我什么也做不了。这是有道理的。

@jmorris 摆脱/牺牲。

瞪眼,瞪眼,瞪眼——我有机会学习,在支持和帮助下,我可以成为团队中非常重要和功能性的一员。这是我现在的障碍之一,但不会持续太久。但是,如果我只是不明白,我明白我会去的。我想我会得到它。


最后,我团队的支持在这一切中起了很大的作用。让一个人花时间提供帮助,让我开始养成好习惯总是受欢迎的。然后,之后有一个良好的支持网络会很棒。以后有人来几次,检查一些代码,看看一切是如何进行的,而不是在审查本身,而是作为一次友好的访问,总是会很感激的。

推理、准备、教学、跟进、支持。

于 2008-08-11T02:07:46.593 回答
12

我注意到很多程序员在理性的层面上看到了测试的价值。如果您听说过诸如“是的,我知道我应该对此进行测试,但我确实需要快速完成此操作”之类的话,那么您就会明白我的意思了。然而,在情感层面上,他们觉得只有在编写真正的代码时才能完成某些事情。

因此,目标应该是以某种方式让他们了解测试实际上是衡量某事“完成”时间的唯一方法,从而赋予他们编写测试的内在动力。

不过,恐怕这比它应该做的要难得多。你会听到很多借口,比如“我真的很着急,我稍后会重写/重构它,然后添加测试”——当然,后续行动永远不会发生,因为令人惊讶的是,他们'下周 一样 忙.

于 2008-08-10T18:00:35.830 回答
9

这是我要做的:

  • 第一次出去……“我们要一起做这个项目。我写测试,你写代码。注意我是怎么写测试的,因为这就是我们做事的方式就在这里,这就是我对你的期望。”

  • 之后……“你完成了?太好了!首先让我们看看推动你开发的测试。哦,没有测试?让我知道什么时候完成,我们将重新安排查看你的代码。如果你'如果需要帮助来制定测试,请告诉我,我会帮助你的。”

于 2008-08-10T19:53:27.427 回答
6

他已经在这样做了。真的。他只是没有写下来。不服气?观看他完成标准开发周期:

  • 写一段代码
  • 编译它
  • 跑看看它做了什么
  • 写下一段代码

第三步是测试。他已经进行了测试,他只是手动进行。问他这个问题:“你怎么知道明天的代码仍然有效?” 他会回答:“就是这么少的代码!”

问:“下周怎么样?”

当他没有得到答案时,问:“你希望你的程序如何告诉你,当一个改变破坏了昨天工作的东西?”

这就是自动单元测试的全部意义所在。

于 2009-02-24T14:25:49.117 回答
5

作为一名初级程序员,我仍在努力养成编写测试的习惯。显然,养成新习惯并不容易,但考虑到什么能让这对我有用,我必须 +1 关于代码审查和指导/结对编程的评论。

可能还值得强调测试的长期目的:确保昨天有效的东西今天、下周和下个月仍然有效。我之所以这么说,是因为在浏览答案时,我没有看到提到的内容。

在进行代码审查时(如果您决定这样做),请确保您的年轻开发人员知道这不是要让他失望,而是要让代码变得更好。因为这样他的信心就不太可能受到损害。这很重要。另一方面,知道自己知之甚少也是如此。

当然,我真的什么都不知道。但我希望这些话是有用的。

编辑:[贾斯汀标准]

不要让自己失望,你要说的几乎是正确的。

关于代码审查的观点:您会发现不仅初级开发人员会在此过程中学习,审查者也会学习。如果你把它变成一个协作过程,代码审查中的每个人都会知道。

于 2008-08-14T00:28:04.143 回答
4

坦率地说,如果你不得不付出那么多努力让他做某事,那么你可能不得不接受这样的想法,即他可能不适合球队,可能需要离开。现在,这并不一定意味着解雇他……这可能意味着在公司中找到更适合他的技能的其他地方。但如果没有其他地方......你知道该怎么做。

我假设他也是一个相当新的员工(< 1 年)并且可能最近离开学校......在这种情况下,他可能不习惯在公司环境中如何运作。像我们大多数人在大学里可以逃脱的事情。

如果是这种情况,我发现的一件事是进行一种“惊喜新员工审查”。如果你以前从来没有做过也没关系……他不会知道的。让他坐下,告诉他你要检查他的表现并向他展示一些真实的数字……拿你的正常审查表(你确实有一个正式的审查过程,对吗?),如果你愿意,可以改变标题,这样看起来官员并向他展示他的立场。如果你在一个非常正式的环境中向他展示不做测试会对他的表现评级产生不利影响,而不是仅仅“唠叨”他,他希望能明白这一点。你必须向他表明他的行为实际上会影响他,无论是明智的还是其他的。

我知道,你可能不想这样做,因为这不是官方的……但我认为你有理由这样做,而且这可能比解雇他并招募新人要便宜得多。

于 2008-08-10T17:58:14.057 回答
4

作为一名初级程序员,我认为 Id 揭示了当我发现自己处于与你的初级程序员类似情况时的感受。

当我刚从大学出来时,我发现它严重地让我无法应对现实世界。是的,我知道一些 JAVA 基础知识和一些哲学(不要问),但仅此而已。当我第一次得到我的工作时,至少可以说有点令人生畏。让我告诉你,我可能是周围最大的牛仔之一,我会拼凑一些没有评论/测试/文档的小错误修复/算法,然后将其发送出去。

我很幸运能够在一位善良且非常有耐心的高级程序员的监督下。对我来说幸运的是,他决定和我坐下来,花 1 到 2 周的时间来检查我被破解的代码。他会解释我哪里出错了,c 和指针的细节(男孩这样做让我感到困惑!)。我们设法在大约一周内编写了一个相当不错的类/模块。我只能说,如果高级开发人员没有花时间帮助我走上正确的道路,我可能不会坚持很长时间。

令人高兴的是,两年后,我希望我的一些同事甚至会认为我是一个普通的程序员。

带回家积分

  1. 大多数大学都非常不擅长让学生为现实世界做好准备
  2. 配对编程真的帮助了我。这并不是说它会帮助每个人,但它对我有用。
于 2008-08-18T19:42:34.357 回答
3

如果这是您关心的问题,请将它们分配给不需要“高质量稳定代码”的项目并让 jr. 开发商失败。让他们成为“周末进来”修复错误的人。多吃午饭,谈论软件开发实践(不是讲座,而是讨论)。随着时间的推移,他们将获得并发展最佳实践来完成分配给他们的任务。

谁知道呢,他们甚至可能想出比你的团队目前使用的技术更好的东西。

于 2008-09-18T01:05:51.377 回答
2

如果初级程序员或任何人没有看到测试的价值,那么就很难让他们去做......时期。

我会让初级程序员牺牲他们的周末来修复错误。他的行为(或缺乏行为)不会直接影响他。此外,请明确指出,如果他不提高自己的测试技能,他将不会看到晋升和/或加薪。

最后,即使有你所有的帮助、鼓励和指导,他也可能不适合你的团队,所以让他去找一个能做到的人吧。

于 2008-08-10T17:49:22.873 回答
2

我赞同 RodeoClown 关于代码审查每个提交的评论。一旦他完成了几次,他就会养成测试东西的习惯。

我不知道你是否需要阻止这样的提交。在我的工作场所,每个人都可以免费提交所有内容,所有 SVN 提交消息(带有差异)都会通过电子邮件发送给团队。

注意:如果您打算这样做,您真的需要Thunderbird colour-diffs 插件。

我的老板或我自己(两个“高级”编码人员)最终会阅读提交,如果有任何诸如“你忘记添加单元测试”之类的东西,我们只需轻扫一封电子邮件或去和那个人聊天,解释他们为什么需要的单元测试或其他什么。鼓励其他人也阅读提交,因为这是查看正在发生的事情的好方法,但初级开发人员不会发表太多评论。

您可以通过定期说诸如“嘿,鲍勃,你看到我今天早上所做的提交了吗?我发现了一个巧妙的技巧,你可以做任何事情,阅读提交并查看这个怎么运作!”

注意:我们有 2 名“高级”开发人员和 3 名初级开发人员。这可能无法扩展,或者您可能需要与更多开发人员一起调整流程。

于 2008-08-11T00:35:42.693 回答
2

教导他/她是他/她的导师的责任。你教他/她如何测试的效果如何。你和他结对编程吗?Junior 很可能不知道如何为 xyz 设置一个好的测试。

作为一名刚毕业的大三学生,他知道许多概念。一些技巧。一些经验。但归根结底,所有的青少年都是有潜力的。几乎他们开发的每一个功能,都会有他们以前从未做过的新东西。当然,Junior 可能已经为课堂上的一个项目做了一个简单的状态模式,打开和关闭“门”,但从来没有在现实世界中应用这些模式。

他/她只会和你教得一样好。如果他们能够“得到它”,您认为他们首先会担任初级职位吗?

以我的经验,初级人员被雇用并承担与高级人员几乎相同的责任,但只是报酬较低,然后当他们开始步履蹒跚时就被忽视了。如果我看起来很痛苦,请原谅我,因为我是。

于 2008-08-13T19:20:30.470 回答
2
  1. 使代码覆盖率成为评论的一部分。
  2. 将“编写暴露错误的测试”作为修复错误的先决条件。
  3. 在签入代码之前需要一定程度的覆盖率。
  4. 找一本关于测试驱动开发的好书,用它来展示测试优先如何加速开发。
于 2008-08-29T18:55:24.813 回答
2

许多心理学和有用的“指导”技巧,但老实说,这只是归结为“如果你明天还想有工作就写测试”。

你可以用任何你认为合适的术语来表达它,苛刻的或柔和的,没关系。但事实是,程序员并不仅仅是把代码放在一起并签入——他们得到报酬是仔细地把代码放在一起,然后把测试放在一起,然后测试他们的代码,然后把整个东西都签进去。(至少根据您的描述,听起来就是这样。)

因此,如果有人要拒绝做他们的工作,请向他们解释他们明天可以待在家里,然后你会雇用一个会做这项工作的人。

再一次,如果你认为有必要,你可以温和地做这一切,但很多人只需要在现实世界中狠狠地一记耳光,你会给他们一个帮助。

祝你好运。

于 2008-11-07T07:13:08.083 回答
2

暂时将他的工作描述更改为仅编写测试和维护测试。我听说许多公司在刚开始时会为没有经验的新人这样做一段时间。

此外,在他担任该角色时提出挑战:编写将 a) 在当前代码上失败 a) 满足软件要求的测试。希望这会让他创建一些可靠而彻底的测试(改进项目),并让他在重新集成到核心开发时更好地编写测试。

编辑>满足软件的要求,这意味着当代码从未打算或不需要考虑该测试用例时,他不仅仅是编写测试来故意破坏代码。

于 2009-02-24T14:35:34.600 回答
1

如果您的同事缺乏编写测试的经验,那么他或她可能难以在超出简单情况的情况下进行测试,这表明测试不充分。这是我会尝试的:

  • 花一些时间与您的同事分享测试技术,例如依赖注入、寻找边缘案例等。
  • 提供回答有关测试的问题。
  • 对测试进行代码审查一段时间。请您的同事回顾您所做的更改,这些更改堪称良好测试的典范。查看他们的评论,看看他们是否真的在阅读和理解您的测试代码。
  • 如果有些书特别适合您团队的测试理念,请给他或她一份。如果您的代码审查反馈或讨论参考了这本书,这可能会有所帮助,以便他或她有一个线程可以接受和关注。

我不会特别强调羞耻/内疚的因素。值得指出的是,测试是一种被广泛采用的良好实践,编写和维护良好的测试是一种职业礼貌,因此您的团队成员不需要在周末工作,但我不会强调这些点。

如果你真的需要“变得强硬”,那就建立一个公正的制度;没有人喜欢觉得自己被孤立了。例如,您的团队可能需要代码来维持一定水平的测试覆盖率(可以玩游戏,但至少可以自动化);需要新代码进行测试;要求审查人员在进行代码审查时考虑测试的质量;等等。建立该系统应该来自团队的共识。如果您仔细地缓和讨论,您可能会发现其他根本原因,您的同事的测试不是您所期望的。

于 2008-08-10T18:19:17.727 回答
1

@jsmorris

我曾经让高级开发人员和“架构师”在电子邮件中斥责我和一名测试人员(这是我大学毕业后的第一份工作),因为我没有熬夜并在前一天晚上完成了如此“简单”的任务。我们一整天都在忙,晚上 7 点就叫停了,我从那天中午 11 点开始就一直在吃午饭,并且至少两次纠缠我们团队的每个成员寻求帮助。

我回应并抄送团队:“我对你失望了一个月了。我从来没有得到团队的帮助。如果你需要我,我会在街对面的咖啡店。我是抱歉,我无法调试几乎所有东西都依赖的 12 参数、800 行方法。”

在咖啡店冷静了一个小时后,我回到办公室,抓起我的垃圾离开了。几天后,他们打电话给我,问我是否进来,我说我会,但我有一个面试,也许明天。

“那你辞职了?”

于 2008-08-13T19:34:12.707 回答
1

在您的源存储库中:在每次提交之前使用钩子(例如 SVN 的预提交钩子)

在该挂钩中,检查每种方法是否存在至少一个用例。使用可以通过预提交挂钩轻松实施的单元测试组织约定。

在集成服务器上编译所有内容并使用测试覆盖率工具定期检查测试覆盖率。如果代码的测试覆盖率不是 100%,请阻止开发人员的任何提交。他应该向您发送覆盖 100% 代码的测试用例。

只有自动检查才能在项目中很好地扩展。您无法手动检查所有内容。

开发人员应该有办法检查他的测试用例是否覆盖了 100% 的代码。那样的话,如果他没有提交 100% 测试过的代码,那是他自己的错,而不是“哎呀,对不起,我忘了”的错。

记住:人们永远不会做你期望的事情,他们总是做你检查的事情。

于 2008-08-29T19:19:31.150 回答
1

首先,就像这里的大多数受访者指出的那样,如果这个人没有看到测试的价值,那么你就无能为力了,而且你已经指出你不能解雇这个人。但是,这里不能选择失败,那么您可以做的几件事呢?

如果您的组织足够大,可以拥有超过 6 名开发人员,我强烈建议您设立一个质量保证部门(即使只有一个人开始)。理想情况下,您应该有 1 名测试人员与 3-5 名开发人员的比例。关于程序员的事情是......他们是程序员,而不是测试人员。我还没有采访过正式教授过适当 QA 技术的程序员。

大多数组织都会将测试角色分配给新员工,即对代码接触最少的人——理想情况下,应该将高级开发人员转移到 QA 角色,因为他们有代码经验,并且(希望)已经对可能出现的代码异味和故障点形成了第六感。

此外,犯错误的程序员可能不会发现缺陷,因为它通常不是语法错误(那些在编译中被发现),而是一个逻辑错误——当他们编写代码时,同样的逻辑也在起作用在他们编写代码时进行测试。不要让开发代码的人测试该代码——他们会发现比其他人更少的错误。

在你的情况下,如果你能负担得起重定向的工作量,让这个新人成为你的 QA 团队的第一个成员。让他阅读“现实世界中的软件测试:改进过程”,因为他显然需要在新角色中接受一些培训。如果他不喜欢它,他会退出,你的问题还是解决了。

一个稍微不那么报复性的方法是让这个人做他们擅长的事情(我假设这个人被录用是因为他们实际上能够胜任工作的编程部分),并聘请一两个测试员进行测试(大学生通常有实习或“合作”条款,喜欢曝光,而且价格便宜)

旁注:最终,您会希望 QA 团队向 QA 主管报告,或者至少不向软件开发经理报告,因为让 QA 团队向主要目标是完成产品的经理报告是一种冲突兴趣。

如果您的组织少于 6 人,或者您无法创建一个新团队,我推荐配对编程 (PP)。我不是所有极限编程技术的完全转换者,但我绝对是配对编程的信徒。但是,配对编程团队的两个成员都必须专心致志,否则根本行不通。他们必须遵循两条规则:检查员必须完全理解屏幕上正在编码的内容,或者他必须要求编码员进行解释;编码员只能编码他能解释的东西——不能容忍“你会看到”或“相信我”或挥手。

如果你的团队有能力,我只推荐 PP,因为就像测试一样,再多的欢呼或威胁都无法说服几个自负的内向者在他们不自在的情况下一起工作。但是,我发现在编写详细的功能规范和进行代码审查与配对编程之间,PP 通常会胜出。

如果 PP 不适合您,那么 TDD 是您最好的选择,但前提是从字面上理解。测试驱动开发意味着您首先编写测试,运行测试以证明它们确实失败了,然后编写最简单的代码使其工作。现在的权衡是您(应该)拥有数千个测试的集合,这些测试也是代码,并且与生产代码一样可能包含错误。老实说,我不是 TDD 的忠实拥护者,主要是因为这个原因,但它适用于许多宁愿编写测试脚本而不是测试用例文档的开发人员——有些测试总比没有好。将 TDD 与 PP 结合起来,可以提高测试覆盖率并减少脚本中的错误。

如果所有其他方法都失败了,让程序员相当于一个发誓的罐子——每次程序员破坏构建时,他们必须将 20 美元、50 美元、100 美元(无论对你的员工来说是什么痛苦的东西)放入一个你最喜欢的罐子里(注册!)慈善。在他们付钱之前,避开他们:)

除了开玩笑,让你的程序员编写测试的最好方法是不要让他编程。如果您想要程序员,请雇用程序员——如果您想要测试,请雇用测试员。12 年前,我作为一名初级程序员开始做测试,它变成了我的职业道路,我不会用它来换取任何东西。一个经过适当培养并被赋予改进软件的权力和任务的坚实 QA 部门与最初编写软件的开发人员一样有价值。

于 2008-11-07T08:58:15.360 回答
0

根据您的评论,“表明设计变得更简单”,我假设你们练习 TDD。事后进行代码审查是行不通的。TDD 的全部内容在于它是一种设计,而不是一种测试哲学。如果他没有将测试作为设计的一部分编写,那么您将不会从事后编写测试中获得很多好处——尤其是从初级开发人员那里。他最终会遗漏很多极端情况,他的代码仍然很糟糕。

你最好的选择是让一位非常有耐心的高级开发人员和他坐在一起,做一些结对编程。坚持下去,直到他学会为止。或者不学习,在这种情况下,您需要将他重新分配给他更适合的任务,因为您最终只会让您真正的开发人员感到沮丧。

并非每个人都具有相同水平的才能和/或动力。开发团队,甚至是敏捷团队,都是由“A 团队”和“B 团队”的人组成的。A-Team 成员负责构建解决方案、编写所有重要的生产代码并与企业主沟通——所有这些工作都需要跳出框框思考。B 团队处理诸如配置管理、编写脚本、修复蹩脚的错误和进行维护工作之类的事情——所有这些工作都有严格的程序,对失败的影响很小。

于 2008-08-13T23:55:44.737 回答
0

这可能有点无情,但你描述情况的方式听起来你需要解雇这个人。或者至少说清楚:拒绝遵循内部开发实践(包括编写测试)检查其他人必须清理的错误代码最终会让你被解雇。

于 2008-08-18T20:12:24.687 回答
0

初级工程师/程序员不需要花费大量时间来设计和执行测试脚本的主要原因是因为大多数 CS 认证并不严格要求这一点,因此其他工程领域将在大学课程中进一步涵盖,例如设计模式。

以我的经验,让初级专业人员养成习惯的最佳方法是明确地将其作为流程的一部分。也就是说,在估算一次迭代应该花费的时间时,设计、编写和/或执行案例的时间应该包含在这个时间估算中。

最后,审查测试脚本设计应该是设计审查的一部分,并且应该在代码审查中审查实际代码。这使得程序员有责任对他/她编写的每一行代码进行适当的测试,而高级工程师和同行则有责任对编写的代码和测试提供反馈和指导。

于 2008-08-27T03:52:11.673 回答