提供一点不一样的看法
※ 引述《leo5916267 (封膜猎人)》之铭言：
: 也许在软件也蛮容易遇到类似个性的同事
: 我们是新创公司，我进去前已就有一个前端工程师，他从0建构了整个产品A
代表他能力不算差
而且产品A有很多他习惯的practice
: 我是产品B的前端，刚好我们产品线不急，被拉去支援他们 改版
: 但在合作上就觉得跟他相处很不舒服
: 可能是把我当竞争对手吧？
: 喜欢用高姿态/批判的方式codereview,
有些人讲话是比较机歪
但review comment只要不是“这边写得好烂”这种垃圾话
应该都还是有点价值
然后个人认知中的code review
最主要的目的，是要让你的code能符合既有的style
细到变量命名，粗到目录结构、pattern的运用
有没有重造轮子，还是有既有的utility function可以用但你不知道？
很多工程师（包含小弟我XD
都会有自己的写法最屌的错觉
对于没看过或不熟悉的做法总是看不顺眼
code review就是在确保
一个repo在多人维护下也能有一定程度的一致性
而不是每次都要在review过程中讨论出一个很猛的写法或架构
: 而我对他提出写法的意见，才提开头一句
: 就霹雳啪拉回了十句，顺带挑我程式毛病，我觉得更像是用公事来打压别人
想像一下，你从0开始写出了整个专案
一个新来的工程师，不了解既有的convention，上来就想照自己的方式写
你会不会觉得奇怪？
: 就讲不得，而整个团队都对他很头痛，但又要依赖他做事情，很多文件需求都没写清楚，很多事情都绑在他身上，而且专案架构维护性蛮差的，我看了整整一个月才懂他的思路，大概就是小孩子拿AK的感觉
脾气不好，但又依赖他做事，就更代表他确实能力不错
文件需求不清楚是小公司满常见的，而且需求应该是PM负责吧怎么会是工程师来写需求？
: 我们做事不得不都要照的他的方式做事，但他又很自我中心，跟他配合心力大概4成是处理情绪问题4成才是程式问题
由他建立起的专案，按照他的方法做事，应该没什么问题
因为你也是短期支援而已，要是被你一通乱改改到他看不懂
后面要收拾的也不是你
: 我网络上找过类似的关键字
: 攻击性强的同事
: 自以为是的同事
: 他的性格满符合上面相关搜寻找到的描述
: 不知道各位前辈是怎么应对的
: 我现在是当练EQ，大概还要半年改版完忍忍
这段都是个人心情的部分，就不多做评论
: 程式部分就消极应对，我有好的想法就跟别人讨论，在他的专案只用他写过的方式做
有好的想法，也要看专案性质跟时程
不一定你在A专案的好做法，到B专案也适用
尤其前端又是生态系很乱的一个环境
光React管理CSS的做法，就有三种以上知名的solution
每过一两年都会看到“原本那套过时了，现在应该要用这个啦”的说法
如果你想套新的作法，当然就是要跟身为原作者的他讨论
很多情况都是一段你看起来很粪的code
但前人已经想过几种可能的优化方法，只是受限于某些条件无法这样做
或是大家判断这边再改动的可能性很低，干脆就先放著能动就好
因为没有实例，所以我也无法给你太具体的建议
不过如果想做refactor的话，最好还是要有条理的整理出
旧做法哪里不好，新做法哪里好
是改善了效能、改善可读性、改善扩充性，还是什么呢？
如果你真的对自己的做法很有信心
也可以直接做个prototype后PR就丢出来
把重要的人全部拉进去当reviewer
要是多数人认同你的做法，只有他在PR里面乱喷
就算最后没办法merge，那也是帮助你在公司建立credit
他则是在败自己的人品
那也许有一天专案出事，主管就会想到要找你去救
到时候自然是你想怎么写就怎么写