你的代码写的很烂

我有一个很熟的朋友，他现在忙的不可开交。他手上有一大堆没有完成的合同，而且一个跟他一起开发的助手也离他而去。于是，在三个大客户的催命鬼时的督促下，他已经连续好几个星期没休息了。

其中有个客户跟他讨论他给这个客户做的iPad应用程序，客户告诉他“我们花钱雇了另外一个程序员来审查你的代码，他说你的代码写的很烂。”

 

当他告诉我这个故事时，我只是微微一笑，想起了我以前是怎么唾弃别人的代码的。当我刚开始编程时，我看到过一段程序，我认为那是毋庸置疑的写的很烂 的，我删掉了那段代码，用自己认为更好的方面重新写了一遍。当我变成的成熟后，我回头再看，发现我所删掉的那段代码其实是用了一个很好的设计模式，而我重 写的确是丑陋无比。

我就这样被上了一课。

之后的日子里，我经常会遇到我认为是丑的不能再丑的代码。尽管如此，我也不通篇否定它们了，我只会在其中找一些特别的无法容忍的部分重新编写。可 10次中有9次，当我快要完成时，我发现了一个问题使我不得不对自己说“哦，怪不得他们要写成这样了”，然后把代码恢复成原样，或也使用同样“丑的不能再 丑”方式完成它。

现在我变的更成熟了，我可以充满自信的告诉你，我再也不会看着别人编的代码说“哦，这代码很烂”了。我知道，在没有了解整个程序的解决方案之前，你 不可能就那么轻易的判断代码的好和坏。真的，有时候它看起来很傻，或完成的不好，或没有文档标注（我的意思是自我注释），然而，你根本就不可能知道程序员 在写这段代码时脑袋里是怎么思考的。更多的情况是，他们要选择这样做是有一定的理由的，除非去深入的研究它们，你不可能再有其他简单快速的方法来理解程序 的上下文环境。

所以，每当听到有人看着别人的代码说很烂时，我只会微微一笑，让我想起我当年的天真和盲目自信。的确，我以前坚信自己是个出色的开发人员，坚信知道 每种算法的最优设计。我很想念当时的自大，但是我很高兴现在学到的这些理念，我知道，我唯一能鄙视的代码只能是我自己的代码，鄙视的原因就是我不能使它变 的更好。

 

翻译来源：外刊IT评论

 

：）

 

评论

21 楼 chanball 2010-08-16  

有时候我是明知道这样写很烂，但是我还是要这样写，因为这样写快。其实很多烂的代码都是由于项目时间短造成了，我也跟楼主一样，看到了很烂的代码，但是我看到的是真正烂的代码。我也跟楼主一样，刚开始一直说“写的真烂”，但是我没说错，唯一错的就是不了解他们是在什么样的情况下写出来的

20 楼 newster 2010-08-16  

楼主说的非常对，在不了解整体架构的情况下是不能轻易的评价一段代码的好坏的

另外，架构是非常重要的！

19 楼 Aaronic 2010-08-16  

mikeshi 写道

aoliwen521 写道

Aaronic 写道

除非是初学者，否则大多数的“烂代码”是被项目催出来的。
我见过一个程序员，时间充裕的时候，代码质量非常高，注释非常漂亮，但一遇到时间紧张，交货期逼近的时候，代码就变得非常糟糕，常常一个方法几百行，注释为零，充斥着大量的代码copy。

还有的“烂代码”是被框架逼的。
有时候公司的框架不够强大，一些特殊功能非得用“烂代码”才能完成，这也是没有办法的。

同感。。
项目催得紧，工作压力大。根本没心情写注释，也没有心情把方法提炼出来，考虑代码的安排或者设计模式。。甚至有时候连稍微全面点的黑盒测试也懒得做。写的差不多，抓紧提交。看都不想再看一眼这些东西。。。

植物大战僵尸告诉我们，如果初期认为僵尸就要来了，忙不迭的种豌豆大炮而不是种向日葵，你的脑子是迟早要被僵尸吃掉的。真正大的项目，还是要注重架构方面的东西的，否则，等到领导都觉得工期内是不可能完成的，同意加时间了，你那糟糕的设计也会要了你的命，到时候你想解释了不行了。

嗯，有道理。
不过注重架构容易掉入过度设计的泥潭，许多你认为要抽象的东西其实项目根本用不到。只能尽量把方法的粒度变小、多写关键注释，方便缩短今后重构的时间。

18 楼 泥沙AV 2010-08-16  

被上了一课，我现在因为还没写代码，只是在看别人的代码来熟悉项目，就感觉‘烂’，原来是这么回事

17 楼 mikeshi 2010-08-16  

aoliwen521 写道

Aaronic 写道

除非是初学者，否则大多数的“烂代码”是被项目催出来的。
我见过一个程序员，时间充裕的时候，代码质量非常高，注释非常漂亮，但一遇到时间紧张，交货期逼近的时候，代码就变得非常糟糕，常常一个方法几百行，注释为零，充斥着大量的代码copy。

