这是一个创建于 2862 天前的主题，其中的信息可能已经有所发展或是发生改变。
某一个模块，业务是实现了的，但是有的地方不是很完美
比如效率低，但是因为模块涉及到的数据量很小，所以不仔细看代码的话，发现不了
比如重复定义变量，方法变量名不规范等等
就是这些我感觉，跟“工作能力”没有太大的关系，而是跟“工作是否用心”有关系的事，怎么去讲，能让对方比较好接受一些，并且知道以后类似的这些东西需要“用点心”去写，而不是单纯的“实现业务”就可以了？
 | 1 T110E5 2017-12-12 12:48:55 +08:00 via Android 大家一起搞个 review |
 | 2 liangdu 2017-12-12 12:49:27 +08:00  20 老大，我知道了，下次会注意写好代码的。下周五我想请假去面试。 |
 | 3 doublleft 2017-12-12 12:57:10 +08:00 1 委婉？不存在的，我一般都会说这里有颗鼻屎你擦一下 |
 | 4 kiwi95 2017-12-12 13:03:18 +08:00 1 你是老大，又不是他是老大。。。老大都还这么谨慎的吗 |
 | 5 tmac 2017-12-12 13:04:46 +08:00 via Android 每天下午下班前固定 code review 半小时。这些都是对大家有帮助的。直说也无妨。 |
 | 6 maemual 2017-12-12 13:04:57 +08:00 code review 的时候会明确说 |
 | 7 zjuster 2017-12-12 13:07:38 +08:00 你是他老大，不需要委婉... |
 | 8 Kmzl 2017-12-12 13:08:39 +08:00 via Android 我希望我老大直说 |
 | 9 SourceMan 2017-12-12 13:09:49 +08:00 不说他怎么进步？？ |
 | 10 notreami 2017-12-12 13:10:23 +08:00 直接吐槽，不服来辩。。 |
 | 11 anteros 2017-12-12 13:11:26 +08:00 2 让他解释下这段代码的逻辑，从他所说的逻辑中提问，比如问“这段逻辑中会不会出现某种情况，如果出现了某种情况的话怎么处理” |
 | 12 Phariel 2017-12-12 13:23:16 +08:00 有什么问题直说无妨 大家都是成年人 |
 | 13 discrete 2017-12-12 13:26:35 +08:00 项目里用 Git 的话用 Codacy 一类的自动检查代码质量，「重复定义变量」这种简单的问题还是能查出来的。这样就不用你明说了。 |
 | 14 sunny352787 2017-12-12 13:35:23 +08:00 委婉？干嘛要委婉？做的不好直说啊，少给他发工资的时候他会不会找你啊？ review 的时候直接说你这里写的不对，我这边的小崽子们我要求换行都要按我说的来，否则不允许上传，“委婉”这玩意太影响效率了。 |
 | 15 Gonejack 2017-12-12 13:35:47 +08:00 via iPhone 要有很明确的点，不要简单说这里不好却又没有好的理由。 要尝试做正确示范，不然很容易站着说话不腰疼或者没留意到别人踩的坑。 |
 | 16 Lothar 2017-12-12 13:38:25 +08:00 1 用 Github / Gitlab 之类的话，直接在合分支的 PR / MR 里加 Code Review 评论嘛～ 没啥需要委婉的，程序员之间代码上的事情，直接开喷就行。 |
 | 17 qq976739120 2017-12-12 13:41:08 +08:00 2 有你这样的老大真幸福 |
 | 18 Anshi 2017-12-12 13:55:55 +08:00 我希望我老大直说；（有你这样的老大真幸福，还招人吗） |
 | 19 akagi 2017-12-12 13:57:11 +08:00 编译级别错误 > 自动化检查 > Code Review > 正面一对一 变量名不规范通常是经验和能力范畴，我自己也还有点儿这个毛病。重点是看到本质原因，并且给出解决方案；如果做不到，对事不对人、语气轻一些，一般也是会感谢指出的人的。 |
