"老王，你这代码写得也太烂了吧？" "啥？我这代码怎么了？" "你这变量命名，这代码结构，这是人能看懂的吗？" "我寻思挺好啊，能跑就行呗..." "能跑就行？！后面谁维护你知道吗？"
场面一度很尴尬。
代码评审现场翻车，相信不少同学都经历过。但更多时候，我们的反应是：
- 默默点个"收到"，然后继续摸鱼
- 心里暗骂对方太较真，但嘴上说"好的我改"
- 改完立马找产品理论："这需求本来就不合理！"
- 在工作群怼不过，转手就把对方拉黑
说实话，谁不是从怂包子开始的呢？我自己刚工作那会儿，那叫一个怂。产品经理改需求，默默接受；测试提bug，默默修改；leader说要加班，默默加班...直到有一天，我实在忍不住了。
从小到大，我们都被教育要"和为贵"。打小学起：
- "要和同学好好相处啊"
- "忍一忍就没事了"
- "吃亏是福" 这些话听得耳朵都起茧子了。
到了职场，这种思维更甚：
- "大家都是同事嘛"
- "和气生财"
- "多一事不如少一事"
结果呢？憋出一堆职场"老好人"。
这个真不能怪我们怂，实在是：
- 得罪测试，你的bug就别想过了
- 得罪产品，下次需求改到你怀疑人生
- 得罪leader，你的绩效就悬了
- 得罪同事，代码评审能挑毛病挑到天亮
更要命的是，现在都讲究"团队协作"。得罪一个，可能得罪一群。谁还不想混口饭吃了？
说实话，很多时候我们不敢怼，是因为：
- 代码写得确实不够好
- 技术深度确实不够
- 方案确实有漏洞
- 经验确实不足
就很尴尬，明明知道对方说的不全对，但又说不出所以然来。
- 今天妥协用了个烂方案
- 明天将就写了个烂代码
- 后天将就改了个烂需求 最后？整个项目烂得像坨浆糊。
我之前就遇到过，一个"临时方案"用了两年，最后重构的时候，连碰都不敢碰，生怕整个系统崩溃。
- 测试说有bug，默默改
- 产品说要改需求，默默改
- 运营说要加功能，默默改
- 领导说要优化，默默改
结果呢？但凡出点问题： "这块代码是谁改的？" "哦，是小王啊，每次都是他改的..."
久而久之：
- 技术讨论不敢发言
- 方案评审不敢反对
- 有想法也不敢说
- 有建议也憋着
最后在团队里混成了隐形人，存在感只剩下每天打卡。
就像写代码一样：
- 不同的人有不同的代码风格
- 不同的团队有不同的技术栈
- 不同的项目有不同的要求
有分歧很正常，没分歧才不正常。
- 代码评审被怼，是提高代码质量的机会
- 方案被质疑，是完善设计的机会
- 观点不一致，是思维碰撞的机会
- 需求有分歧，是深入理解业务的机会
说白了，底气不足就是因为实力不足。
要学会：
- 写代码先想想为什么要这么写
- 接需求先想想有什么坑
- 做方案先调研同行都怎么做
- 有空多看看源码，别光是CRUD
以前我的表达方式： "这个...可能...会不会有问题..."
现在的表达方式： "这个方案我觉得有三个问题：
- 性能可能会有瓶颈
- 扩展性不太好
- 维护成本会很高 我建议我们可以..."
与其对抗：
- "你这需求改得也太频繁了！"
- "你这代码写得也太烂了！"
- "你这测试也太细了！"
不如：
- "要不我们先确定核心需求？"
- "我们一起看看代码怎么优化？"
- "测试案例是不是可以优先级排序？"
职场冲突就像代码里的bug：
- 遇到很正常
- 解决很重要
- 回避不可取
- 处理要及时
重要的不是避免冲突，而是学会处理冲突。
记住：
- 把话说出来总比憋在心里强
- 把问题摆在台面上总比暗地里较劲强
- 把分歧当面讨论总比背后吐槽强