很多人做事写代码都在对付，写好规范也没人遵守，只要能实现需求啥办法都用，重复代码一坨坨，看得人眼花缭乱。非常恶心。

你们代码没有审核吗,我们公司代码写完都有审核,写的不规范就返工重写!

定期做team code review

定期review

用gerrit吧

写程序多，会写程序的少。

gerrit +1,不靠谱的人只给 read+upload,靠谱的给 review+submit 权限

这样不靠谱的提交全部可以打回重新提交

审核就是个应付，对于敝司这种项目型公司，只求短快平，是个人就招，只关注业务，不注意留人，不注意技术积累。
之前项目重复的一坨坨好不容易被我干掉了好多之后，业务代码好歹叫有半个像是代码像是html的样子，突然来个新项目组，然后又继续一坨坨，跟领导说也没用，想想也是，都2012了还在使用这种早已经被淘汰的框架来做web，还美起名什么3.0、4.0，恶心的继续。

@tremblingblue 给别人做项目的公司都这样

review +1

就是如 @tremblingblue 说的这样。

@cyokvip 我那个是给自己公司内部做的。

入职就送他一本《重构》，读一星期

这种情况最终还是看人，包括干活的人的素质，和老板的关注点。
如果上下都有提高代码质量的共识，可以用Sonar持续检测代码质量，将质量状态可视化，然后订立质量标准。一开始起码要求代码质量不能继续下滑，然后制定目标逐步改善。
虽然这种规则检测死板了一点，但是效率比人工review高很多，而且容易定制客观标准，而不是因人而异。在团队不成熟的时候，反而比较有效。

+1 @welsonla for 入职就送他一本《重构》，读一星期

么有流程就么有生产力。

看公司的管理体制是什么样的？
制度严格，很古板的团队风格，可以强化代码review，有奖罚机制。
如果是较为人性化，很愉快的团队风格，可以靠内部交流讨论建立良好编码的风气。
总之风气很重要！更重要的是在管理上不要给混乱的代码找到借口！！！比如，不论项目时间是否紧张，都不能成为代码混乱的借口。

没办法阻止别人。

送书的都不现实，写代码不认真的人，根本就不会认真看书；
咱不是管理者管不着别人，是管理者也不会关心代码质量；
常常替人擦烂代码的屁股，平时工作受到赞赏的一般都是那些干活快速而无质量的人，最后出的各种稳定性问题总是留给那些认真做事的人。

也许。。。。一开始就应该做个烂人懒人奸人坏人。

其实感觉个公司有关。
如果工作量一堆一堆压，是个人都对付了。如果轻松惬意才会去关系代码质量

看老板喽，老板不行开掉他。

我们也是这样，天天说专注，说质量，其实是东一榔头西一棒子，一个项目不管需求多天马行空，一概两个月。。。。

也不是没有一起讨论过，也不是没有定过规范，规矩，也不是没有下过决心，技术负责人换了一个又一个，哪个来了还不是这些方式方法。你规范定了，规矩立了，第二天，老板起个项目，一个月提交测试审核，两个月上线，规范？规矩？全没啦，上线要紧啦，于是又失败了。。。。

这种公司，别要质量啦，也别要什么技术积累技术发展啦，各自忙乎各自的，尽可能让自己成长，自己舒服就得啦。

@darasion
为什么我之前一份工作跟你说的情况这么像……也是给客户做网站的。
经理啥都不管，就看你做得快不快，一来就跟我说XX一天做4个网站，我操，除非copy & paste，否则这可能么。后来XX跑路了，发现他原来干活只干一半的，有些页面直接拿前端做的静态页面来骗客户，反正客户也不懂。结果呢，就找我给他改bug。我不知道XX之前在公司呆了多久，但我直到我离职前一周起码要给他擦一次屁股。
骂了隔壁，耍滑头的拿了钱就跑，老实人还得给他打扫残局。

换个环境吧。

就我而言，不遵守规范的原因是不认可规范，我需要一个能镇的住我人给我定规范
如果强制我遵守我不认可的规范，我会想办法调到一个我能做主的项目