还有的“烂代码”是被框架逼的。
有时候公司的框架不够强大，一些特殊功能非得用“烂代码”才能完成，这也是没有办法的。

同感。。
项目催得紧，工作压力大。根本没心情写注释，也没有心情把方法提炼出来，考虑代码的安排或者设计模式。。甚至有时候连稍微全面点的黑盒测试也懒得做。写的差不多，抓紧提交。看都不想再看一眼这些东西。。。

植物大战僵尸告诉我们，如果初期认为僵尸就要来了，忙不迭的种豌豆大炮而不是种向日葵，你的脑子是迟早要被僵尸吃掉的。真正大的项目，还是要注重架构方面的东西的，否则，等到领导都觉得工期内是不可能完成的，同意加时间了，你那糟糕的设计也会要了你的命，到时候你想解释了不行了。

16 楼 zhangshixi 2010-08-16  

有同感，希望那些在一味埋怨别人的代码“烂”的时候，自己最好能先给出一个“好”的解决方案。

15 楼 aoliwen521 2010-08-16  

Aaronic 写道

除非是初学者，否则大多数的“烂代码”是被项目催出来的。
我见过一个程序员，时间充裕的时候，代码质量非常高，注释非常漂亮，但一遇到时间紧张，交货期逼近的时候，代码就变得非常糟糕，常常一个方法几百行，注释为零，充斥着大量的代码copy。

还有的“烂代码”是被框架逼的。
有时候公司的框架不够强大，一些特殊功能非得用“烂代码”才能完成，这也是没有办法的。

同感。。
项目催得紧，工作压力大。根本没心情写注释，也没有心情把方法提炼出来，考虑代码的安排或者设计模式。。甚至有时候连稍微全面点的黑盒测试也懒得做。写的差不多，抓紧提交。看都不想再看一眼这些东西。。。

14 楼 Aaronic 2010-08-16  

除非是初学者，否则大多数的“烂代码”是被项目催出来的。
我见过一个程序员，时间充裕的时候，代码质量非常高，注释非常漂亮，但一遇到时间紧张，交货期逼近的时候，代码就变得非常糟糕，常常一个方法几百行，注释为零，充斥着大量的代码copy。

还有的“烂代码”是被框架逼的。
有时候公司的框架不够强大，一些特殊功能非得用“烂代码”才能完成，这也是没有办法的。

13 楼 咖啡豆子 2010-08-16  

出钱的人说行那就行

12 楼 aoliwen521 2010-08-16  

对我是一个很好的提醒。。。。
圣经教导我们不要冒失开口，也不要心急发言。。尤其是在上帝面前

11 楼 langyu 2010-08-16  

我判断烂代码的标准是看胃部是否有不适反应

10 楼 volking 2010-08-16  

shaobaitou 写道

我们经理跟我这样说的:"黑猫,白猫,能抓到老鼠的就是好猫!"

这句话有其局限性

9 楼 shaobaitou 2010-08-16  

我们经理跟我这样说的:"黑猫,白猫,能抓到老鼠的就是好猫!"

8 楼 qingjian 2010-08-16  

恩 有体会  有的时候 千万别轻易否定别人的设计！ 也许他考虑的东西比你想的多得多， 我们不能太自我了

7 楼 tuti 2010-08-16  

光说烂不烂没有意义，关键是判断理由是什么。

6 楼 webcluster 2010-08-16  

loess 写道

楼主说的很好，我最近找了几个小伙子，一个干了三年的小伙子说我们的代码很规范。他们做1千万的项目也没有这么好。但是一个北大青鸟出来才三个月的说我们的代码很烂，简直是垃圾。
    这就是你说的道理。

兄弟在兰州哪个单位呀 我本科在兰州上的 以前好多同学在兰州工作

5 楼 20029388 2010-08-16  

大背景下决定代码必须写的“烂”一点

4 楼 loess 2010-08-16  

楼主说的很好，我最近找了几个小伙子，一个干了三年的小伙子说我们的代码很规范。他们做1千万的项目也没有这么好。但是一个北大青鸟出来才三个月的说我们的代码很烂，简直是垃圾。
    这就是你说的道理。

3 楼 zr0243 2010-08-16  

有同感， 

2 楼 sunson468 2010-08-16  

恩，得用历史的发展的观念来看代码，不排除有特别的烂的代码，但是除非你读懂了整个过程，否则不要仅仅针对一段代码评价它的好坏。

除非你了解这段代码的发展史，请不要随便说一段代码如何的不好，因为在特定的阶段有特定的实现。

深有体会，现在我也学会了努力去看懂别人的代码，而不是一味的唾弃，如果让我来写，也一定不会比他好多少，因为若干年之后，我的代码也会变成古董，因为需求在变，没有人能够看到未来～