43

有一位同事非常了解自己的东西，他是我共事过的最聪明的人之一，但他：

  • 在他自己的主目录的小区域中工作，而不是在公共CVS存储库中工作
  • 没有记录他的代码
  • 不注释他的代码，例如 3,500条 C 的SLOC，没有注释，也没有空行来分解
  • 经常使事情变得过于复杂，例如使用三个相互调用的 shell 脚本来完成一个简单的 shell 脚本可以完成的工作。

也许这可能是那些认为“如果我是唯一知道这一点的人，他们就无法摆脱我”的人之一？

关于做什么的任何建议？

顺便说一句，管理层了解情况并正在尝试改变事情。

4

40 回答 40

126

在我看来，像你上面描述的那样做愚蠢事情的人不能成为明星开发者！在我看来，他似乎故意让事情变得更复杂，这样除了他自己之外没有其他人可以维护代码。这让他自己比实际上更重要！跟他说话。他必须改变它！如果他不这样做，请用真正的明星开发者代替他！

我向你保证，即使是半年，他也不会知道自己的代码是如何工作的！解雇他，您可以节省大量时间和金钱。

于 2009-02-10T13:59:58.493 回答
46

CVS 部分很简单——一个“意外”的硬盘故障会给他上一堂终生的教训（确保你有一个备份，这样你就不会真正丢失代码）

于 2009-02-10T13:39:40.073 回答
26

这听起来像一个艰难的情况。

就个人而言，我会让他走。他可能是一个明星开发者，但他不是一个团队合作者。如果你想制作一个好的产品，你需要有一个有凝聚力的团队可以一起工作。

于 2009-02-10T13:39:56.687 回答
20

不记录是确保工作安全的一种（非常糟糕的）方法。

你可以做几件事来解决这个问题：

  • 添加文档作为个人绩效评估的要求。
  • 不要接受没有记录的软件。
  • 与开发人员交谈并找出他不记录的原因。
  • 购买一个很酷的文档工具。
于 2009-02-10T13:45:21.527 回答
16

播放您从电影中看到的坏警察/好警察素描。让管理层成为坏警察，而你成为好警察。让管理人员要求提供他工作的过度杀戮文档和每分钟 ZIP 备份。但是您向他提供了适度的文档（例如通过 doxygen）和通常的源代码管理签入...

于 2009-02-10T14:09:12.357 回答
11

跟他说话？

如果他真的是“明星开发者”，他会注意到你说的话。

这可能不会在一夜之间改变他，但可能是他完全没有意识到其他人不像他那样明白这一点。

编辑：

现在改变可能有点晚了，但在制定解决方案时需要更多信息。这里的任何人都不可能仅根据这些观点来建议让这个人离开。如果去年你每天都在告诉那个人他需要改变或者他离开了这里，那么你可以让他离开。但是，我没有看到任何证据。

可以教一个出色的开发人员使用源代码控制、评论和文档。如果你在这里付出努力，那么你真的会拥有一个明星开发者。

于 2009-02-10T13:43:13.073 回答
10

您可能在这里专注于错误的领域，您有机会看到您的流程中的一些弱点。

  • 在他自己的主目录的小区域中工作，而不是在公共 CVS 存储库中工作

在这里简单的聊天可能就足够了，版本控制的好处不言而喻，任何“聪明”的人都可能对这些好处充满热情。然而，这也可能是一个很好的机会来研究允许更大易用性和灵活性的替代版本控制系统（看看 bzr 和 git）。更好的是，让他参与选拔过程，如果他真的是一个“明星”，他可能会有很好的投入，并且更加投入使用。

  • 没有记录他的代码

听起来文档不是您流程的一部分。人们会抵制必须做额外的工作，如果没有明确的流程，那么你就是在谈论很多额外的工作。真的需要文档吗？如果是这样，是否定义了创建它的过程？你应该有一个完全致力于它的人吗？您是否应该至少有一个工具来促进它（也许像 mediawiki 这样简单）？

  • 不评论他的代码，例如 3,500 SLOC 的 C 没有评论，也没有空行来说明问题

