碰到一个钉子户，请大家给点意见

其实我们组的人都爱上javaeye，我写在javaeye上也希望他哪天良心发现能看看，然后反省下自己。。。
可惜他老人家应该至今都没看过吧。。。。

可能误会我的意思了。
我的意思是，把checkstyle验证写到脚本里，用脚本向svn提交代码时，如果checkstyle有问题就直接中断，必须checkstyle检测出的错误为零才可以向svn提交代码。以前听说有人这么做过，感觉非常邪恶。

代码规范，要不能这么要求，那基本就没啥效果了，全靠人类本身追求完美的意愿，常常会被懒惰打败。
与其让xx去读xx，不如让他随便写呢，必须限制什么什么绝对不能写，写了就要发回去重做，才有效果。做不到这么具体的话，趁早还是别对代码规格做要求了。

不过，看你说的情况，代码规范尚在其次，那位高人写的代码似乎根本运行不了啊。想法给他配一个测试，要不就强调单元测试，见红的时候千万别提交给svn，省得把其他人的代码都搞乱。

看看能不能至少从team里踢掉他，或者和项目经理说，这人没法用，要么换人，要么加工期。

要是有人在team里不干活还有人把他的活接下来，其他人会怎么想。

希望上帝保佑我啊~~~我也想用邪恶的方法，可惜不会~~嘿嘿~~ 

加工期也没用，只要他动手改了代码，我们就又的改。。。如此循环~~~我还是不让他写得了~~~一了百了~~~

正解正解...如此这般甚好甚好...

以我带team的经验，宁教笨人，不教“恶”人。如果人的品格有问题，他还是不要成为合格的程序员才好，否则走到哪里害人到哪里。
所以楼主的目标应该遵循下面的优先顺序：
1. 赶走。方法有很多，基本上兄弟们都说到了，我也没有高招。
2. 赶不走的话，边缘化他。就是不给他活儿干，或者让他做调研之类的活儿，或者干无关紧要的体力活。如果他是那种拿到调研任务5分钟就号称搞定的家伙，你大可把题目做细一点，比如定下来调研课题后，找本讲这个东西的书，把目录抄一遍，告诉他这是调研提纲，每个问题都必须回答，要有示例程序。反正要求很明确，做不到就返工。
3. 不能赶走也不能边缘化，还不能表现出不重用的话，可以给他些假任务。这个要点技巧的，比如可以故意给某个模块弄出点过度设计，其中一部分是可有可无的，没实现也不影响整体运行的，但如果老大要review也能理直气壮的说出其重要性。这样的模块交给此君，反正随便你了，做成啥样都行，还可以假模假式的review、提出整改意见。

我一般不建议对不能赶走又不能边缘化的人采取穿小鞋的方法，例如故意刁难他，让他心怀怨怼的离开。道理很明白，如果有人持反对意见我倒很有兴趣讨论一下。

似乎赞成边缘化他的人比较多，这里我要提醒楼主一声，你要做好自我保护。他不是傻瓜，在被边缘化一段时间后说不定会心生怨恨，如果要报复你怎么办(有靠山的小人)？自我保护有两个方面：
1. 收集他工作不力的证据。新劳动法规定，要证明员工工作不力，必须有其认可的书面材料。就是说，你得在布置任务时发邮件给他，把要求都讲清楚，他的产出也邮件给你，然后把你认为他做的不合要求的地方再邮件给他，要求他确认(他如果不肯确认，不妨在邮件里说明“如果x月x日x点钟之前不回复，就认为你已认可。”)。往来邮件可以写的官样文章，这样如果起争议，错不在你。
2. 布置垃圾任务时尽量隐蔽。公司不会容忍你占用一个名额却不让他有产出，即使你有客观原因。(不要说什么不公平，这世道本来就……嘿嘿~)。如果你给布置的是看上去冠冕堂皇且经得起推敲的任务，那么在起争议时，最多就是你在技术判断上有失误，而不是故意排垃圾任务刁难他。

需要声明一下，我team里没这样的家伙，我也只不过是在几年TL经验的基础上纸上谈兵罢了，可别给我戴上“阴险”、“狡诈”之类的高帽子。

另外，各位刚当上、即将要当TL的兄弟们，推荐你们看看《职场动物进化手册》，挺有意思的一本书，适合中国国情。

this和resourcesManager是一个东西？
如果不是，又代表什么？
如是，请问，您的junit里不检验业务逻辑？那么，你确信这两行代码不是  从别处复制粘贴过来修改不彻底造成的？
程度员误写这两行代码最初的意图是什么？或者，是重构不彻底造成的？

总之，你就那么确信它代表的业务逻辑没错？

张口闭口junit，对它应该保证什么还这么没谱。不像你，动不动就汗人家，我倒不觉得汗，因为你丫根本就是P都不会。

这位仁兄的建议很中肯，受教了~~~

这位兄台的语气过激了，无论对错，大家还是应该心平气和的讨论~~~
this是包含这2行代码的类，因为这2行上面有set/get方法，所以是得到值后自己set给自己了。
犯这个错，应该是他贴别人代码，然后又没改对；因为其他地方也有类似copy但是没有改完全的代码，所以我是这么认为的。。。