自己一点心声

大部分程序员(个人认为):都希望自己程序达到完美的程序
但是大部分企业(至少我看到的企业都基本上是这样):当一个项目或功能下来,在一定时间内没有办法达到程序质量非常

好的情况下,都只要求功能能够达到ok了.但是这种情况一部分程序员都不会去注意代码质量,但是这个程序或功能内隐

藏的BUG和效率问题基本上没有办法达到理想状态的. 当有了充裕时间后:老板或主管都不愿意重构,因为这样会浪费大

量的时间.这样的情况就会导致后面的维护人员改动程序会是非常的麻烦,这样就会变成恶性循环(其实浪费的是更多的时间)

为什么程序员不应该强而有力的提出重构代码,让老板或主管注意到代码质量质量问题,但是我看到太多程序员只是当时把问题提出来,但是上级提出反对以后就会遵从他们的意见.

我承认大家(包括我)是怕丢工作或让上级对你的影响不好或有别的原因,而影响了前途或钱途.

我又看到这样的问题发生在我身上,但是我的意见没有被采纳. 现在的我想把这个项目做好就闪人(所以我还是重构了)

也没有管去什么主管的反对(大不了就是辞退)

不知道我的想法是否太过激烈?

评论

18 楼 celine 2008-01-30  

我和老板的观点是一致的：有收益的投入才值得投入，so，我们经常重构，但我也拒绝过某些人纯粹为了练习设计模式而要求的重构～

17 楼 Friedrich 2008-01-30  

如果老板允许，但重构代码不得占用上班时间，不能影响到项目的进度，也不给你加班费，而且因为重构导致的测试/修改文档的多余工作量你也需要全权负责，因重构代码导致的潜在风险也全由你承担，你还愿意去重构吗？

如果你愿意，我想老板是不会拒绝的

16 楼 shevliu 2008-01-30  

老板是不会去维护代码的。。。

15 楼 protti 2008-01-23  

C3PO 写道

恕我直言，能把代码写得又精简又易懂的人很稀罕，可能一个公司也没几个。

实际情况是：能把代码写得清晰明了，让以后维护的人能很快找到需要修改的地方，就已经是很谢天谢地的状态了。能把代码写成那样的人才都不多。在高呼“重构”，“完美”之前，先问问你自己是不是这样的人才，有没有人维护过你的代码之后跑来跟你说很欣赏你的代码？

有人跟我说过，如果我的一段代码5秒钟之内不能让人看懂，那就是写得不好。如果将来有维护的人跑来问你这段那段代码（也许不到30行）是什么意思，希望你不要骄傲地跟人吹嘘什么“精简”，“重构”，人家看不懂你的东西说明你是个低手，不是什么光荣的事情。

说的不错，看别人精简的代码也不是轻松的事，特别有些“牛人”特意用一些不常用但是功能一样的代码。
易读性太差。

开发的代码是自己写的，维护有可能是别人，写的精简不易懂的代码跟又臭又长的代码没什么区别（除非性能上的）。

14 楼 xyz20003 2008-01-23  

就是啊，要是上头没有标准，每个人都搞一套，最后不乱套了吗？
要是你是头儿，手下人为了多少行重构吵呀吵的，你心里不是也烦吗？

还是和谐的好，要和谐呀。

13 楼 ice123456 2008-01-23  

xyz20003 写道

C3PO的话很简单，你认为好的，别人不一定认为好，你觉得完美的，别人可能不够完美。

如果你是头目，可以指定一套规则，限制代码的结构和编码规范，如果你不是头目，那么应该遵守上头指定的编码规范，规范上写了，每个方法大于100行就应该重构，写了cpd上出现的代码就应该整合到一起，那么就去重构好了。

如果没有标准，完全靠自己去判断，就没什么争论的必要了。我觉得，既然是工作，还是要统一标准的好，要不最后互相扯皮就没意思了。

