有代码洁癖算不算是个好事

我就有比较强的洁癖要求实习生写 python 不符合 pep8 直接 close PR. 要求团队内部统一代码风格, 用拼音或者风格不一致的我会揪出来重点批评, 复杂一点的函数逼每个人都写文档并且随改随更新.

今天上午又因为一个实习生使用git add *, 结果加进来一大堆临时文件发火了...感觉其他人都不理解自己好累...

nicevar

2020-07-01 09:19:16 +08:00

不是什么代码洁癖问题, 就你自己的描述来看明显你们的 git 流程有问题, 实习生提交的代码你们不审核直接就合并了? 还是都没有创建分支, 抱团开发? 这些都没弄好, 把锅丢给实习生不合理

STRRL

2020-07-01 09:29:31 +08:00

是好事

levelworm

2020-07-01 09:46:51 +08:00

是好事，不过发火没必要。另外 git 不加临时文件等等我倒是觉得的确比较重要，楼上说的审核也很有道理。

levelworm

2020-07-01 09:52:09 +08:00

@Jooooooooo +1 。能用系统解决的最好。

wolfie

2020-07-01 09:53:46 +08:00

git add 肯定有问题，如果临时修改配置文件测试用直接提上去？

kzfile

2020-07-01 10:13:10 +08:00

有个完善的脚手架可以让人养成代码洁癖

linvon

2020-07-01 10:13:25 +08:00

@lenqu 一般项目自身没有 gitignore 我也不会去给它加，一直用 git add -u

hantsy

2020-07-01 10:15:31 +08:00

规则是必须。虽然不必要求太苛刻，但是不成规矩，不成方圆的道理，大家都懂。

1. 简单开发文档说明统一遵循的约定。应该配置代码静态检测之类的工具，Git 嘛，最基本的 Github FLow 吧（ Branch 基础）。最好参加一些国际上认可的代码规范，然后定制，这点我讨厌一些自己创造（看到很多人搞出来的笑话）。

2. 一开始就使用工具配置强制要求，而不是靠嘴巴，流程做到位，让偷懒，摸鱼，打酱油的行为无处可藏。我这个人特别讨厌绩效考核，但是之前一些经验告诉我，对于一些懒散的第二次犯同样问题的人，绩效是个很好的东西。

你说的这个 Git Add 的代码怎么会直接合并进去 Master ？我不明白这是什么操作？没有分支？没有 Code review ？没有 CI ？

soulmt

2020-07-01 10:18:08 +08:00

洁癖是好事，但是用这种方式管理，很明显有问题，你可以针对规范开个小会，得到大家对规范的认可，或者用脚本检查语法规范，合格了才可以 commit，方法很多

ghwolf007

2020-07-01 10:20:31 +08:00

感觉对手下人是好事我多希望刚毕业能碰到这种团队结果散养到现在唉

sanqian

2020-07-01 10:23:33 +08:00

好事吧，对实习生也挺好的。但是为了这个对其他人发火的话没必要吧实习生也需要点时间去适应你？

mahone3297

2020-07-01 10:24:08 +08:00

好事
不然，他离职了，还是要你处理吧？线上出问题了，开发的人不在，你肯定要紧急处理，看不懂代码，怎么办？
所以，还是平时要求把。。。

hsk9044

2020-07-01 10:25:30 +08:00

规范是好事, 如果刚开始没有养成习惯, 后面等老油条再改回来更麻烦

hantsy

2020-07-01 10:33:15 +08:00

@namelosw 人工监督方式没必要的。

我一直推荐强制用工具来约束。

代码都是可以 Code Review，在 Github PR （其它的专用 CR 或者 GitLab 也类似）上，人人都可以针对某一行代码，某个文件，扯断进行否决，或提修改意见。技术这东西还公开讨论比较好。

国内最怕的是某些人本来就平时懒散成性，加上心胸狭窄，最后成了拉仇恨，变成人身攻击的可能。

zzzmj

2020-07-01 10:33:27 +08:00

代码洁癖，不要上升到钻牛角尖都可以接受，至于统一代码规范，可以用一些 ci+lint 工具，挂了不给过就好了。从小抓起还是最省事的

Nostalgiaaaa

2020-07-01 10:34:36 +08:00

工具比每天开会好用不少。配置下 pre-commit，.gitignore，写点 pylint 插件，加上 ci 或者 action 基本解决你现在描述的问题。

TangMonk

2020-07-01 10:38:11 +08:00

严格是好事，但是发火不是好事。

不应「违逆我者则生嗔恚」。

libook

2020-07-01 10:41:01 +08:00

分情况。

1. 要依照具体情况制定标准。举个例子，代码缩进，后端代码逻辑复杂，且每一行不会太长（很多语言长语句拆成多行阅读更清晰），强化视觉层级可以加强代码可读性，所以可以考虑缩进四个空格；前端 HTML 代码可能因为标签属性较多，每一行都会很长，所以为了尽量避免折行，可以考虑缩进 2 个空格，甚至 1 个。（当然，可以换成 Tab ）
2. 制定标准要有理有据，不能作为信仰开圣战，也不要盲从大公司、大牛、著名项目。比如有的人见过 StandardJS （注意这个不是 JS 官方标准）之后就唾弃一切在末尾加分号的行为，但忽略了之所以可以不加分号是因为有 StandardJS 的 Linter 在排雷，没有 Linter 的时候盲目省略分号基本上就是作死（从不失手的肉体解释器除外）。
3. 如果是多人协作的项目，要以团队为重，个人让步，Leader 负责把控标准对于项目整体和未来发展的适用性。只要没有明显的风险其实都可以尝试接受。
4. 能用工具限制的事情，尽量不要靠自觉。一来可以使得团队和睦，免去扯皮；二来可以提高效率。各自语言的 Linter 、.gitignore 、editorconfig 、commitlint

再说说管理上的，个人建议就事论事，有问题解决问题，没必要带入情绪（当然做到这个很难）。
其实通常出现情绪主要还是因为举手无措，由一个问题反复解决但是最终仍然复发而导致的懊恼；可以尝试加一些轻的奖惩机制，比如 6 人的团队，谁出现一次不符合标准的情况就请大家伙下午茶，这样惩罚不重，但也始终有个惩罚在那时刻提醒大家要遵循标准。