这是一个创建于 2058 天前的主题，其中的信息可能已经有所发展或是发生改变。
实在看不下去了，思维毫无逻辑想到哪写到哪，代码不格式化，变量命名大小写毫无规则，model controller 混着写，各种不规范的方式导致整个代码质量降低很多经常出一些奇怪的 bug，但是碍于面子没有出 bug 的地方又不好意思改动别人写的代码。 大家有什么方法应对这种问题吗？
第 1 条附言 2020-02-27 11:23:36 +08:00
谢谢大家的建议，其实我是外包接的一个项目，组员是另外一个接包的自由职业者，所以还没拿到钱之前既无法直接走人又不太好建议别人怎样规范，看来还是要尽快赶完这个项目后期不再参与比较好。
以前挺反感 code review 的，现在觉得真的是有必要
以前挺反感 code review 的，现在觉得真的是有必要
 | 1 uxstone 2020-02-27 09:02:34 +08:00 跳槽离职 |
 | 2 whileFalse 2020-02-27 09:03:38 +08:00 via iPhone 一般而言我推荐团队新人的代码风格应和现有代码相符。 你也这么写吖 |
 | 3 kiritoxf 2020-02-27 09:11:27 +08:00 正常应该有人 review 的 |
 | 4 xianxiaobo 2020-02-27 09:15:37 +08:00 直接告诉他，让他注意点就行了 |
 | 5 FindByMe 2020-02-27 09:26:25 +08:00 via iPhone  3 制定代码风格规范、配置静态检查工具、有不符合规范的代码、直接抛 error |
 | 6 danyi 2020-02-27 09:30:46 +08:00 7 没遇到过这样的组员，不过我同事遇到过，看样子他们挺想打我的。 |
 | 7 coderluan 2020-02-27 09:43:56 +08:00 你是负责人就制定代码规范和进行 code review，你不是负责人就建议负责人这么做。负责人明确拒绝建议离职，不懂代码质量重要性的人基本也没啥技术水平。负责人认可但是因实际情况难以推行，比如工期太紧张，这种就没啥好办法了，只能尽量明确职责，分配好模块，让自己尽量不去看别人代码，不负责别人的 bug。 |
 | 8 minglanyu 2020-02-27 09:45:14 +08:00 1 1.以身作则 2.成为他们的 leader 3.code review |
 | 9 tt67wq 2020-02-27 09:47:11 +08:00 code review 不给通过 |
 | 10 itskingname 2020-02-27 10:15:14 +08:00 依靠文档不如依靠代码。用文档或者 txt 规范来约束人是没有效果的。 举个例子，例如 Python 项目，你多次强调写代码要遵守 PEP8 规范，可就是有人不遵守。怎么办？在 git 上面加个流程，必需 Pylint 扫描无报错，无警报了才能 merge 代码。这样就能迫使对方必需遵守。 |
 | 11 sagaxu 2020-02-27 10:16:52 +08:00 via Android 跳槽到好 team，让你自己成为被嫌弃的那个 |
 | 12 carpediem777 2020-02-27 10:17:52 +08:00 其他组员也许也有跟你一样的想法 |
 | 13 hoyixi 2020-02-27 10:20:56 +08:00 团队没有代码规范吗？ 试用期是干嘛用的？ 管理人员是干嘛吃的，正事不管，在管啥？ 哈哈 |
 | 14 |
 | 15 nmap 2020-02-27 10:54:55 +08:00 严格模块级隔离，出了问题可追溯，就跟你没啥关系 |
 | 16 Smash 2020-02-27 11:21:08 +08:00 代码提交要先规范检查，检查不通过不会让合入的，规范后的代码，我都能忍。不然就六字真言。 |
 | 17 shm7 2020-02-27 11:27:53 +08:00 via iPhone 向甲方提这些事情 |
 | 18 learnshare 2020-02-27 11:32:24 +08:00 接手的项目，该扛起来就扛起来。代码规范还是要有的 我接手的项目没办法下手写代码，就完全换了 lint 规则，处理了几百个文件、几千处问题 不过逻辑、模块划分啥的还是没有办法 |
 | 19 gowa 2020-02-27 11:33:18 +08:00 via Android 你当 reviewer，代码打回去。 |
 | 20 enlight OP @learnshare 说的很对，我这边代码已经完全不是 lint 能解决的了，逻辑思维感觉很混乱。我本来搭好了一个架子，model controller services 划分得非常清晰。结果对方直接把 model 写到 services 里去了，怎么省事怎么来。而甲方只看能不能跑通和开发速度不管代码质量，本来还是因为我一个人开发速度不够才又找了个人，所以我也很为难 |
 | 21 jinsongzhao 2020-02-27 11:41:42 +08:00 @danyi 你可以的，原来你就是那位组员！ 23333 |
| 23 jinsongzhao 2020-02-27 11:51:17 +08:00 因为代码即文档是最省力的开发模式，所以给他提供代码风格手册，好的风格大家都乐意接受，毕竟本人也要阅读，已经存在的代码重构它，也可以继续提升质量；本人不在了，那终归无法完美，只能改善，想想 github 上好项目的代码风格各式各样，而且不同语言风格混合开发也常见，读别人的代码提升自己也是必经之路。 |
 | 24 charlie21 2020-02-27 12:03:33 +08:00 via iPhone 重写给他看，供他学习。求他 |
 | 25 blessyou 2020-02-27 12:21:57 +08:00 via Android 当着他的面重写 |
 | 26 wm5d8b 2020-02-27 12:49:17 +08:00 设计上解耦合，确保每一部分都能重构 |
 | 28 sampeng 2020-02-27 12:54:31 +08:00 via iPhone 外包项目跑起来就是赢啊 |
 | 29 ianva 2020-02-27 14:41:31 +08:00 没有 code review 的机制，都是空谈 |
 | 31 mikulch 2020-02-27 16:21:34 +08:00 可能你没看过我这个代码。if 可以嵌套 5，6 层。一个方法几百行。 最牛逼的是写这个代码的人从我们公司走后竟然去了京东了。 |
 | 32 yilingersier 2020-02-28 03:23:27 +08:00 (又不是不能用。。手动狗头 |
Select Language