本来以为成员都会默认按照原来代码的规范来写代码，但是后来发现是我想的太简单了。有人使用驼峰动词+名词结合的方式，有人使用名词的方式。git 有人使用中文，有人使用中文拼音。和他们说这个问题后，人家来了一句：我以前就是这样写代码的，没有啥问题。背后还说：这家伙老是挑我的刺
60 条回复 • 2018-04-19 10:37:54 +08:00
 |
1
loshine1992 2018 年 4 月 18 日  1
说服老大，code review，不合格扣绩效
|
 |
2
ai277014717 2018 年 4 月 18 日 1
首先明确指定出一份规范。然后 lead 要督促。
|
 |
3
hjw45611 2018 年 4 月 18 日 5
上面不重视，说啥都白搭
|
 |
4
c466934322 OP 1
我觉得是我没有说清楚情况，公司没有技术方面的大佬，一直都是我在引导技术，但是我也不懂这方面的规范，所以我没有意识到这方面的问题
|
 |
5
zj299792458 2018 年 4 月 18 日
不是 team leader 的话还是不要操这个心了……无法建立有效的监督机制，靠说服是不太可能的。
|
|
6
loshine1992 2018 年 4 月 18 日
如果大家都是同等级的，你就别操心了。
blame 的时候谁写的谁维护就行 |
 |
7
chairuosen 2018 年 4 月 18 日
git 中文拼音????
我还以为是有人用中文有人用英文呢。。。 |
 |
8
quickma 2018 年 4 月 18 日
统一规范是要求，不是说服。
|
 |
9
rrubick 2018 年 4 月 18 日 1
当领导，不用“说服”。
平级就别想了 |
 |
10
l00t 2018 年 4 月 18 日
能看懂就行，不强求。这种地方只是看着不舒服罢了，并不会有实质上的差别。
|
 |
11
fstab 2018 年 4 月 18 日 via Android
上面不重视，说多了得罪人。
我现在都不想说了，关我屁事。 做好自己就好了，别人要乱搞我也控制不了。 |
|
12
c466934322 OP @chairuosen 都有，我建议是用英文。一共有三种：中文，中文拼音，英文
@loshine1992 问题是：大多数人都是写了两天代码就跑了。留下一堆不一样的代码 @zj299792458 刚刚好的就是：我最近刚好想转型，老板也给了一个小机会，所以有说服力，但是不会说，因为要照顾他人的情绪。 主要是我没有管理方面的经验，然后我又想做这个事，所以我来这里请教各位。老板也给我了一个机会，让我去尝试着管理。当我开始管理的时候，我就发现这个问题了：规范问题。并且这个问题已经形成了，所以我更多是希望如何解决这个问题，直接了当的说，这个人会说在挑他的刺。但是不说，这个问题会越来越严重 |
 |
13
yoke123 2018 年 4 月 18 日
那我们这种 写代码命名基本都是 去谷歌翻译一下 然后复制进来的人
合格吗 "git 有人使用中文，有人使用中文拼音" 是提交信息吗 |
 |
14
qwertyiuop 2018 年 4 月 18 日
求同存异
|
 |
15
eric1202 2018 年 4 月 18 日 1
开会聊一下利弊,再吃个饭缓解关系
|
 |
16
binjoo 2018 年 4 月 18 日
要么同流，要么离职。
没有领导去牵头，平级去处理这种事情，吃力不讨好。。 很多人只是把工作内容当成任务，任务完成就行了。只要没有问题，其他的哪管得了那么多。。 |
 |
17
xianyu0 2018 年 4 月 18 日 1
从上往下推，如果领导也觉得无所谓，那还是弃坑吧。别的方式基本都无效，因为狗改不了吃屎。
|
 |
18
LeoNG 2018 年 4 月 18 日
如果上面不重视，LZ 还是别放弃吧，这就是一个吃力不讨好的事。
|
 |
19
yanjinbin 2018 年 4 月 18 日 via iPhone
@c466934322 所以你的规范都没说清楚，那你发个 mao
|
 |
20
nfer 2018 年 4 月 18 日 1
说服是不可能说服的，别说同级，就是比你低一级，规范的事情别人也不一定服你，本身就没有什么对错的事情。
我的方案是：使用 eslint 等工具来限制，不满足规范你的代码就编译运行不过。 这种方法能够让一部分认为“规范没有意义”的同事纳入到规范中。 但是对于那种有自己的“坚持”的同事，比如 tab 和空格党，这就纯属于看能力了，谁 nb 谁说了算，都不 NB 就别 BB。 |
 |
