请教一些关于代码规范和 code review 的问题

[BugNotExist]

项目组新插进来一个同事，本来是打算安排他写实际业务的。新同事刚进来就开始改项目配置，加上各种代码规范。后来新同事和产品老大关系搞得很好，产品老大就打算安排新同事管前端技术。新同事就搞了一个技术专讲会，就说分支名应该加上自己的名字什么什么的，例如 hotfix/name/实际业务。还有点击事件应该用 on 开头，目前项目里用的 handle ，新同事不太认同。这新同事一直说别人写的组件很不好，要像他的那种组件的写法，给我们展示了他的代码。

关于分支名，我感觉没必要再加上自己的名字了吧，提交的时候不就有作者么，还有那个点击事件要用 onXXX ，这个是属于规范必要性么？我感觉项目里只要统一风格就好了吧？

现在有个实际需求开发，但是我只是按照文档写了，还没测试，相当于还没做完。他非要让我先提 MR ，让他 code review ，我都没做完，我不太认同这种 MR 。

[4ark]

1. 只看前面这个人挺不错的，起码我愿意和这样的人一起工作。
2. 但看到他对分支名和事件名的坚持，感觉他有点过于自信。可能这只是他上一份工作团队里的规范，没有好坏之分，只是看是否适合现在的团队。
3. 总体来说，他的出发点是好的，但方式太激进、有些幼稚，显得有点教条主义。

每个团队都有适合自己的规范，不可能完全照搬以前的经验。不过话说回来，你们团队里没有技术大佬吗？一个新来的普通同事居然能主导这些事？

[pixcai]

你们之前都统一采用 handle 作为事件函数前缀，这个是没毛病的。同样，Git 提交统一用 feat 、fix 、doc 也没毛病。你这个问题不算是项目的问题，是人的问题。

首先，项目有代码规范是好事，新同事有意愿增加好的规范也是好事。因为我也有代码洁癖，我如果在 React 项目中用了 onClick ，那所有的地方我都要 onDownload 、onClose 这种，绝不会用 handleClick ，否则我心里就不舒服。但我不会把这种习惯带到工作中，工作中是要合作、要效率、要妥协的。技术在其中的作用一定是锦上添花，而不是追求极致。

目前来看这个新同事和我很像，他的技术眼界可能很开阔，技术能力可能也很好。但他太“技术”了，这种人其实不太适合管项目。你的质疑是对的。我只能说你们的老大可能没有意识到：以新同事的性格和能力，更适合做技术攻坚或基础架构方面的工作，而不是听从他的想法去改变现有的流程，在任何项目中途打破团队默契都是很危险的做法。

[pixcai]

你现在的场景我之前也遇到过，我当时想的是：如果哪天我当老大，我在做决策的时候，一定要多了解底下人的想法，不要拍脑袋决定。然而，世界真的就是一个草台班子，我待了几家公司发现，领导眼里底下人真就是一个“臭打工的”，没必要跟你商量。

[BiChengfei]

产品老大能安排技术团队？

[connection]

赞同 #2 的看法

[IvanLi127]

我只想知道改代码风格这事，安排多少工期？不会不给排吧🤔

看起来这个新同事适应性不太好的样子，能留下来的话要么职级高，要么关系硬，建议从了他。他的要求不算太离谱，就是有点没事找事，能给充足的时间的话换换口味也不错。

[tonytonychopper]

这个问题在于，他给你们提出的规范没有在你门团队内部经过充分的讨论

[tyrantZhao]

从描述看，没有太大问题，你们产品老大能管技术团队，说明你们技术团队没有人，或者说没有顶事的人，你们这个新来的人权利很大。

[wq1997]

看情况，1. 他代码质量确实好，但是目前项目流程不规范，带来的问题很多
2. 技术不行，只是会搞关系会表现，所以做一些和业务无关，但是容易表现的
我觉得可能招人进来的时候，就准备这样安排，逐步试探罢了

[nbhaohao]

其他几点楼上几位都说了. 一些想法关于楼主最后一个问题: 我之前参与过项目, 当时的要求是开始写功能的时候, 就把 PR 开出来, 这样的话, 其他同事无意中看到, 可以顺便看下一些规范, 以及提早发现一些风险 (相比于把大量代码攒在本地, 而没有公开出来).
也许这位新同事, 担心楼主这次的功能, 有些风格, 方案思路不符合他的预期? 怕晚发出来, 到时候 review 要改太多, 影响交付.

我也赞同楼上几位的说法, 这位新同事似乎招进来, 职级很高, 直接接管项目规范/配置, 一般来说这都是项目技术负责人, 或者在小组中公认的技术比较好的人所负责的事情.

[rocmax]

前端开发的各种代码规范工具链很成熟，采用一套较好的规则很有必要，但是这些规范大多是以避免 bug 为目标。命名规范我认为统一一下驼峰还是下划线啥的就够了，僵硬到必须用 on 不能用 handle 这个程度有点过，让强迫症管项目会闹矛盾的。

[www5070504]

有规范就比没规范好 但是这个人我不喜欢 感觉有点装 x 没写完的东西要求别人提鸡毛 MR 自己不会看提交吗

[RealJacob]

1. 分支名这个事儿感觉意义不是特别大。能明确分支类型即可。
2. handle 和 onXXX ，我感觉后者好，但是这个东西也不应该作为强制。更像是组里讨论出后得到的结论，潜移默化的让大家知道更好更清晰的方式。
3. 提 mr 这个没问题吧，开发完毕提测之前提 mr ，提了 mr 是给人 cr 的，可以评论并且可以看到你后续的改动。当然 cr 这件事我认为是建立在非常良好的开发节奏上才成立，如果各个需求都很紧急，其实没有什么 cr 的意义。不如测完上线再提。其实很多大公司里 cr 都执行的并不好

[BugNotExist]

新来的人得来的权力只是产品老大口头承诺的，他之前是在组件库负责的，结果被投诉了，产品老大就把他弄到我们这边了。事实上对我影响并没有很大，我可能马上就要去做其他项目，不用面对这个新同事了。很多人都投诉了这个新同事了，他给大家增加了不少的工作量。其实代码规范很好，但我觉得在项目中期加这个是有问题的。

[lqm]

我喜欢 handleXXXX

[wusheng0]

代码规范确实很重要。

个人风格部分一般不会干预，不会造成理解困难就行。

[nikenidage1]

其他还好，分支加自己名字这个确实没必要

[horizon]

「产品老大就打算安排新同事管前端技术」
怎么会有这种事？

[BugNotExist]

@horizon 我也不清楚为什么会这样，我才进去不久。

[BugNotExist]

这同事真的气人，马上要走了，还要改我之前已经通过测试的那部分代码，需求文档都不看，就开始大刀阔斧的重构，他拍拍屁股走人了，到时候还得我擦屁股。