大于100行??  我最多大于30行`  我就去重构

12 楼 xyz20003 2008-01-23  

C3PO的话很简单，你认为好的，别人不一定认为好，你觉得完美的，别人可能不够完美。

如果你是头目，可以指定一套规则，限制代码的结构和编码规范，如果你不是头目，那么应该遵守上头指定的编码规范，规范上写了，每个方法大于100行就应该重构，写了cpd上出现的代码就应该整合到一起，那么就去重构好了。

如果没有标准，完全靠自己去判断，就没什么争论的必要了。我觉得，既然是工作，还是要统一标准的好，要不最后互相扯皮就没意思了。

11 楼 ice123456 2008-01-23  

冗长不是好事，但是又精减又易懂的代码要求就更高了，生产环境下有时候没空去追求这个
这点你也知道阿??  那为什么不改?  等后面来维护的人改??

10 楼 ice123456 2008-01-23  

C3PO 写道

你所谓的“完美”可能只是一厢情愿，一文不值。当需求变动来临的时候说不定你那苦苦构思的“完美代码”和“架构”都要推到重来。更可能的是当未来的你回头维护自己的代码的时候，再也想不通自己当初的设计为何如此怪异。

可能就像你说的,我的完美只是我自认为的完美,但是同时我认为这种"完美"是当前程序需求最好的代码了

小小龙猫 写道

很多公司是做项目的，项目做完人也要被调到别的项目组去了，除非你被留下来做维护，才可以做些自己想做的事情。
到是觉的互联网公司和做产品的公司更适合做这些事情，反正我已经开始讨厌一遍一遍的花时间理解一个新的业务需求。

    是的,我可以把这个程序做完了,不需要管维护或增加需求,我只需要写冗长但是易懂的代码给后来的人去改就行了.
可能这种代码跟我想象中的代码就只有美观和代码大小不同罢了,我还更添加了它的复杂性.

    可能是我想法有点天真或有点固执,我认为一个好的软件或程序是不断重构和修改出来的,冗长但是易懂的代码可能大部分人都认为好,但是同时它的文件大小和质量有多少是可以保证的?

  

9 楼 ray_linn 2008-01-23  

重构是软件的目标，但不是软件公司的目标。

8 楼 agile_boy 2008-01-23  

为什么要专门去重构呢？给老板的印象是你好像要重写，老板当然不同意了，呵呵。
完美是要的，但也要讲究一下平衡。

7 楼 xjl 2008-01-23  

这种问题不好说，人的思维总是单方面一相情愿的。

你的重构很可能只是你追求完美的一种表现，而你领导考虑的是“重构”很可能得不偿失，他们只是想要一个能用的功能罢了。

也可能你是对的，这种事情只有你付出更多（利用下班时间重构），才能得到认可。

我最近也是深有体会：负责的员工，不是最好的员工；付出更多努力，让别人的不认可改变为认可的员工，才是最棒的。

6 楼 lordhong 2008-01-23  

那么。。。只要搞清楚以后是不是你自己维护再决定重构不重构。。。

5 楼 小小龙猫 2008-01-23  

很多公司是做项目的，项目做完人也要被调到别的项目组去了，除非你被留下来做维护，才可以做些自己想做的事情。
   到是觉的互联网公司和做产品的公司更适合做这些事情，反正我已经开始讨厌一遍一遍的花时间理解一个新的业务需求。

4 楼 ice123456 2008-01-23  

Michael 写道

你直接说我在“修改”以前的程序，而不是重构，然后你重构。这不是骗人不骗人的问题，虽然你“内方”，但是必须要“外圆”才行。

时间上不够阿.....  修改或重构时间上可能一样吗?

3 楼 Michael 2008-01-23  

你直接说我在“修改”以前的程序，而不是重构，然后你重构。这不是骗人不骗人的问题，虽然你“内方”，但是必须要“外圆”才行。

2 楼 ice123456 2008-01-23  

lordhong 写道

你的想法是一个好程序员一个真正对自己程序负责的程序员的正确想法。

但是在上级面前我只是顽固的想法

1 楼 lordhong 2008-01-23  

你的想法是一个好程序员一个真正对自己程序负责的程序员的正确想法。