Your Code Sucks
A very good friend of mine is in the midst of an avalanche of work. He has a lot of open contracts, and has been abandoned by a fellow developer that was helping him with his workload. So, with three huge clients breathing down his neck he has been working non stop for weeks now.
One client contacted him about the iPad application he is building for them, he let him know "I paid another developer to look at your code, he says it really sucks."
When he told me this story, I had to chuckle a bit, and think of all the times I had decided that other people's code sucked. When I first started out, and I looked at code that definitely sucked hard, I scrapped it, and started from scratch in a way I knew was way better. As I matured I looked back and realized that what I had destroyed was a well accepted design pattern, and what I created was a mess of a mess pattern.
Lesson learned.
After some growth I encountered code that I thought sucked ever so often. At this point I wasn't decimating things all together, I would find specific parts of code that I found intolorable and rewrite it. About 9 times out of 10, when I got more than halfway there I'd run into an issue that made me say "Ooooh, that's why they did it that way" and revert it or use the same "sucky" logic with my syntax.
Now that I am a little more seasoned, I can tell you with all confidence that I never look at a solution that someone else created and say "Oh, this code sucks." I know that there really is no quick way to tell if code is good or bad without understanding the entire solution. Sure, sometimes things can look sloppy, or poorly done, or undocumented (in my case, not self documenting), however, you never know what was going through the head of the developer that wrote it. More often than not there is a reason why they have done things this way, and there is no hard and fast way to tell what the context is without being elbow deep in it.
So, when I hear that someone has looked at someone else's code base and determined that it sucked I smile and remember what it was like to be so new and sure of myself. So sure that I was an amazing developer, and that I knew what was best in every problematic situation. I miss that swagger, but I appreciate what I have learned, and that is the only person's code that sucks is my own, and the reason why it sucks is I just haven't learned how to make it better yet.
你的代码写的很烂
我有一个很熟的朋友，他现在忙的不可开交。他手上有一大堆没有完成的合同，而且一个跟他一起开发的助手也离他而去。于是，在三个大客户的催命鬼时的督促下，他已经连续好几个星期没休息了。
其中有个客户跟他讨论他给这个客户做的iPad应用程序，客户告诉他“我们花钱雇了另外一个程序员来审查你的代码，他说你的代码写的很烂。”
当他告诉我这个故事时，我只是微微一笑，想起了我以前是怎么唾弃别人的代码的。当我刚开始编程时，我看到过一段程序，我认为那是毋庸置疑的写的很烂 的，我删掉了那段代码，用自己认为更好的方面重新写了一遍。当我变成的成熟后，我回头再看，发现我所删掉的那段代码其实是用了一个很好的设计模式，而我重 写的确是丑陋无比。
我就这样被上了一课。
之后的日子里，我经常会遇到我认为是丑的不能再丑的代码。尽管如此，我也不通篇否定它们了，我只会在其中找一些特别的无法容忍的部分重新编写。可 10次中有9次，当我快要完成时，我发现了一个问题使我不得不对自己说“哦，怪不得他们要写成这样了”，然后把代码恢复成原样，或也使用同样“丑的不能再 丑”方式完成它。
现在我变的更成熟了，我可以充满自信的告诉你，我再也不会看着别人编的代码说“哦，这代码很烂”了。我知道，在没有了解整个程序的解决方案之前，你 不可能就那么轻易的判断代码的好和坏。真的，有时候它看起来很傻，或完成的不好，或没有文档标注（我的意思是自我注释），然而，你根本就不可能知道程序员 在写这段代码时脑袋里是怎么思考的。更多的情况是，他们要选择这样做是有一定的理由的，除非去深入的研究它们，你不可能再有其他简单快速的方法来理解程序 的上下文环境。
所以，每当听到有人看着别人的代码说很烂时，我只会微微一笑，让我想起我当年的天真和盲目自信。的确，我以前坚信自己是个出色的开发人员，坚信知道 每种算法的最优设计。我很想念当时的自大，但是我很高兴现在学到的这些理念，我知道，我唯一能鄙视的代码只能是我自己的代码，鄙视的原因就是我不能使它变 的更好。
Taken from:
http://www.aqee.net/2010/08/09/your-code-sucks/
http://www.girldeveloper.com/2010/07/your-code-sucks.html