21
fengbica 2018 年 4 月 18 日
那就不合代码
|
 |
22
dikT 2018 年 4 月 18 日
python 变量都支持中文了, git commit 中文咋地了
|
 |
23
zr8657 2018 年 4 月 18 日
@c466934322 大部分情况下让管理又不给明确的权力，就是扯淡。大家都是同级谁搭理你？我吃过这样的亏，我身边也正在发生这样的事，都是泪。
|
 |
24
imnpc 2018 年 4 月 18 日 1
git 一般建议 英文+中文 如果针对国际化的项目 可以只英文
|
 |
25
whosesmile 2018 年 4 月 18 日 1
构建工程的时候加上强制的语法验证啊？？这有什么好纠结的？构建失败他还能去改构建规则不成...
|
 |
26
locktionc 2018 年 4 月 18 日 1
先说代码命名问题，例如 Python 有 pylint，可以检查变量命名方式。你用的那个语言应该也有这种东西。
再说 Git，Git 中英文我觉得问题不大。你可以做一个 Git commit 的模板，他们提交的时候可以设置自动使用这个模板。 建议上持续集成，提交代码到 Git 以后，Jenkins 自动拉取代码，自动检查代码规范，不合格不让进。 |
 |
27
NonClockworkChen 2018 年 4 月 18 日
你如果想让拼音的人写英语，这是不可能的- -
|
 |
28
Chyroc 2018 年 4 月 18 日
@whosesmile 人家不舒服真的改了怎么办，哈哈哈
|
|
29
c466934322 OP |
 |
30
goodryb 2018 年 4 月 18 日 1
首先，你要制定一个规范，最好是邀请所有组员参与讨论制定，让大家都没有异议
其次，说服老板，讲清楚好处，让规范变成制度，写进每个人的 KPI 里面 第三，建立有效的审查机制，代码 review，自动规范检查 |
 |
31
onion83 2018 年 4 月 18 日 1
最佳实践是：用技术去约束规范
每个人背景不一样，甚至对文字的理解都不一样，你的文字规范、口头劝说对别人只有指导意义，而没有强制意义。 - 代码层面：在代码提交阶段，服务器对代码做前置检查，不通过就不能提交。（ Mess Detector 了解一下） 包括且不限于：语法检查、文件编码约束、禁止 tab、函数 /方法命名检测，未使用函数、变量检查，自动化测试等 - 数据层面：分离 DAO 层，无法直连数据库，只能通过中间件、API 取数据 - 产品层面：少写代码，能自动生成尽量自动生成。高度抽象思考现有业务，能做后台做后台，通过配置驱动业务 |
|
32
c466934322 OP @goodryb
@onion83 @locktionc @whosesmile @imnpc @nfer @nfer @imnpc @nfer @xianyu0 @eric1202 @hjw45611 @loshine1992 @ai277014717 感谢各位的解惑，我想我有了解决方案，确实不能单对单说：单对单有种不一样的地方，以后还是开会讨论，然后用技术去实现讨论的结果，强行约束所有人 |
 |
33
6diyipi 2018 年 4 月 18 日
抓住每一个人打一顿，问他服不服。
|
 |
34
tomczhen 2018 年 4 月 18 日
技术上：
1. 用脚本解决习惯和偏好问题（空格，tab ） 2. CI Pipeline + lint 3. 根据实际情况添加自动检查机制 4. 根据 CI 生成业绩指标数据 管理上： 1. 明确权力 2. 干掉不听话的，如果干不掉就边缘化 其他： 做好失败之后找下家的准备 |
 |
35
woodface2233 2018 年 4 月 18 日 via iPhone
这是强制不需要说服
|
 |
36
SuperMild 2018 年 4 月 18 日
看来你们老板对管理也不是很懂，光口头上支持你没用的，要给你实权，有实权才能谈如何恩威并施，没有实权都懒得鸟你，不反过来怼你就已经很客气了。
|
 |
