我们要写怎么样的系统

编程也好久了。越来越觉得一个做一个好的程序员不是一件简单的事情，只有努力努力再努力。
经常看到一些很烂的代码，总是想着怎么要把它改善一下。今天，看了javaeye的你的代码写的很烂的帖子，心里一阵的寒啊。有那么多的人在说：

在没有了解整个程序的解决方案之前，你不可能就那么轻易的判断代码的好和坏。
在没有了解清楚前请不要轻易下结论，任何一段代码能跑起来都有它的一定道理。
恩，得用历史的发展的观念来看代码，不排除有特别的烂的代码，但是除非你读懂了整个过程，否则不要仅仅针对一段代码评价它的好坏。
千万别轻易否定别人的设计！ 也许他考虑的东西比你想的多得多， 我们不能太自我了。
你几乎无法在短时间、局部的环境中体会到10年前编写这段代码的人的思路。
是的，每个人都有自己的设计思路……不应该轻易的去否定别人的作品！！

对，我承认上面说的都有道理。

好吧，那我们程序员是干什么的，我们为什么做程序员，如果有一天我们看到自己的系统都是一脸惭愧，那作为程序员自身的意义何在呢。

我很同意在没有了解整个程序的解决方案之前，你不可能就那么轻易的判断代码的好和坏。
但是事分两说，如果一个成熟的程序员不能很快的看出一个系统的大概架构，那这个系统就是有问题的。很多时候，要费劲心机才明白一小段程序的意义，为什么，因为代码不好，没有自我解释性。本来看代码应该是只看一个架构，看一个领域模型，就差不多了，基本上靠猜应该八九不离十了。但是实际生活中呢，太多方法名和内容不符合的了，搞的人都怕怕了。

代码应该还是有好坏之分的吧，你看到一个7层的try catch不晕，你看到一个17个参数的方法不晕，你看到一个方法前条件约束2，3页的不晕，ok，我服了你了。

即使是整个程序的解决方案之前，你不可能就那么轻易的判断代码的好和坏。这句我还是有保留的，一个类写在哪里，一个方法出现在哪里，都是有意义的，一段代码的好坏，的确依赖于对整个方案的理解，但是，同样的，一段好的代码，本身就应该可以解释很多事情。

常见的理由，有时间紧，资源有限，功能性的需求优先级高，历史条件（这个听的最多了）。我们不是有持续重构的利器吗，不要觉得一个方法的注释，一个变量的名字，不重要，想想看，写代码和读代码的时间的比例，我们一天写几行代码，一天要读多少行代码，当你读着读着想打人，骂人的时候，多想想自己不要做这样的人。

看了这个帖子有点激动，有些言语过激了。