@darasion 真要是把干活快速而无质量的人当榜样的公司也只有后果自负了

给楼主+1 我喜欢你这样的程序员。

其实大家还只是关注在写程序这一层面，很多公司都是以自身生存为第一前提，项目赶不出来，不能及时提交给客户，就拿不到回款，就没法养活自己，就不能做大。其实这些个问题，老板也心知肚明，但是中国就这一情况，生存压力是最大的，其它都靠边站。
如果是和老外一样，第一次创业挖了一桶金了，后边再创业，再做一些新东西，本身就会考虑产品质量、代码质量，高可重用性这些。

@skywinger 不完全同意,我以前也长期做项目.生存是一个大前提,但是代码质量和生存是不冲突的,在我看来,赶时间不是写烂代码的借口.当团队中每个人都不会去直接复制粘贴代码的时候,我发现在这些代码的基础上重构的成本其实已经可以接受了,而且大家都会发现开发效率提高很多.不知道DRY的Coder应该及时的被开除,因为你还得给他搽屁股,我管这叫负输出.

只有一句话 ... 抽出时间来每周例行开代码评审会 ...

这是我现在的方式 ... 简单粗暴有效 ...

不仅仅可以激发大家思考的热情 ... 还可以避免上班划水 ...

@kakaryan 老板是不会看代码的，但是却会看到你的工作效率，你跟你老板说，你前期需要一定的时间来重构或优化现有的代码，后期工作效率会高；老板肯定懒得理你，还会说，不要太执着于你自己写的代码，代码写的再好，意义都不大，过个三五年，你回头再来看看自己之前认为写的不错的代码，自己估计都觉得做此类事情无意义，意义在于你能不能想到一个好的产品，做出一个好的产品。就连苛刻细节的jobs，也无所谓他手下的人是如何实现功能的。

@skywinger 老板的确不会管我怎么实现,但是你可以去引导他,让他认识到重构带来的价值. 我相信大多数管理者不是短视的.重构的意义不在于这个代码要用个三五年,而是在于提高代码的可维护性和可扩展性.非要等到代码的维护成本等于或者高于重新开发的成本的时候再来讲重构已经晚了.不知道你的老板对于一个几个月之后不能维护的代码的看法是怎么样的,你会告诉他我需要再花XX小时来重新做一个?

@kakaryan 没你想的那么复杂，原来谁做的，需要添加功能，或是修改需求时，再让他们干就行，不推荐提早进行重构，有重构必要时，原先写那些代码的家伙，自然会想着如何重构，报书本，上网找方案等等，何必吃力不讨好的，一开始就强制要求呢？有重构的需求了，自然就会去做这件事，提早去做，没啥必要。

@skywinger 现实情况是，多数写了烂代码的人，干一阵就离职。

@darasion +1，而且让别人接手代码，可能比重新写一遍还花时间，特别是原来的代码是烂代码。这种情况根本不是重构，是重做了。

再者，如果对代码的味道有自觉，懂得DRY的程序员，就算一开始写的代码并不完美，也绝对不会是一坨一坨的。一开始就放任代码腐烂的coder，可能根本连“重构”这个词都没听过。

@PrideChung 然也,不懂DRY的程序员应该被开除出程序员界,输出的代码没有维护性可言.随着项目的不断前进,很快就会发现,他的代码的维护成本将大于其价值,只能苦逼的帮他重写了.如果继续让他将这种代码维护下去:第一,他自己很痛苦.第二,这个问题下次暴露出来的时候帮他搽屁股的人更想去死.


@skywinger 你就没帮别人搽过屁股?你不觉得帮人搽屁股是件极其痛苦的事情?

@darasion我觉得这个问题要分好几种角色。先问程序员，为什么不写好一些。在问程序的组长或主管，为什么会有烂代码，再问项目经理，这是什么样的项目。有些项目做好了就再也不管的也不是不存在。

@mitnk 入职就打他

@kakaryan 我就是不知道DRY的CODER。

直接干掉！或者把自己干掉！