有一位同事认真地了解他的东西,他是我曾经合作过的最聪明的人之一,但他:
在他的主目录的小区域中工作,而不是在公共CVS存储库中工作
没有记录他的代码
没有评论他的代码,例如3,500 SLOC of C没有评论,也没有空行来解决问题
经常使事情过于复杂,例如使用三个相互调用的shell脚本来完成一个简单shell脚本可以完成的工作.
也许这可能是那些认为"如果我是唯一知道这一点的人,他们无法摆脱我"的人之一？
有关该怎么办的任何建议？
BTW管理层了解情况并试图改变一切.
在我看来,像你上面描述的那样做蠢事的人不可能是明星开发者!对我来说,似乎他故意让事情变得更复杂,所以除了他自己以外没有其他人可以维护代码.这让自己比实际更重要!跟他说话.他必须改变它!如果他不这样做,请用真正的明星开发者代替他!
我保证,即使是半年,他也不会知道自己的代码是如何运作的!解雇他,你可以节省大量的时间和金钱.
CVS部分很容易 - "意外"硬盘驱动器故障会教他一生的教训(确保你有备份,所以你不会丢失代码)
这听起来像是一个艰难的局面.
就个人而言,我会让他离开.他可能是明星开发者,但他不是团队合作者.如果你想制作一个好的产品,你需要一个有凝聚力的团队,可以一起工作.
未能记录是确保工作安全的一种(非常糟糕的)方式.
你可以做几件事来解决这个问题:
添加文档作为个人绩效评估的要求.
不接受未记录的软件.
与开发人员说一句话,找出他没有记录的原因.
购买一个很酷的文档工具.
播放你从电影中看到的坏警察/好警察素描.让管理层成为坏警察,你就是好警察.让管理人员要求他的工作过度杀戮文档和每分钟ZIP备份.但是你提供适度的文档(例如doxygen)和通常的源代码控制签到...
跟他说话？
如果他真的是一个"明星开发者",他会注意到你说的话.
它可能不会在一夜之间改变他,但可能是他完全没有意识到其他人不像他那样得到它.
编辑:
现在改变可能有点晚,但在制定解决方案时需要更多信息.这里的任何人都不可能实际建议让这个人单独根据这些观点去做.如果你去年每天都在告诉那个他需要改变的人,或者他已经离开这里,那么你可以让他离开.但是,我没有看到任何证据.
可以教导优秀的开发人员使用源代码控制,评论和文档.如果你在这里花费精力,那么你真的会有一个明星开发者.
您可能会关注错误的区域,为您提供了一个在您的过程中看到一些弱点的机会.
在他的主目录的小区域中工作,而不是在公共CVS存储库中工作
一个简单的聊天可能就足够了,版本控制的好处不言而喻,任何"聪明"的人都可能对这些好处充满热情.然而,它也可能是一个很好的机会来研究更容易使用和灵活性的替代版本控制系统(看看bzr和git).更好的是,让他参与选拔过程,如果他真的是一个"明星",他可能会有很好的投入并且更多地使用它.
没有记录他的代码
听起来不像文档是您的过程的一部分.人们会拒绝做额外的工作,如果没有明确的过程那么你就会谈论很多额外的工作.真的需要文档吗？如果是,是否有为创建它而定义的流程？你应该有一个完全致力于它的人吗？你是否应该至少有一个工具来促进它(也许像mediawiki一样简单)？
不会评论他的代码,例如3,500 SLOC of C,没有评论,也没有空白行
三个字:同行代码审查.除了明显的引人注目的好处之外,这也可以提供一些同伴压力,这是一种强大的力量,可以是一件好事.希望被同行认识得好,自我产生所有权和质量.
经常使事情过于复杂,例如使用三个相互调用的shell脚本来完成一个简单shell脚本可以完成的工作.
同样,同行代码审查.你提到管理层知道这个程序员的不足之处.他呢？如果人们不认识到他们做事的方式存在问题,那么人们就很难改变和改进.
而且,或许最重要的是,通过提出改善开发过程的计划(这不仅可以改善你的"明星",而且可以改善团队中的其他人),你可以从管理层获得一些金星.
对我来说听起来不像一个明星程序员.所有优秀的程序员都知道代码格式化和源代码控制的使用很重要.听起来虽然他自己取得了很好的进步,但他阻碍了其他团队成员的进步,这可能对完成的工作产生净负面影响.跟他说话,如果他拒绝改变他的做法,就让他走吧.
如果他真的那么聪明并且你无法改变他的方式,你也不想失去他,但你仍然希望你的代码被记录和评论,那么我的建议是让一个经验不足的开发人员为他做记录和评论.就个人而言,如果我是一名明星开发人员,如果有人对我的代码进行评论,我会觉得很愚蠢,我最终会自己开始做.与此同时,虽然没有发生这种情况,但经验不足的开发人员可能会学到一两件事.
作为一名明星开发人员,不仅仅是一名出色的程序员.如果他没有团队技能并故意无视团队标准,则需要将其提交给他.如果他在与管理层交谈后拒绝遵守这些规定,那么他可能不适合贵公司.
这个问题让我很紧张,因为虽然你所描述的人听起来很恶劣,但我可以在他身上看到一点点.
我认为我是一个非常好的团队合作者,我很幸运能够成为一支非常优秀的团队.但是,我确实使用了我的同事不理解的方法,尽管我已经非常努力地解释它们.只有相当大的经验差距,这对我们任何人都没有反映.
文档是一个广泛而棘手的主题.我试着遵循DRY(不要重复自己)格言.与代码分开的文档可能相当于重复自己,因此它可能会过时,除非您放慢脚步以使其保持最新状态.我通常的做法是随后进行修改.
通常我正在处理的问题是如此棘手,以至于我可以提前计划并记录我想要的所有内容,但是当谈到代码时,我经常发现我错了,必须重新考虑它.因此,我认为你可以提前记录内容,然后按照这一点,只适用于非常简单的问题.
无论如何,我认为这是一个很好的问题,答案并不简单.
这家伙真的是摇滚明星吗？真的吗？想想它一秒钟.他是聪明的,但是没有完成任务,或者他是否聪明并能够完成任务？
想想真的很难.
如果他真的是摇滚明星,那么也许你不应该惹他.他用他自己的过程制作了令人难以置信的令人敬畏的东西.只是因为有一种不同的做事方式最适合你,并不意味着这将使他能够创造出最好的作品.而不是试图让他屈服于你的过程,这很可能会杀死他所有的精彩,你应该尝试找到一种方式来适应他的工作方式.
如果他真的像你说的一样好,你不应该介意这样做.如果不值得努力那么做,那么他真的不是那么好.在这种情况下,你没有摇滚明星,你只是有一个不喜欢玩规则的平庸程序员.那些家伙,你应该摆脱.然而,一个气质摇滚明星通常值得痛苦,因为他或她可以产生的质量.那些人,你应该竭尽全力保持.
京公网安备 11010802040832号 | 京ICP备19059560号-6 