如果你作为 leader,怎么委婉的跟下属说他的代码有一些小的毛病?

2017-12-12 12:43:46 +08:00
 xiaojunjor

某一个模块,业务是实现了的,但是有的地方不是很完美

比如效率低,但是因为模块涉及到的数据量很小,所以不仔细看代码的话,发现不了

比如重复定义变量,方法变量名不规范等等

就是这些我感觉,跟“工作能力”没有太大的关系,而是跟“工作是否用心”有关系的事,怎么去讲,能让对方比较好接受一些,并且知道以后类似的这些东西需要“用点心”去写,而不是单纯的“实现业务”就可以了?

10466 次点击
所在节点    程序员
109 条回复
zhouquanbest
2017-12-12 14:00:17 +08:00
我一般很直白,直接拉过来问:
傻屌,你这写的什么玩意
openSUSE
2017-12-12 14:00:47 +08:00
搞事的话,#1 @T110E5 的做法可取。
直接说,别绕弯子,绕弯子容易产生误解。

Q:“如效率低,但是因为模块涉及到的数据量很小,所以不仔细看代码的话,发现不了”
A:直接说要改,效率要提高 balabala ……

Q:“比如重复定义变量,方法变量名不规范等等”
A:让他们把开发规范文档再细看一遍。

Q:“就是这些我感觉,跟“工作能力”没有太大的关系,而是跟“工作是否用心”有关系的事,怎么去讲,能让对方比较好接受一些,并且知道以后类似的这些东西需要“用点心”去写,而不是单纯的“实现业务”就可以了?”
A:方便告诉我贵司的地址吗?你的团队缺人不,我能加入吗?我能帮你传达心声。
Catyuki
2017-12-12 14:00:48 +08:00
....好吧 或许我改检讨..每次低级问题都压不住火气直接喷了 如果是重大问题反而耐心去沟通解决
sbw
2017-12-12 14:01:08 +08:00
review 里直接回复
很多开源项目贡献代码的时候对格式、命名还有 commit msg 都有很高要求的
经常因为一个空格,一个大小写就扣分
iFlicker
2017-12-12 14:04:49 +08:00
为什么不直接说呢。。
Felldeadbird
2017-12-12 14:15:01 +08:00
有什么好委婉的。直接说出来:
小李啊,你这段代码写得不够优雅啊。你这样的话,没有抽象出来,后面维护的人会难写接口的。你改一下。
fasling
2017-12-12 14:17:17 +08:00
代码上的事情直接说,没什么委婉不委婉的。
zhoucan007
2017-12-12 14:18:46 +08:00
之前当过老师,有一个活动叫评课,跟程序员的 Code Review 很像啦。我们评价一个人是有套路的,如果有什么缺陷,会这么说:XX 的这个做的非常的好,那个做的也非常的好,如果在 XXXXXXX 方面稍微加强一下,那就太完美了。

自己体会。
forestyuan
2017-12-12 14:20:13 +08:00
“比如效率低,但是因为模块涉及到的数据量很小,所以不仔细看代码的话,发现不了”

既然数据量很小,效率低点怕什么?貌似楼主有点吹毛求疵了
linuxchild
2017-12-12 14:26:30 +08:00
直接说就好,是我我不会介意的
chuhemiao
2017-12-12 14:30:11 +08:00
有这样的老大何愁不进步,还招人吗
hitmanx
2017-12-12 14:30:50 +08:00
增加个 code review 的环节,有啥问题大家就直说咯,对事不对人。其实团队的代码要求提高了,对于团队中的每个人来说都是有帮助的。
algery
2017-12-12 14:32:17 +08:00
我们是直接怼的 哈哈哈
DiverRD
2017-12-12 14:37:38 +08:00
我多希望我们老大会跟我说,你这块代码不够好 ,应该这样写。balabala.......
nekoyaki
2017-12-12 14:41:49 +08:00
说一个情况,我不知道贵司有没有绩效考核或者每天汇报之类的,如果有的话,可能也会阻止员工对代码的追求。
像我在小公司的时候,每天什么时候发现代码里有不合理的地方都会试图进行优化甚至重构,但在大公司这个自我改良动力就明显减弱了,因为其中许多都没法算到我的绩效里,也影响每天的汇报。
xomix
2017-12-12 14:42:52 +08:00
某一个模块,业务是实现了的,但是有的地方不是很完美
模块需求文档里面怎么写的?有什么标准为完美吗?你一开始不说的话都指望自觉又希望大家越快越好,大家把握不住这个度出现什么不完美都正常。

比如效率低,但是因为模块涉及到的数据量很小,所以不仔细看代码的话,发现不了
没有效率需求,又是小数据量,低效率快速开发是一种解决方案。

比如重复定义变量,方法变量名不规范等等
这是一个编程习惯,你需要从需求上就说清楚。

就是这些我感觉,跟“工作能力”没有太大的关系,而是跟“工作是否用心”有关系的事,怎么去讲,能让对方比较好接受一些,并且知道以后类似的这些东西需要“用点心”去写,而不是单纯的“实现业务”就可以了?
那你布置业务的时候怎么不会“用点心”的布置下去,让同事更清楚你的需求。

一到公司给一个模块让你随便写,写完了再这儿那儿的毛病一挑,这是立威吗?
wangdu2012
2017-12-12 14:44:43 +08:00
不需要委婉直接说
wampyl
2017-12-12 14:44:47 +08:00
我想要个这个的老大.jpg 。毕业刚加入的公司老大没啥经验,他都不重视这个,很想在自己的团队加入 code review。
saulshao
2017-12-12 14:56:59 +08:00
我觉得首先要表扬人家做的好的方面,然后再指出不足,如果只是小的问题,其实作为 leader,大可不管。
如果 leader 觉得严重影响了产品 /代码质量,那就不是小的问题
Khlieb
2017-12-12 14:59:59 +08:00
大家一块 debug

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/414064

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX