开发故事

故事1：

这段代码我没有找到被引用的地方，是不是有什么隐秘的用法？
哦，没有的，这段代码没有用了。
没有用了怎么不删掉？
删掉干什么？
不删干什么，你还要改，我还要code review，测试还没有办法对这个改动进行测试。
恩，还是放在那里吧，谁知道那天又会用到了。

那天基本不会到来的，即使到来了，谁又能保证这段代码没有问题呢，到那时，技术变了，业务变了，不是还得一样分析，编码，测试的老一套走完软件开发的流程，才敢上线。由于是存在老代码，反而使人容易放松警惕，产生以前就是这个样子，所以现在也不会错的想法。殊不知，时过境迁，无用的代码其实是躲在系统的阴暗角落中苟延残喘，鬼才知道当下该段代码的质量如何。
退一步讲，代码其实是删不掉的。我们不是有版本控制吗，可以在历史记录里面查找啊。实在你爱惜这段代码，觉得以后可以用到，可以保存在本地做备份啊。
放一堆不用的代码在系统中，要占地方吧，要编译吧，要维护吧，要干扰看代码的程序员的思路吧，要和每个有疑惑的人解释吧，百害而无一利吧。有那么多的时间和精力要浪费在这些无用的东西上，还是干脆点，删了吧。
当然，系统中有时会存在一些大家都不知道用途的代码，也没有人可以肯定该代码不再使用。可以打打日志，钻研一下这些代码，或者在集成环境删掉看看有什么影响。总之，系统中不应该有没有人知道用途的代码存在，如果当下不知道，就要想办法了解该代码的用途，最终结果有二，一是搞清楚了代码的用途，一是代码无用，可以删掉。
故事2：

我做了一个重构，合并了功能相似的两端代码。
你为什么要改啊，代码不是运行的好好的吗？
恩，功能是正常的，但是系统代码有重复，所以合并了代码。
不要没事找事，好好的代码不要乱改，改错了怎么办，还要浪费我的测试时间。

软件质量大致可以划分为两个方面，外在质量和内在质量。
用户可以直接观察到的系统功能是否正常，响应速度是否满意等等，属于外在质量。
冰山之下，用户看不到的，开发关注的，除了外在质量，也关注系统本身内在的质量，如架构是否合理，代码是否优雅等等，既然重复代码是软件质量公认的大敌，能改的还是要改的。勿以善小而不为！
故事3

我感觉这个代码不好。
怎么不好，全部遵守代码规范。

软件开发的光环早已褪去，昔日的荣耀我们没有机会体会到，但是至少我们还是想传承其精神一二。软件开发已经产业化了，但是软件开发仍然是介于工程和艺术之间的一个存在。如果一个简单的代码规范就可以解决一切，那么作为软件行业从业者岂不是太悲哀了。
代码规范只是软件开发最基本的一个要求，某种意义上说，是用来规范不合格的程序员的一个工具。因为要划一条线，必然会错杀一二，请把代码规范作为自己的基本要求，并深刻理解为什么有这些代码规范和其使用场景，而不是把遵守代码规范作为最终目标。

看来楼主积蓄很久了，不吐不快
很多时候程序员中的水平差距很大，想法这东西不是你悟到了，并做了，然后其他人就明白的，但是自己有对自己的要求，对开发的态度

SVN是干啥吃的？不要的代码删了，留着干嘛。

楼主很愤怒了，哈哈。唉，没办法

没用的代码删除
重复的代码重构
感觉不好的代码重写

同感，项目已经上线，项目上好多不用的注释代码，重复代码，想重写也不行。

我勒个去

1，同意
2，同意
3，重构的实际要控制，不能乱来
   a，修复bug的时候顺手重构
   b，新需求新设计的时候顺手重构
   c，没事别乱重构，遵从够用就好，不要过度设计。乱折腾bug会有很多风险和成本的。