三个词：同行代码审查。除了明显的错误捕获好处之外，这也可以提供一些同伴压力，这是一种强大的力量，可能是一件好事。想要被你的同龄人很好地感知会自我产生所有权和质量。

  • 经常使事情变得过于复杂，例如使用三个相互调用的 shell 脚本来完成一个简单的 shell 脚本可以完成的工作。

再次，同行代码审查。你提到管理层知道这个程序员的缺陷。他有吗？如果人们不认识到他们做事方式的问题，就很难改变和改进。

而且，也许最重要的是，通过制定改进您的开发过程的计划（这可能不仅会改善您的“明星”，还可能会改善团队中的其他人），您可能会从管理层那里为自己赢得一些金星。

于 2009-02-10T17:49:55.960 回答
9

对我来说，这听起来不像是明星程序员。所有优秀的程序员都知道代码格式和源代码控制的使用很重要。听起来虽然他自己取得了很好的进展，但他正在阻碍其他团队成员的进展，这可能会对完成的工作产生净负面影响。和他谈谈，如果他拒绝改变他的做法，让他走。

于 2009-02-10T14:12:16.750 回答
8

如果他真的那么聪明，你不能改变他的方式，也不想失去他，但你仍然希望你的代码被记录和评论，那么我的建议是让经验不足的开发人员为他做文档和评论。就个人而言，如果我是一名明星开发人员，如果让其他人评论我的代码并且我最终会开始自己做，我会觉得非常愚蠢。与此同时，虽然这种情况不会发生，但经验不足的开发人员可能会学到一两件事。

于 2009-02-10T13:54:41.580 回答
7

成为明星开发人员不仅仅是成为一名优秀的程序员。如果他没有团队技能并且故意无视团队标准，则需要向他提出。如果他在与管理层交谈后拒绝遵守这些规定，那么他可能不适合您的公司。

于 2009-02-10T13:49:32.343 回答
6

这个问题让我很紧张，因为虽然你描述的这个人听起来很糟糕，但我可以在他身上看到一点我自己。

我认为我是一个非常好的团队球员，我很幸运能加入一个非常好的团队。然而，我确实使用了我的同事不理解的方法，尽管我已经非常努力地解释它们。只是经验差距很大，这对我们任何人都没有影响。

文档是一个广泛而棘手的主题。我尝试遵循 DRY（不要重复自己）的格言。与代码分开的文档可能相当于重复自己，因此除非您放慢自己的速度以使其保持最新，否则它可能会过时。我通常的做法是事后补上。

通常我正在处理的问题非常棘手，以至于我可以提前计划并记录我想要的所有内容，但是当涉及到代码时，我经常发现我错了并且不得不重新考虑它。因此，在我看来，您可以提前记录内容并遵循它的想法仅适用于非常简单的问题。

无论如何，我认为这是一个很好的问题，答案一点也不简单。

于 2009-02-10T14:48:47.503 回答
5

这家伙真的是摇滚明星吗？严重地？想一想。他是聪明，但没有把事情做好，还是他既聪明又能把事情做好？

想想真的很难。

如果他真的是摇滚明星，那么也许你不应该惹他。他正在使用自己的流程制作出令人难以置信的很棒的东西。仅仅因为有一种不同的做事方式最适合你，并不意味着这将使他能够创作出最好的作品。不要试图让他屈服于你的过程，这很可能会扼杀他所有的敬畏，你应该尝试找到一种方法来适应他的工作方式。

如果他真的像你说的那么好，你不应该介意那样做。如果不值得那么努力，那么他真的没有那么好。在这种情况下，你没有摇滚明星，你只有一个不喜欢按规则行事的平庸程序员。那些家伙，你应该摆脱它。不过，一个喜怒无常的摇滚明星通常值得痛苦，因为他或她可以制作出高质量的作品。那些人，你应该不遗余力地留住。