| 20 Anshi 2017-12-12 13:59:20 +08:00 比如效率低，但是因为模块涉及到的数据量很小，所以不仔细看代码的话，发现不了 比如重复定义变量，方法变量名不规范等等 以上这些是我初入职场完全不在意的问题，我觉得就我自己写，自己看，就自己知道就好了。虽然我知道这么写不对，但是懒得改了。这种心态。会这么估计我不不爱写这份代码，这份业务。 ...后来用了相关规范工具，类似的错误会标黄色，或者红色，波浪线等等...我受不了。。就改了。。。 |
 | 21 zhouquanbest 2017-12-12 14:00:17 +08:00 via Android 5 我一般很直白，直接拉过来问: 傻，你这写的什么玩意 |
 | 22 openSUSE 2017-12-12 14:00:47 +08:00 搞事的话，#1 @T110E5 的做法可取。 直接说，别绕弯子，绕弯子容易产生误解。 Q：“如效率低，但是因为模块涉及到的数据量很小，所以不仔细看代码的话，发现不了” A：直接说要改，效率要提高 balabala …… Q：“比如重复定义变量，方法变量名不规范等等” A：让他们把开发规范文档再细看一遍。 Q：“就是这些我感觉，跟“工作能力”没有太大的关系，而是跟“工作是否用心”有关系的事，怎么去讲，能让对方比较好接受一些，并且知道以后类似的这些东西需要“用点心”去写，而不是单纯的“实现业务”就可以了？” A：方便告诉我贵司的地址吗？你的团队缺人不，我能加入吗？我能帮你传达心声。 |
 | 23 Catyuki 2017-12-12 14:00:48 +08:00 ....好吧 或许我改检讨..每次低级问题都压不住火气直接喷了 如果是重大问题反而耐心去沟通解决 |
 | 24 sbw 2017-12-12 14:01:08 +08:00 review 里直接回复 很多开源项目贡献代码的时候对格式、命名还有 commit msg 都有很高要求的 经常因为一个空格，一个大小写就扣分 |
 | 25 iFlicker 2017-12-12 14:04:49 +08:00 为什么不直接说呢。。 |
 | 26 Felldeadbird 2017-12-12 14:15:01 +08:00 1 有什么好委婉的。直接说出来： 小李啊，你这段代码写得不够优雅啊。你这样的话，没有抽象出来，后面维护的人会难写接口的。你改一下。 |
 | 27 fasling 2017-12-12 14:17:17 +08:00 代码上的事情直接说，没什么委婉不委婉的。 |
 | 28 zhoucan007 2017-12-12 14:18:46 +08:00 之前当过老师，有一个活动叫评课，跟程序员的 Code Review 很像啦。我们评价一个人是有套路的，如果有什么缺陷，会这么说：XX 的这个做的非常的好，那个做的也非常的好，如果在 XXXXXXX 方面稍微加强一下，那就太完美了。 自己体会。 |
 | 29 forestyuan 2017-12-12 14:20:13 +08:00 “比如效率低，但是因为模块涉及到的数据量很小，所以不仔细看代码的话，发现不了” 既然数据量很小，效率低点怕什么？貌似楼主有点吹毛求疵了 |
 | 30 linuxchild 2017-12-12 14:26:30 +08:00 直接说就好，是我我不会介意的 |
 | 31 chuhemiao 2017-12-12 14:30:11 +08:00 有这样的老大何愁不进步，还招人吗 |
 | 32 hitmanx 2017-12-12 14:30:50 +08:00 增加个 code review 的环节，有啥问题大家就直说咯，对事不对人。其实团队的代码要求提高了，对于团队中的每个人来说都是有帮助的。 |
 | 33 algery 2017-12-12 14:32:17 +08:00 我们是直接怼的 哈哈哈 |
 | 34 DiverRD 2017-12-12 14:37:38 +08:00 我多希望我们老大会跟我说，你这块代码不够好 ，应该这样写。balabala....... |
 | 35 nekoyaki 2017-12-12 14:41:49 +08:00 说一个情况，我不知道贵司有没有绩效考核或者每天汇报之类的，如果有的话，可能也会阻止员工对代码的追求。 像我在小公司的时候，每天什么时候发现代码里有不合理的地方都会试图进行优化甚至重构，但在大公司这个自我改良动力就明显减弱了，因为其中许多都没法算到我的绩效里，也影响每天的汇报。 |
 | 36 xomix 2017-12-12 14:42:52 +08:00 3 某一个模块，业务是实现了的，但是有的地方不是很完美 模块需求文档里面怎么写的？有什么标准为完美吗？你一开始不说的话都指望自觉又希望大家越快越好，大家把握不住这个度出现什么不完美都正常。 比如效率低，但是因为模块涉及到的数据量很小，所以不仔细看代码的话，发现不了 没有效率需求，又是小数据量，低效率快速开发是一种解决方案。 比如重复定义变量，方法变量名不规范等等 这是一个编程习惯，你需要从需求上就说清楚。 就是这些我感觉，跟“工作能力”没有太大的关系，而是跟“工作是否用心”有关系的事，怎么去讲，能让对方比较好接受一些，并且知道以后类似的这些东西需要“用点心”去写，而不是单纯的“实现业务”就可以了？ 那你布置业务的时候怎么不会“用点心”的布置下去，让同事更清楚你的需求。 一到公司给一个模块让你随便写，写完了再这儿那儿的毛病一挑，这是立威吗？ |
 | 37 wangdu2012 2017-12-12 14:44:43 +08:00 via iPhone 不需要委婉直接说 |
 | 38 raslan 2017-12-12 14:44:47 +08:00 我想要个这个的老大.jpg 。毕业刚加入的公司老大没啥经验，他都不重视这个，很想在自己的团队加入 code review。 |
 | 39 saulshao 2017-12-12 14:56:59 +08:00 我觉得首先要表扬人家做的好的方面，然后再指出不足,如果只是小的问题,其实作为 leader，大可不管。 如果 leader 觉得严重影响了产品 /代码质量,那就不是小的问题 |
 | 40 Khlieb 2017-12-12 14:59:59 +08:00 via Android 大家一块 debug |
 | 41 zenxds 2017-12-12 15:17:46 +08:00 code review 直接说 |
 | 42 Moorj 2017-12-12 15:33:17 +08:00 不需要委婉+1 我之前给我的女售后和女运营讲解一些要点的时候，得跪着说，不然她总以为我找茬，是故意欺负她 “是是是，你说的对，你是领导，都听你的” 就很气 |
 | 43 sm0king 2017-12-12 15:45:41 +08:00 有什么委婉的，直接说呀 |
 | 44 mengzhuo 2017-12-12 15:46:48 +08:00 直接说，或者 review 的时候说 |
 | 45 Mikey 2017-12-12 15:53:35 +08:00 委婉？那还是 leader ？ |
 | 46 rrubick 2017-12-12 16:03:30 +08:00 我的主管会直接给我指明，我觉得挺好，能学到东西 |
 | 47 wingoo 2017-12-12 16:06:01 +08:00 都是直接说的 一般会在 merge 的时候看下 |
 | 49 loryyang 2017-12-12 16:32:23 +08:00 看到直说，对事不对人呀。你既然是 leader，本身就有这个权力和义务来协助提升小弟的能力 你如果不说，就是你的失职了 |
 | 50 fengwei23 2017-12-12 16:36:52 +08:00 直说比较好，或者进行 code review，我是希望老大说出来的 |
 | 51 chztv 2017-12-12 16:41:07 +08:00 作为 leader，不需要委婉，这是你的义务。 |
 | 52 uleh 2017-12-12 16:42:41 +08:00 这还需要“委婉”么。。 熟一点的一般会说：这什么玩意儿，重写！ 不太熟的会说：这里有 xx 问题，你改下 |
 | 53 hustlike 2017-12-12 16:55:20 +08:00 pull request 可以加 comments |
 | 54 13036101641 2017-12-12 16:55:49 +08:00 有可能你不说，他不知道，现在说了，以后他做 TL 了，恰好遇见一个这样子的下属，他也会再去教下去 |
 | 55 GuangTsang 2017-12-12 17:04:41 +08:00 带着你的解决方案去和他谈，用事实证明你的观点，你的方案比他的更有效率 |
 | 56 sunsmooth 2017-12-12 17:13:52 +08:00 要让他能感觉到你是在帮他，而不是故意在找茬。 |
 | 57 codermagefox 2017-12-12 17:17:21 +08:00 哇,楼主,我巴不得被带我的大佬喷. 被喷,说明有进步的空间,说明代码确实烂. 只要不涉及父母,人身攻击都没问题啊(没错我就是抖 M 事实上被喷了以后确实长记性快. |
 | 58 nickel123666 2017-12-12 17:24:20 +08:00 居然还要委婉，我的 leader 在指点我代码的时候都是说“你也好意思写这种代码哦”； “这里！怎么办吧，要不要改？” “为什么这里 xxxx ”； 哇，感觉被骂得好爽。。 |
 | 59 xxbutoo 2017-12-12 17:27:13 +08:00 真为了你的小弟好 直接喷他 最好周围没人的时候 |
 | 60 sensui7 2017-12-12 17:29:42 +08:00 直接讲哪里可以有问题 |
 | 61 Damon4V 2017-12-12 17:32:31 +08:00 还招人吗？遇到这样的老大真得是幸福啊 |
 | 62 wupher 2017-12-12 17:43:31 +08:00 不懂，我一般就是直说，也建议直说。 code style 的话，最好设立规范，然后用自动代码检查。 如果是算法不合理，没考虑到当数据很大会有较大耗时或性能消耗。这就是与工作能力相关了。一般来说，能提供职业技术能力的建议，程序员一般还是会乐于接受的。（来不来得及马上改可能存在排期问题） 如果确实是态度不好，那应该反省一下招聘了。招聘和试用阶段为什么没有发现这种情况。 如果是 N 年老员工，可能就要看看彼此利益干系，实在不行就只能曲线处理，关键任务不交给他。 |
 | 63 cosmosz 2017-12-12 17:44:23 +08:00 把 coding standard 弄出来，按照 coding standard 改变量名。 对效率的要求在 non-functional requirement 中提出来。 如果这些都有，但还是“没用心”，就直接当面说；如果这些没有，就是团队管理的问题。 |
 | 64 Katherina 2017-12-12 17:47:47 +08:00 希望老大直接说，只要说的中肯有帮助 命名规则、代码规范什么的最好有一个文档的吧～如果哪里逻辑复杂又没加注释、或者命名让人根本看不出这个是干嘛的，后面的人维护起来也很头疼，肯定要点出来的。而且这都属于习惯的问题，没什么接受不了 如果是具体到逻辑、效率上的，我还要感谢老大帮我上了一课好嘛～ 当然有些模块划分或者功能实现上我和老大有点各持己见，偶尔会有争论，其实最后还是学习到了 |
 | 65 dozeboy 2017-12-12 17:49:20 +08:00 如果你是我老大，我希望能直接跟我说，没必要顾及太多，虽然有可能尴尬，但我更希望得到提高 |
 | 66 Takahashi 2017-12-12 17:49:34 +08:00 想要有这样的老大 |
 | 67 vagranth 2017-12-12 17:51:23 +08:00 别人我不知道，反正如果人家指出我的代码里有问题，我一般都是先听明白，再确认。 如果真的有问题我还感觉蛮高兴的，因为这样下次就不会再犯了。 |
 | 68 yuhr123 2017-12-12 18:04:51 +08:00 私底下明说就是了，目的是为了让程序更好，如果连优化建议都听不进去这人心胸就太小了。太委婉反倒耽误事。 |
 | 69 fhefh 2017-12-12 18:23:10 +08:00 我希望老大直接跟我说 这样我自己也会提升 |
| 71 akagi 2017-12-12 18:39:24 +08:00 @fhefh 路过，这个貌似要看写啥，C++有 cppcheck, js 有 eslint, 用 lint 做关键字一般可以搜到些~ |
 | 73 m999 2017-12-12 19:26:53 +08:00 via Android 下属身体很壮么 |
 | 74 vdvvdd 2017-12-12 19:33:26 +08:00 这还需要委婉 |
 | 75 forkon 2017-12-12 19:44:09 +08:00 楼主怎么定义委婉……有内情？ |
 | 76 scratbai 2017-12-12 19:44:37 +08:00 只是个代码问题，我跟我老板说，都不用特别注意的。 |
 | 77 srx1982 2017-12-12 19:57:15 +08:00 为什么要委婉，直接说啊 |
 | 78 sampeng 2017-12-12 20:13:06 +08:00 亲，你这坨代码写的真好，就是有那么一丢丢的问题。 楼主是要这样么。。。 毛线啊，leader 的职责就是支出代码问题啊。。 |
| 79 sampeng 2017-12-12 20:17:55 +08:00 其实吧，都说直接说好。但是真轮到自己头上指不定怎么炸毛呢。。 lz 这个话题，我也经常碰到来着，但是我看着不爽还不让我提，你来当 leader 啊。。。 |
 | 80 cchange 2017-12-12 20:35:44 +08:00 via iPhone 记得 SVN 的时候 貌似有个 SVN blamed 不过我没用过 SVN 所以…… |
 | 81 wdlth 2017-12-12 21:35:47 +08:00 你们不规定编码规范，不用静态分析么？ |
 | 82 l00t 2017-12-12 22:04:50 +08:00 有需求，或者有要求，你提前说。写完再唧唧歪歪的还没个实锤，就算是领导，底下人也未必服的。编程上很多问题不过是个意见分歧和个人偏好而已。当然如果你三番五次强调过了对方还是再犯，那确实是工作态度有问题。 |
 | 83 RaymondYip 2017-12-12 23:43:19 +08:00 之前说过几次指出来都以为我在骂人，，后面不说了 直接自己看到顺手就改掉舒服多了，就是自己累点 |
 | 84 romisanic 2017-12-13 00:30:58 +08:00 为什么要委婉？ 没有由头的话，现在设立一个规则或者要求，让大家遵循，说明的时候就拿这部分代码举例子。 有问题说出来才好进步。 说了不改，那就该换人了。。。 |
 | 85 takato 2017-12-13 00:45:28 +08:00 完全可以找一份和他问题相似的代码，找个非正规场合单独给他看看，不要指出问题。这时候如果对方够聪明，应该能够自己发现一些问题。 如果对方没意识到再考虑评审时候说吧。 个人意见 |
 | 86 jsfaint 2017-12-13 07:38:21 +08:00 via Android 大家都在说楼主委婉的问题，我换个思路 如果代码风格问题，用 lint 工具扫了让他改或者参考团队代码风格 如果是性能问题，不上 profiling 就说有性能问题，这样不严谨啊 |
 | 87 missdeer 2017-12-13 08:37:01 +08:00 你是老大你说了算，委婉干什么 一劳永逸的方法是制订编码规范，落实 code review |
 | 89 ii4Rookie 2017-12-13 09:52:14 +08:00 @zhouquanbest 哥，不是你教我这样写的吗？ |
 | 90 zjddp 2017-12-13 10:08:34 +08:00 渴望有这样的老大 |
 | 91 zhangfeiwudi 2017-12-13 10:23:30 +08:00 直接就说了，不用委婉啊 |
 | 92 8355 2017-12-13 10:25:36 +08:00 我觉得先看看是能力不够还是能力够随意乱写 如果能力不够虚心接受那你多教教 诚心乱写就骂人啊.. |
 | 93 skylancer 2017-12-13 10:26:41 +08:00 组织一场 code review 不是最好的办法么..？ |
 | 94 scnace 2017-12-13 10:30:40 +08:00 via Android 那么反过来呢 要怎么委婉地说( |
 | 95 hundred 2017-12-13 10:36:38 +08:00 有什么好委婉的，发工资的时候委婉发了 8 折么 |
 | 96 myself659 2017-12-13 10:46:41 +08:00 代码规范有的话，直接上规范 没有的话通过代码 review 论对错与优劣 |
 | 98 meathill 2017-12-13 11:08:04 +08:00 不用委婉，直说即可。 代码规范用 lint 工具，必须通过才能提交。 定期组织 Code Review，新人的代码必须 Code Review 才能合并到 master。 |
 | 99 kkzxak47 2017-12-13 11:10:23 +08:00 via Android 直接叫过来指出来啊 |
 | 100 m939594960 2017-12-13 11:22:26 +08:00 我现在特想问一个问题,我作为员工,怎么指出 leader 的代码有一些小问题呢 |
Select Language