想要直接看懂代码，我觉得必不可少的有几点：

　　简短——每个方法都应该尽可能地短，有人提倡每个方法不超过四行，暂时我觉得还达不到那个标准，不过我们至少可以达到的是，每个方法只做一件事。曾经见过非常可怕的代码是有超过五层的if嵌套，而且每个嵌套里面的处理代码都无法显示在一屏之内，我直接就崩溃了，哈哈。

　　命名准确——这个应该是最有利于在维护的时候理解代码的了。业界中提倡的自解释代码也正是如此，如果变量、方法、类等等的名称都能够准确地表达出它的意义，那么阅读代码就和阅读说明书一样，自然所有的工作就都变得简单了。

　　恰当的注释——在某些时候，注释还是非常必要的，甚至对于自解释代码，有时还是有必要用注释来说明一下，毕竟其中还有计算机语言无法说明的业务逻辑在里面。当然，注释不应该是越多越好，某些项目中规定一定要有30%的注释量，还是有些值得商榷的。

　　最后想说说关于数据库的设计，我觉得这其中也必须应该贯彻简单就是美的原则，我们应该达到的标准是——直接能理解。

　　好的数据库设计对于系统的开发和维护都是非常重要的，特别是对于一些MIS、ERP、MRP等管理软件，数据库的设计在系统的架构中会起到举足轻重的作用。

　　我想应该把握下面的几个原则：

　　表中字段不要太多——每个表的字段数应该控制在30个之内吧，这个标准可能会因项目而异，只是一个基本的概念。想象一下吧，当在项目中遇到一个数据表的定义中有超过100个字段的时候，是不是感觉到很难处理呢?我在工作的过程中遇到过多次，这种大而全的表往往就是问题的多发地段。

　　名称合理——有些项目中，为了预防，往往会使用一些备用字段，或者放一些不一定代表什么意义的字段，它们的的名称可能就是一个字母带数字，比方说a1 a2 a3……这种字段真的是维护者的噩梦，它们可能在不同的情况下代表不同的意义，那样我们不仅仅需要一份数据库说明书，还需要针对每个字段在不同情况下的说明书。如果能够避免这种情况，每个名称都清晰地代表自身的意义，那么难度就会大大降低。

　　其实这里的原则和编码的原则基本是相通的，毕竟暂时我还是以程序员的角度来看待这个问题的。

　　总之，简单就是美，就是美啊就是美，你是不是也这么认为的呢?