于 2009-02-10T13:56:06.773 回答
4

听起来像一个明星程序员，他对自己的工作感到厌烦，并且过度复杂化以使其更具挑战性。他很快就会找到更好的东西。

于 2009-02-11T03:24:22.040 回答
3

试图改变事情？你更喜欢什么，一个记录不充分的工作软件或一个记录良好的垃圾？有些人能够编写几乎不需要评论的软件，这不是质量的可靠指标。

恐怕你会失去一个优秀的开发者。

于 2009-02-10T13:40:01.180 回答
3

“嗨星开发者，

只是一个非正式的提醒告诉你，从下周开始，我们将需要代码文档，并在代码中提供有用的注释 - 这将是公司政策，不会有任何例外”

从那时起，你只需像处理未能按时上班、未能停止在工作中打发时间等一样处理失败。底线是老板说文件，你文件还是你你没有做好你的工作。

于 2009-02-10T13:56:46.240 回答
3

如果他这样工作，他就不是明星开发者——伟大的软件开发者明白可维护性是极其重要的。从长远来看，你可能会为此付出高昂的代价，我会非常直接地告诉他这有多严重，如果他不能开始适应，就让他走。我以前见过很多次，这是一个定时炸弹。

老实说，我见过很多这样的开发人员，除非他们刚刚离开学校，否则他们不会改变。我说现在削减你的无损，随着他继续喷出更多不可维护的代码，解雇他只会变得更加困难:)

于 2009-02-10T14:51:28.653 回答
2

如果他真的很聪明，管理层不太可能摆脱他。

当然，整个项目可能会被关闭，但无论如何，CVS 和文档将毫无用处。

没有管理层会解雇一个优秀的程序员只是为了雇佣一个糟糕的程序员。

告诉他，这将有助于他随时摆脱管理。

他想换什么工作？他可以告诉管理层：“好吧，人们，一切都像你问我的那样：登记、记录并在你的控制之下。我完成了我的工作，我收拾行李离开了”。

于 2009-02-10T13:41:59.800 回答
2

代码文档被高估了。CVS 培训很容易。

一个好的类应该通过它的方法和属性来揭示它的目的。

在应用程序之外记录模型也更容易流动和理解。

我会提请他注意，如果你不能解决它，看起来你将失去一位明星开发者。

编辑：哎呀 - 使用 CSV 而不是 CVS，对于许多导入，我使用 svn heh。

于 2009-02-10T13:43:19.033 回答
2

没有他，球队能成功吗？如果是这样，请推动问题并拒绝接受任何未正确记录或不符合其他标准的代码。希望这会让人明白这一点，但这可能只会让他生气并导致他退出。如果球队在没有他的情况下无法取得成功，那么你就很不走运了，直到你可以训练一个达到他技能水平的替补球员，这可能不值得花时间和精力。

于 2009-02-10T13:44:27.190 回答
2

+1 to ocdecio - 如果他是明星开发人员，那么他的代码应该基于如此高质量的设计，以至于它可以记录自己。

话虽如此，但令人沮丧的可能是，尽管他在他感兴趣的技术要求高的领域表现出色，但他并没有在交付功能时混入 - 只有你会知道这是否对你的组织来说是个问题。

有一个可用的“大师”可以是一个绝对的救星——或者至少它曾经是，或者 StackOverflow 让这个角色变得多余了？

于 2009-02-10T13:44:40.433 回答
2

在通过代码审查之前不要让代码发布，并且只有在他为当前功能/项目编写的代码有足够的注释和/或文档时才允许它通过。

编辑在他的评价中提出来。可以为他的“改进领域”提供文档/评论代码。

:-)

于 2009-02-10T13:49:54.307 回答
2

您还可以添加自动质量检查，以防止他签入他的代码，直到它被充分记录。

那就是如果你能说服他在第一时间登记入住！（这是必不可少的，imo）

