从入行做页面仔的时候开始就有点代码洁癖，喜欢比较整齐的码代。后来开始写 JS 了慢慢也开始去看一些 Good/Bad 样例，让自己的代码尽量简单易读不复杂且美观。
但是遇到的人越多越发现这是个问题，总会觉得其他人写的代码很随意，按排出去的任务都会自己过一遍，然后帮忙修改或者指出优化方案。
但是很多情况下功能模块会是同级的或者职级更高的同事编写，直接指出问题或者说优化方案，会让对方觉得尴尬/难堪，但是自己看到这些代码又会很难受。
即使要求团队开启了 ESlint 但是一些业务代码处理方式就特别让人难受。大块的无效代码，但是你改写吧浪费时间，它也不是不能跑，就是看着难受。
因为工作重心的问题，也没有办法组织 review，所以应该怎样避免自己这种主观的“优化”思维方式的呢。
我说说我自己吧，我一开始入行也是有很严重的代码洁癖，每每看到不好的地方，都忍不住提出自己的建议，或者上手重构。
但是这个对于我的工作并没有太大的帮助，反而增加了我的工作量。因此我逐渐对此做出了让步。
对于我独立开发的模块、项目、功能：我自己做好我自己的代码质量就好了。不再去理睬别人的代码内容和质量。
对于在已有项目、模块、功能的接手、二开。就看公司对项目的时间松紧度和前人的代码质量。若本身就是群魔乱舞的屎山或者工期紧张，我会在上面在拉一炮，以功能交付为主。 若本山质量就很好，我也会遵循前任规范。
总而言之就是一句话：做好自己的，不要太较真。
这个问题即从我开始工作就困扰着我 ：“他们难道就一点儿不注重代码质量吗？”。
刚开始的时候，在外包工作的时候，接手一个项目的时候，看到那代码，简直是群魔乱舞，因为甲方老是要改东改西的（而给配的时间又不是很多），几乎每个人都改过，最后虽然还是交付了，那是我遇到的第一座屎山代码。
在后续的几份工作中，我发现这个问题还是比较常见的，大部分人都是选择以完成需求为目的，并没有对代码进行过多设计。
这其中每个人对于交付时间的把控、自身水平、业务熟练度都有关系。
对于代码的设计本身就是一个难题，因为当你开始设计代码时，你的代码就会变得略微复杂一些（相对于不设计代码的同事）。当你引入的设计越多，这些复杂性可能就会慢慢累积。对于不熟悉的人来说，在你看来优雅的代码，对于他来说可能就是一个新难题。
想要写出好的代码，有个现实存在的问题：“不是他们不想写，而是真的写不出来。”。因为不少时候都觉得自己做的已经很好了（其实每过一段时间，我也会觉得我曾经觉得设计的很好的代码中仍然有可以进步的空间）。
要问代码洁癖如何去纠正，对于我来说，不应该去“纠正”，可以选择适量的妥协。我目前的妥协方式就是：“做好自己的”。因为自己也会有时候写出一些垃圾代码。
如果你希望你的团队都有统一的风格，统一的代码组织能力，那就可以在这方面进行一个整体的投入。通过总结自己过往的经验，定期或者定量的组织会议，向其他同事进行传播。前提是他们乐意，否则就成了划水会、独角戏了。对于代码风格来说，无法仅仅依赖 Lint，Lint 实际上只局限于“格式”，而不是“风格”。
如果只靠自己埋头苦干去重写别人的代码，到头来累倒的就只能是自己。如果直接指出他人代码中的问题，再依赖他自己去改正，如果两个人没有达成共识的话，这其实是一件很难的事情，如果你们总是能达成共识，那这个问题就不会存在了（这其实是在消耗两个人的时间做一件事）。
我也一直有代码洁癖，但是从来不会要求别人也这样，也没兴趣去重构别人的代码，代码那么多，我的原则就是管好自己，坚持住自己的底线就好了，当然，如果项目所有权变成你的时候，一些实在看不下去的代码，可以写代码时候把涉及到的部分重构一下
以前有段时间我觉得代码洁癖这种纯粹属于一个程序员的内功的体现，当然如果大家都忙于业务，注重结果，其实很多review，规范都是浮于形式。归结到底，大部分场景下它属于一个软指标。如果组织能把代码质量当作一个硬指标，也就是工作量的部分体现，那这种问题就迎刃而解。当然大部分人能做到“严于律己，宽以待人”都很不错了。
同为代码洁癖患者，第一次崩溃源于项目上线前发现同事把DateUtil的工具类命名为DataUnit，当时等大家都下班了合并完代码后自己修改了这个。后面甚至发现项目内有用f**kAAA作为变量名的代码，完全都不考虑后期代码运维的时候有多痛苦。
现在自己带项目了，项目团队选定、过方案分配任务的时候我会花1-2天去讲代码规范的问题，偶尔在review代码的时候发现问题，哪怕功能已经上线正常运行了3个月了，还会要求团队成员去修改甚至重构处理这些问题。这样做耗费了一些工作量，但目前一起做过项目的成员，可以无缝衔接处理其他人负责的模块，在公司后续项目的配合上也有了一些默契度。如果是付出一些管理成本达到团队磨合的效果，对公司而言是好事情。
楼主因为工作中心问题，无法组织review，可以选定时间进行代码互查，我认为坚持代码洁癖一定是一件好事情，不管作为团队成员还是项目负责人，都应该尽力去维持维护这件事情。仅仅做到“实现就行”“能跑就行”的话，是否还要考虑“运维怎么办”“项目交接怎么办”的问题呢？
个人觉得这是一种很好的习惯，它可以让你的代码更加易读、易懂、易维护。然而，在有些时候的团队协作的环境下，过分追求代码的整洁度可能会给其他人带来困扰。我觉得纠正没必要，必要的应该是团队协作，团队沟通，应该适度妥协，不要过分强求自己的代码风格和习惯，应该尊重团队的编码规范和标准，以达到更好的协作效果。寻求一个平衡吧！
1.2k 阅读
4 回答452 阅读
3 回答3.1k 阅读
极客观点
项目管理
HarmonyOS
程序员
2006 年我开始工作，那会儿没有 GitHub、Google、StackOverflow，也没什么最佳实践之类的东西。大部分时候，每个人都有一个或多个文本文件，里面抄着各种将将 能工作 的代码。然后需要某个功能的时候，就翻一翻，找出一段程序贴上。程序员之间的交流，基本也就是互抄代码片段。
这些代码大部分时候能工作；有时候不能工作，摸索着改改也就行了。公司发展的很快，业务越来越复杂，渐渐的问题越来越多，修复问题的时候，很多代码根本看不懂，我就只好自己写。然后我发现我的代码清晰很多，维护成本很低、复用简单。后来我就开始大规模重构，几乎很少抄旧代码。
重点：然后我就秃了，眉毛也没了。（感兴趣的同学可以点开我的头像）
早先我的观点跟你一样，一定要把所有代码都弄好。最近几年我不断回顾过往，观点渐渐改变：
最后，code review 是必须的，否则一切皆扯淡。