对于不记录其工作的明星开发人员该怎么办？[关闭]
https://stackoverflow.com/questions/532338
-
22-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian解决方案
在我看来，做你上面描述的愚蠢事情的人不可能成为明星开发人员！在我看来，他似乎故意让事情变得更加复杂，这样除了他自己之外没有人可以维护代码。这让他自己变得比他真正的自己更重要！跟他说话。他必须改变！如果他不这样做，就用真正的明星开发者取代他！
我向你保证，半年之内他都不会知道自己的代码是如何工作的！解雇他，你可以节省大量时间和金钱。
其他提示
CVS 部分很简单 - 一次“意外”硬盘故障会给他一个终生难忘的教训（但要确保你有备份，这样你就不会真正丢失代码）
这听起来是一个艰难的处境。
就我个人而言，我会让他走。他可能是一名明星开发人员，但他不是一名团队合作者。如果你想做出好的产品，你需要有一个有凝聚力的团队，可以一起工作。
不记录是确保工作安全的一种（非常糟糕的）方法。
您可以采取多种措施来应对这种情况：
- 添加文档作为个人绩效评估的要求。
- 不接受未记录的软件。
- 与开发人员交谈并找出他不记录的原因。
- 购买一个很酷的文档工具。
播放 坏警察/好警察 你在电影中看过的素描。让管理层当坏警察，你当好警察。让管理层要求他提供过多的文档和每分钟的 ZIP 备份。但是你为他提供了适度的文档（例如 doxygen 提供的）和通常的源代码控制检查......
跟他说话？
如果他真的是“明星开发者”，他会注意到你说的话。
这可能不会在一夜之间改变他，但他可能完全没有意识到其他人并不像他那样理解它。
编辑：
现在改变可能有点晚了，但需要更多信息来制定解决方案。这里的任何人都不可能仅仅根据这些点就真正建议让这个人走。如果你在过去的一年里每天都告诉这个人他需要改变或者他离开这里，那么你可以让他走。然而，我没有看到任何证据。
优秀的开发人员可以学会使用源代码控制、注释和文档。如果您在这里付出努力，那么您将真正拥有一位明星开发人员。
您可能在这里关注了错误的领域，您有机会看到流程中的一些弱点。
- 在他自己的主目录的小区域中工作，而不是在公共 CVS 存储库中工作
在这里，简单的聊天可能就足够了，版本控制的好处不言而喻，任何“聪明”的人都可能对这些好处充满热情。然而，这也可能是研究替代版本控制系统的好机会，这些系统可以提供更大的易用性和灵活性（看看 bzr 和 git）。更好的是，让他参与选择过程，如果他真的是一个“明星”，他可能会有很好的投入，并且会更倾向于它的使用。
- 没有记录他的代码
听起来文档并不是您流程的一部分。人们会抵制做额外的工作，如果没有明确的流程，那么你就会谈论大量的额外工作。真的需要文档吗？如果是，是否定义了创建它的流程？你应该有一个人完全致力于它吗？您至少应该有一个工具来促进它（也许像 mediawiki 这样简单的东西）？
- 不评论他的代码，例如3,500 个 C SLOC，没有注释，也没有空行来补充内容
三个词：同行代码审查。除了明显的错误捕捉好处之外，这还可以提供一些同行压力，这是一股强大的力量，可能是一件好事。想要被同事良好地看待，就会产生主人翁意识和品质。
- 经常使事情变得过于复杂，例如使用三个相互调用的 shell 脚本来完成一个简单 shell 脚本可以完成的工作。
再次，同行代码审查。您提到管理层知道该程序员的缺陷。他有吗？如果人们不认识到自己做事方式中存在的问题，那么他们就很难改变和改进。
而且，也许最重要的是，通过提出改进开发流程的计划（这可能不仅会改善您的“明星”，还会改善团队中的其他所有人），您可能可以从管理层那里为自己赢得一些金星。
对我来说听起来不太像明星程序员。所有优秀的程序员都知道代码格式化和源代码管理的使用很重要。听起来虽然他自己取得了良好的进展，但他阻碍了其他团队成员的进展，这可能会对完成工作产生净负面影响。和他谈谈，如果他拒绝改变他的做法，就让他走。
如果他真的那么聪明，你无法改变他的方式，也不想失去他，但你仍然希望你的代码被记录和评论，那么我的建议是让经验不足的开发人员为他做记录和评论。就我个人而言，如果我是一名明星开发人员，如果让其他人评论我的代码，我会觉得很愚蠢，而我最终会开始自己做。与此同时，虽然这种情况不会发生，但经验不足的开发人员可能会学到一两件事。
成为明星开发人员不仅仅只是成为一名优秀的程序员。如果他不具备团队技能并且故意忽视团队标准，则需要向他提出这一问题。如果他在与管理层交谈后拒绝遵守这些规定，也许他不适合你的公司。
这个问题让我很紧张，因为虽然你所描述的这个人听起来很令人震惊，但我可以在他身上看到一点我自己的影子。
我认为我是一个非常好的团队合作者，而且我很幸运能够加入一支非常好的团队。然而，我确实使用了同事们不理解的方法，尽管我已经尽力解释它们。只是存在相当大的经验差距，这对我们任何人来说都没有反映。
文档是一个广泛而棘手的主题。我尝试遵循 DRY（不要重复自己）的格言。与代码分离的文档可能相当于重复自己，因此它很可能会过时，除非您放慢速度以使其保持最新状态。我通常的做法是事后修饰。
通常我正在处理的问题非常棘手，我可以提前计划并记录我想要的一切，但当涉及到代码时，我经常发现我错了，必须重新思考。因此，在我看来，可以提前记录内容并遵循它的想法只适用于非常简单的问题。
无论如何，我认为这是一个很好的问题，而且答案一点也不简单。
这家伙真的是摇滚明星吗？严重地？想一想。是他很聪明，但没有把事情做好，还是他既聪明又能把事情做好？
想想真的很难。
如果他真的是摇滚明星，那么也许你不应该惹他。他使用自己的流程生产出令人难以置信的出色产品。仅仅因为有一种最适合你的不同的做事方式，并不意味着这将使他能够创作出最好的作品。不要试图让他屈服于你的流程，这很可能会扼杀他所有的魅力，你应该尝试找到一种方法来适应他的工作方式。
如果他真的像你说的那么好，你不应该介意这样做。如果不值得为此付出努力，那么他真的没那么好。在这种情况下，你没有一个摇滚明星，你只是一个平庸的程序员，不喜欢遵守规则。这些家伙，你应该摆脱掉。不过，脾气暴躁的摇滚明星通常值得承受痛苦，因为他或她能创作出高质量的作品。那些人，你应该想尽办法去挽留。
听起来像是一个明星程序员，他对自己的工作感到厌倦，并且让事情变得过于复杂，使其更具挑战性。他很快就会找到更好的东西。
试图改变一些事情？您更喜欢哪个，一个文档不完整的工作软件还是一个文档良好的垃圾？有些人能够编写几乎不需要注释的软件，这并不是可靠的质量指标。
我担心你会失去一个优秀的开发人员。
“您好，明星开发者，
只是一个非正式的提醒，告诉您从下周开始，我们将要求提供代码文档，并在代码中提供有用的注释 - 这将是公司政策，没有例外”
从那时起，你就可以像处理未能按时上班、未能停止工作中偷懒等问题一样处理这种失败。最重要的是，如果老板说要记录，你就记录，否则你就没有做好你的工作。
如果他这样工作，他就不是明星开发人员——伟大的软件开发人员都明白可维护性极其重要。从长远来看，你可能会为此付出高昂的代价，我会非常直接地告诉他这有多严重，如果他无法开始调整，就让他走。我以前已经见过很多次了，这是一个定时炸弹。
说实话，我见过很多这样的开发人员，除非他们刚刚走出学校，否则他们不会改变。我说现在就砍掉你的无损，因为他继续吐出更多难以维护的代码，解雇他只会变得更加困难:)
如果他真的很聪明，管理层不太可能解雇他。
当然，整个项目可能会被关闭，但无论如何，CVS 和文档将没有用处。
没有哪个管理层会解雇一名优秀的程序员而只雇用一名糟糕的程序员。
告诉他这会有帮助 他 只要他愿意，就可以摆脱管理层。
他想换什么工作？他可以告诉管理层：“好吧，朋友们，一切就像你们问我的那样：签入、记录并在您的控制之下。我完成了我的部分，我收拾行李离开”。
如果没有他，球队能取得成功吗？如果是这样，请推动该问题并拒绝接受任何未正确记录或不符合其他标准的代码。希望这能让他明白这一点，但这可能只会让他生气并导致他放弃。如果球队在没有他的情况下无法取得成功，那么你就不走运了，除非你能训练出一个达到他技术水平的替代者，而这可能不值得花费时间和精力。
+1 ocdecio - 如果他是明星开发人员，那么他的代码应该基于如此高质量的设计，并且可以记录自身。
话虽如此，令人沮丧的可能是，尽管他在他感兴趣的技术要求高的领域表现出色，但他并没有在功能交付上搞砸——只有你知道这对你的组织来说是否是一个问题。
拥有一个可用的“大师”绝对是救星——或者至少过去是这样，还是 StackOverflow 已经让这个角色变得多余了？
在通过代码审查之前不要发布代码，并且仅当他为当前功能/项目编写的代码有足够的注释和/或文档时才允许其通过。
编辑 在他的评价中提出来。可以向他提供文档/注释代码以供他“改进的领域”。
:-)
您还可以添加自动质量检查，以防止他签入代码，直到代码得到充分记录。
前提是你能首先说服他入住！（这是必要的，我认为）
“没有评论，那呢？”这里有很多人。潮流在这里。没有注释的文字代码是完全可能的，但是仅仅因为某人很聪明并且不注释并不一定意味着他们正在编写文字代码。
那么让我们澄清一下。您已经说过他根本不记录他的代码，无论是在注释中还是在单独的文档中，并且他不使用任何源代码控制。怎么样：
- 尽管缺乏注释，他的代码是否可以理解？
- 您的团队是否使用任何类型的问题跟踪（例如FogBugz、Bugzilla 等）他参与了哪些？
- 他的代码正在测试中吗？
- 团队中是否还有其他人实际上至少在一定程度上熟悉他的代码的工作原理？
- 他是否愿意至少承认他可以对与团队其他成员的合作方式做出一些改变？
如果所有这些问题的答案都是“否”，那么你就有大问题了。仅仅聪明并不一定能让某人成为资产。你能保证他明天不会离开你的公司，也不会被公交车撞到吗？如果发生这种事，你会有多糟糕？值得冒这个风险吗？
我认为这在任何环境中都是非常典型的。你如何让别人做你想做的事？这正是“如何赢得朋友并影响别人”的意义所在。戴尔·卡内基关心的不是操纵，而是管理人。
在我看来，他只是缺乏经验，需要一些经验和指导。
你认为你可以坐下来和他谈谈这些问题吗？告诉某人他们做错了事通常看起来是错误的事情（特别是在当今的西方社会，我们不想伤害别人的感情），但我认为通过冷静和诚实地解释问题和解决问题，你可以走得更远。与他们交谈。如果这个人尊重你和你的意见，这会有所帮助，这是一个完全不同的问题，并且在上面提到的书中讨论过。确保他明白这些都是严重的问题。此外，在未来的任何开发工作中，他也将被期望做这些事情，所以现在就练习它们是个好主意。
我认为等到下一次绩效评估不是一个好主意。堆积一堆负面反馈并一次性交付只是一个坏主意，我真的不喜欢这样做。
代码文档被高估了。CVS 培训很简单。
一个好的类应该通过它的方法和属性来揭示它的用途。
在应用程序外部记录模型也更容易流动和理解。
我会提请他注意，如果你不能解决这个问题，看起来你将失去一位明星开发人员。
编辑：哎呀 - 使用 CSV 而不是 CVS，对于许多导入，我使用 svn 呵呵。
让他使用自动执行验证工具。（参见我的回答“如何向阻挠者提问？")
如果他过于复杂化并且不使用 SCC，那么他就是 不是 一个优秀的开发人员——这些都是软件工程的重要组成部分。
万一他在算法等领域有一些不可替代的才华，就指派他在该领域工作，例如定义算法，并找一个真正的程序员来编码。
使用静态分析代码来理解和清理他的代码。
结对编程。找到一对能够“完善”他以满足您刚才列出的要求的人。您将通过源代码控制、文档、质疑他的每一个操作等来解决问题。你还可以利用第一个人的力量来训练其他人
从你的描述来看，这个人明显是 不是 明星开发商。编程是一项团队运动，那些不能与他人合作的人不会为项目增加太多价值。
就我个人而言，我可能不记得 6 个月或更长时间前编写的代码，并且非常重视某种源代码控制中的更改历史记录。
如果您定期与这个人进行代码审查，我想您会发现他并不像您想象的那样是一位出色的开发人员。
我同意大多数人的观点。让他成为焦点的一种方法是进行团队代码审查。
对于第一次代码审查会议，请从开放并接受建议的团队成员中选择代码。“明星”开发人员将有机会了解代码审查的工作原理，然后您可以安排接下来审查他的代码。给他一些时间准备下一次会议，到那时他至少应该评论他的代码。
代码审查的目的不是为了让人们感到羞耻，而是为了共同找出问题和需要改进的地方，但这将是让明星开发人员处于困境的好方法。
在我看来，你需要放弃这个人。听起来他的代码不可读，他绝对不是一个团队，也不是一个安全的玩家。
让某人认为自己是不可或缺的也是一种非常糟糕的做法。如果你让他继续这样，他的练习会变得更糟，而不是更好。当他离开时，就像每个人都会离开的那样，你将会因混乱的代码而感到非常头疼。如果他不恢复正常，你现在就需要减少损失。
最后，保留这位开发人员而不控制他，给初级开发人员树立了一个不好的榜样。如果你强迫它们正确工作，你可能会遭到“为什么是他而不是我”人群的不满。如果你不这样做，你就会遇到一群像你的“明星”一样工作的黑客。
简而言之，除非他恢复得非常非常快，否则是时候放弃他了，为了整个开发人员的健康和理智。
三年多前，当我开始现在的工作时，我们也遇到了类似的问题，我们的首席开发人员是一名牛仔。他真的很聪明，但很不稳定，他的一些东西有很好的文档记录，但过于复杂，无法维护，或者先编码，然后再弄清楚他要构建什么，他会扔掉代码，看看哪些可以坚持下去。
他大约 2 1/2 年前离开了，当我们发现他的一些旧代码时，它仍然困扰着我们，在他的辩护中，这就是这里的开发商店当时的运作方式，在过去的 3 年里，我一直在进行十字军东征来改变这种心态。
当你成为明星开发人员时，你对系统、代码、框架、架构等的了解程度就不再那么重要了。以及更多关于
- 编写优雅、可维护、灵活、可读的代码
- 与团队其他成员合作：使用源代码控制、以身作则等。
- 记录每个方法、类、对象等正在做什么
- 研究新的、更好的方法来为你自己和你的团队做事
如果您在某种程度上没有遵循所有这四个内容，那么您不是明星开发人员，更重要的是，如果您拒绝尝试/学习使用它们，那么是时候以某种方式找到其他就业机会了，我听说饥饿的艺术家很受欢迎与这个时间的人（整个误解天才的事情）
