我们要写怎么样的系统

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

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

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

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

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

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

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

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

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

内容跟标题一点关系都没有，至少不是在写怎么写系统.

一个段程序就是一个系统

LZ 说的很好

求 好代码

大多数看上去很烂的程序都是可以改进的，只是水平的问题。
要知道kent beck、martin fowler这些就是专干这种这种事的，不能改只能说明水平还不够，拿来自我安慰

列宁同志曾经说过：当你搞不清楚这个事的时候，马*克*思*主义者的绝对要求就是，把它提到一个历史范畴之内。
所以看代码要结合当时的历史环境和系统环境来看。哈哈

注：列宁好像不会编程~~~

哈哈

一行代码一个世界
一个世界有很多行代码.
写一行代码作一次孽.
这个世界就是作孽就要还

对于那些没有勇气去重构的兄弟
你们可以先不OO先改改文件名
改改方法名
改改属性名
把方法挪挪的地方.


抽抽方法起个漂亮的名子.....给这个方法加个测试
还有很多.................

没必要害怕能干多少干多少.
不要写完功能就让测试去测 ,
祈祷自己代码不会出错.
冤孽总需要有人会去还的.不是你就是别人.

就我个人感觉而言,就是写完的东西,下班的路上想想哪里还有问题,该怎样改代码看起来才优美,怎样才能更简练.如果一眼看上去代码像一坨屎,那基本就是烂代码.第二天上班,先改再写新的代码,如此往复.

我做过的所有代码中，有80%以上的，我感到羞愧。

也有很少一部分，会让自己感到惊艳。

瞎扯什么蛋，楼主要淡定，不要眼里只看到别人的差而忽略了别人的优。。。。。

心如止水地去面对吧，尽力做好就可以了，