于 2009-02-10T13:50:53.180 回答
2

这里有很多人在“没有评论，那又怎样？” 这里的潮流。没有注释的识字代码是完全可能的，但是仅仅因为某人很聪明并且不注释并不一定意味着他们正在编写识字代码。

所以让我们澄清一下。您已经说过他根本不记录他的代码，无论是在注释中还是在单独的文档中，并且他不使用任何源代码控制。怎么样：

  • 尽管没有注释，他的代码是否可以理解？
  • 您的团队是否使用他参与的任何类型的问题跟踪（例如 FogBugz、Bugzilla 等）？
  • 他的代码在测试中吗？
  • 团队中是否还有其他人实际上至少对他的代码是如何工作的有点熟悉？
  • 他是否愿意至少承认他可以在与团队其他成员合作的方式上做出一些改变？

如果所有这些问题的答案都是“否”，那么你就有大问题了。仅仅聪明并不一定会使某人成为资产。你能保证他明天不会离开你的公司，或者被公共汽车撞到吗？如果发生这种情况，你会有多糟糕？值得冒险吗？

于 2009-02-10T14:25:30.993 回答
2

我认为这在任何环境中都很典型。你如何让别人做你想做的事？这正是“如何赢得朋友和影响他人”的全部内容。戴尔·卡耐基（Dale Carnegie）不是操纵，而是管理人。

在我看来，他只是缺乏经验，需要一些经验和指导。

你觉得你可以坐下来和他谈谈这些问题吗？告诉某人他们做错事通常看起来是错误的做法（尤其是在当今我们不想伤害他人感情的西方社会中），但我认为通过冷静和诚实地解释问题和谈论他们。如果这个人尊重你和你的意见，这会有所帮助，这是一个完全不同的问题，在上面提到的书中有所讨论。确保他明白这些是严重的问题。此外，在任何未来的开发工作中，他也将被期望做这些​​事情，所以现在练习它们是一个好主意。

我不认为等到下一次绩效评估是一个好主意。堆积一堆负面反馈并一次提供所有反馈只是一个坏主意，当我这样做时我真的不喜欢它。

于 2009-02-10T14:29:49.233 回答
1

你不能因为没有做你在那里建议的事情而杀人。他只是不一样。

if(developer.IsHuman())
{
    developer.IsUnique = true;
}

我和那些写垃圾（并称之为代码）的人一起工作。我也这样做。有时。但是，正如您已经感觉到的，当您知道自己的工作会影响他人时，不改掉坏习惯很烦人。试着说服他更多。

而且，除非您是“经理” ，否则我认为您在这种情况下无能为力。

于 2009-02-10T14:17:44.363 回答
1

  1. 让他使用自动执行验证工具。（请参阅我的回答“如何向阻碍论者提问？ ”）

  2. 如果他过于复杂并且不使用 SCC，那么他就不是一个优秀的开发人员——这些都是软件工程的重要组成部分。

  3. 万一他在算法等领域具有不可替代的才华，分配他在该领域工作，例如定义算法，并让真正的程序员进行编码。

  4. 使用静态分析代码来理解和清理他的代码。

于 2009-02-10T14:32:06.997 回答
1

结对编程。找到他对你刚刚列出的要求将“完成”他。您将通过源代码控制、文档记录、质疑他的每一个行为等来解决问题。您还可以利用第一人的力量训练其他人

于 2009-02-10T14:52:42.860 回答
1

从你的描述来看，这家伙显然不是明星开发者。编程是一项团队运动，与他人相处不好的人不会为项目增加太多价值。

就个人而言，我可能不记得我在 6 个月或更长时间前编写的代码，并且非常重视某种源代码控制中的更改历史。

如果你和这个人定期进行代码审查，我想你会发现他并不像你想象的那样出色。

于 2009-02-10T15:03:29.137 回答
1

我同意这个线程上的大多数人。将他置于热点的一种方法是进行团队代码审查。