37
chiu 2018 年 4 月 18 日 via Android
用 svn，权限限制，这样你就看不到别人不规范的代码了
|
|
38
SuperMild 2018 年 4 月 18 日
另外，老板如果想在公司内培养管理者，一般最好放出消息，画个大饼，然后暗示明示两三个候选人，对他们表示重视，让他们去竞争，在这个过程中慢慢地对其中一人显示出偏好，让全部员工看到这个过程，这样他的威信才能建立起来。
但如果本来就有一个技术和管理都优秀的人才，就不用这么麻烦，他自己就有足够的魅力去管人。 |
 |
39
swulling 2018 年 4 月 18 日 via iPhone
|
|
40
yanjinbin 2018 年 4 月 18 日 via iPhone
管好你自己吧。。。要提高团队代码质量从招聘就可以开始了。。呵呵
|
 |
41
Felldeadbird 2018 年 4 月 18 日
楼主不是管理的话，别去理这种事情。
反之，开会要求全体执行。自己多 做代码审查。 其实，GIT PUSH 部分可以做一些自动化监测脚本，检查代码中变量，函数，类名，文件名是否按照 规范文档编写。 |
 |
42
seeker 2018 年 4 月 18 日 1
借助工具，靠自觉没用。
|
 |
43
looplj 2018 年 4 月 18 日
需要 leader 推动
|
 |
44
niubee1 2018 年 4 月 18 日 1
规范和流程都是自顶向下推进的, 你需要和 Boss 聊聊
|
 |
45
php230 2018 年 4 月 18 日
既然定了开发规范，团队成员哪有不遵守的理？
|
 |
46
vlyonline 2018 年 4 月 18 日
重构他们代码，但是你的代码要比他们的更高效，要不然就别动，忍着，我和我有代码洁癖的朋友都是这样干的，如果你做得比他们好，他们几乎不会去质疑你（ 1 是因为懒，2 是因为反正都重构了他也不想重构回来），不过你要看清楚前提，你的代码更高效、优雅！做不到就先忍着，因为你大佬都没意见你就别说话了，因为再怎么说我们都要尊重领导。
|
 |
47
hasbug 2018 年 4 月 18 日
不列入代码考核 别想了。
平时工作有傻逼遇到 svn 冲突都直接覆盖了呢，这活没法干了 |
 |
48
icegreen 2018 年 4 月 18 日
阿里代码检查插件了解一下
|
 |
49
Libby520 2018 年 4 月 18 日
从入职第一天开始就要求规范，时间长了成为习惯就好
|
 |
50
vela 2018 年 4 月 18 日
checkstyle, pmd 了解下。
|
 |
51
douya0808 2018 年 4 月 18 日
我以前的项目组老大规定必须 check style、findbug 两者错误、警告均为 0，否则一个罚款 50，最高一个月我被罚了 1500
现在出来看其他项目组的代码真是辣眼睛，感觉发财了，但是钱肯定收不上来啊哈哈 |
 |
52
ourzhang 2018 年 4 月 18 日
我们就是被强迫的那种，代码多一个空格都找麻烦。
必须要过 checkstyle。 |
 |
53
Akagi201 2018 年 4 月 18 日
确实是个问题, 我建立了 wiki, 并且要多给同事去讲(同事多半不会看).
|
 |
54
YanSep 2018 年 4 月 18 日 via Android
这个简单，首先要制定一套规范，然后按规范执行，违规的处罚，就这样，我们公司以前也是没有规范的
|
 |
55
feverzsj 2018 年 4 月 18 日
规范就是你写的东西别人能看得懂，小公司就别要求太多了
|
 |
56
hxtheone 2018 年 4 月 18 日
如果领导不重视这个, 基本无解, 做好自己就好了
|
 |
57
Hippie 2018 年 4 月 18 日
像 java， 半年前 阿里巴巴就发布了一套阿里巴巴内部的规范约束插件， 装了插件之后 就会自动识别命名 格式等等 是否规范。 PHP 的话你可以找找看有没有类似的插件
|
 |
58
lazypu 2018 年 4 月 18 日
这是纪律。
|
 |
59
Biscuits 2018 年 4 月 19 日
如果要推进, 被议论是难免的. 这种只能靠你自己的声望来避免.一定要强势, 规范很多时候也是不讲道理的.
|
 |
60
Jehovah 2018 年 4 月 19 日
作为同事，的确没法管人家怎么写，除非你是领导
|
• 请不要在回答技术问题时复制粘贴 AI 生成的内容