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

[darasion]

[ytzong]

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

[level_225]

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

[darklowly]

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

[skywinger]

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

[kakaryan]

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

[Sunyanzi]

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

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

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

[skywinger]

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

[kakaryan]

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

[skywinger]

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

[darasion]

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

[PrideChung]

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

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

[kakaryan]

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


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

[imcj]

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

[zz]

@mitnk 入职就打他

[zz]

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

[kaimingyi]

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