对于第一次代码审查会议，从开放并接受建议的团队成员中选择代码。“明星”开发人员将有机会了解代码审查是如何工作的，然后您可以安排他的代码进行下一步审查。给他一些时间为下一次会议做准备，到那时他至少应该评论他的代码。

代码审查的目的不是要让人们感到羞耻，而是要协作识别问题和需要改进的地方，但这将是让明星开发人员坐上热搜的好方法。

于 2009-02-10T15:17:17.187 回答
1

在我看来，你需要放弃这个人。听起来他的代码是不可读的，他绝对不是一个团队，也不是一个安全的球员。

让某人认为自己是不可或缺的也是一种非常糟糕的做法。如果你让他继续这样做，他的做法会变得更糟，而不是更好。当他离开时，对于每个人来说，你都会对纠结的代码感到头疼。如果他不恢复，你现在需要减少损失。

最后，留住这位开发人员而不控制他，这给初级开发人员树立了一个糟糕的榜样。如果你强迫他们正常工作，你可能会受到“为什么是他而不是我”人群的不满。如果你不这样做，你会得到一堆像你的“明星”一样工作的黑客。

简而言之，除非他非常非常快地成型，否则是时候放弃他了，为了整个开发人员的健康和理智。

于 2009-02-10T16:25:34.090 回答
1

当我在 3 年前开始现在的工作时，我们遇到了类似的问题，我们的首席开发人员是一名牛仔。他真的很聪明，但非常不稳定，他的一些东西有很好的文档记录，但过于复杂以至于无法维护，或者先编写代码然后弄清楚他在构建什么，他会扔掉代码，看看能坚持什么。

他大约在 2 1/2 年前离开了，当我们找到他的一些旧代码时，它仍然困扰着我们，并且在他的辩护中，这就是这里的开发商店当时的运作方式，在过去的 3 年里，我一直在讨伐改变这种心态。

当您成为明星开发人员时，您就不再关心您对系统、代码、框架、架构等的了解程度，而是更多关于

  1. 编写优雅、可维护、灵活、可读的代码
  2. 与团队的其他成员一起工作：使用源代码控制、以身作则等。
  3. 记录每个方法、类、对象等在做什么
  4. 研究新的更好的方法来为自己和你的团队做事

如果您没有在某种程度上遵循所有这四个，您就不是明星开发者，更何况如果您拒绝尝试/学习使用它们，那么是时候以某种方式寻找其他就业机会了，我听说饥饿的艺术家很受欢迎与这个时代的人（整个误解天才的事情）

于 2009-02-10T16:48:16.360 回答
1

虽然在某些情况下个人成就可能很重要且有用，但最终使大多数项目成功的是团队合作以及所有参与者和利益相关者之间的良好合作。

文档是协作过程的一部分。如果您的“明星开发者”不重视这个话题，请通知他并将其放在他的评论中。

记录您的“明星开发者”由于缺乏文档而导致的问题。用这些问题的例子向高层管理人员说明这个问题，并确保他理解后果。如果他在这方面继续失败，那么将其视为任何其他失败......终止是最后的课程。

最重要的是，让他意识到问题并给他一个改进的机会。如果您在约定的时间内没有看到任何改善，那么他就不愿意改善自己和团队。你知道必须做什么！

祝你好运！安德烈斯

于 2009-02-10T17:06:01.667 回答
1

可能是他“知道他的东西”的原因是因为它正是——“他的东西”。最好的代码是其他程序员可以自信地理解和修改的代码。

不指导他人并且只编写他们理解的代码的令人印象深刻的编码人员在恕我直言是一种责任 - 特别是在他们回答了足够多的问题之后，因此您知道如何重写他们的代码并可以将它们发送给其他人。

于 2010-02-07T03:12:19.883 回答
1

我就是那个人。

让我大开眼界的是升职。一位非常聪明的老板让我成为“团队负责人”，说他认可我的编码能力，并希望我帮助团队的其他成员达到我的标准（他是一个说话圆滑的酒吧管家）。然后他给了我一组没有明确包括“文档”、“评论”等的目标——但这不可避免地把我推向了那个方向。一旦我的工作是告诉团队的其他成员如何做他们的工作，我自己就不太可能不去做。

目标是“当新开发人员加入时，他需要在 5 天内充分发挥生产力”；“部署必须少于 3 天”，“代码必须通过我们的外部审计团队的审计”，以及“实施持续集成和单元测试”。

于 2011-11-17T13:19:15.203 回答
0

惯于？如果您已经尝试过其他所有方法，那么可能是时候提醒他在他的工资支票上签名的人了。

严重地！

一个明星开发者在他被公共汽车撞到并且其他人必须在他的代码上工作之后的 5 年对你没有好处。

不使用 CVS？在我工作的一家公司，我们因不签到而被罚款，罚款三笔，然后你就被解雇了。你的源代码就是你的生意，你失去了你的源代码你就失去了生意。再次，我会提醒这个人，他的薪水取决于以下公司标准。

于 2009-02-10T14:29:37.130 回答
0

经常使事情变得过于复杂，例如使用三个相互调用的 shell 脚本来完成一个简单的 shell 脚本可以完成的工作。

这听起来不像是他在给我写有文化的自我记录代码，而是相反。似乎他对过于复杂的解决方案的选择产生了对文档的异常大的需求，并且也使缺乏文档成为一个更严重的问题。

于 2009-02-10T20:04:25.000 回答
0

我认为团队成员应该了解彼此的职责，即使用 DB 是 DBA 的职责，您不要要求 QA 应用 DB 补丁。DBA 不能拒绝，因为这是他/她的责任。每个人都应该清楚，团队成员的职责之一是编写其他团队成员易于理解的代码。我认为从这个角度来看，它应该由他的报告人来解决。

如果您的 DBA 不使用 DB，而是做其他事情，比如构建 UI，那么他/她就不会做他的工作。你的同事也一样——如果他编写的代码无法被其他团队成员理解——他就没有做好他的工作。

编写同事无法理解的代码不应视为完成任务。编写不在 CVS 中的代码，因此无法被其他团队成员审查，直到为时已晚 - 也不应被视为完成任务。写 3 个脚本而不是 1 个应该被认为是浪费时间。

如果管理层无法理解这一点并仍然认为他是摇滚明星程序员 - 考虑更换管理层。

我还要强调，目标不是写评论本身。它应该是可理解的代码，易于维护。我个人认为注释是使我的代码易于理解的最后手段——我更喜欢简洁的设计和命名。

于 2009-02-11T01:12:23.870 回答
0

将他的代码还给他并告诉他修复它，否则他会被解雇。

于 2009-02-11T01:31:05.620 回答
0

代码审查失败。

于 2009-02-11T01:33:52.070 回答
0

除了许多其他建议之外，您还可以尝试以下另一种技巧：

无论出于何种原因，您似乎都倾向于认为您的开发人员的行为和方法很糟糕。假设你已经和他讨论过，而他没有提供让你满意（或愿意改变）的理由，我会说你有两个明显的选择：摆脱他，或者接受它。我建议，在这种情况下，你对他如何编写代码的要求非常坦率，让他选择接受或离开。

例如，我的前任雇主（在管理层改组后）决定不再允许开发人员在代码中使用“断言”，因为他们认为这不必要的混乱，并且与现在“负责”的现有风格不一致" 组（他们编写了非常直接的低级 C 风格代码，没有断言或防御性编程技术）。管理层和我进行了直接讨论，他们告诉我我需要适应他们的风格或者离开，我决定离开。总的来说，我认为这对双方来说都是最好的。

并不是每个人都会对编码、代码指南或开发过程有相同的看法，最终，付钱的人制定规则（与实际生产事物的需要相平衡）。你对自己的需求越是坦诚，开发者的怨恨就越少。

于 2009-02-11T03:42:28.643 回答