我们经常会听到这样一句话——简单就是美，或者是这句话的各种变体，而且这句话不限于行业，不仅仅是在软件业，在各种涉及到设计艺术的领域，很多大师级的任务都会告诉我们，简单就是美。
在这里我当然只想针对软件开发相关的内容来谈，其实我们要解决的问题就是——到底要多简单呢？
对于UI设计——不需培训直接能使用
还记得曾经看过的基本讲述交互设计知识的几本书，其中都提到了，最简单也是最美的界面设计，就是用户直接就明白怎么用，而不需要长期的培训，对于这一点我深以为然，并且努力把这一点贯彻到自己所做的系统中。曾经记得自己帮朋友写了一个简单的库存管理系统，界面上没有菜单，只有几个必要的按钮，采用的是Office 2007的ribbon样式，并且精心挑选了几个意义鲜明的图标。朋友使用的时候，就告诉我，这个东西比他之前用过的财务软件好多了，那个东西培训了两个月还是不会使用，而且其中有太多用不到的字段，虽然不需要填写，但是看起来也比较别扭。而我这个东西，当时特意就没告诉他如何使用，只是说，很简单，看看就会了。达到的效果也很让我自己满意，真的是看看就会用了，哈哈。
其实想想成功的产品，比方说最近大卖的ipod、iphone、ipad等一系列苹果的东西，每一种的设计都是超级简单，没有过于复杂的界面和操作，这种美不用我说，已经得到了无数人的认可。
复杂的界面真的非常考验人，曾经见过最复杂的界面还是出现在对日项目中，同样最复杂的报表也在对日项目中，日本人对于基础知识的培训和学习，以及对复杂情况的耐心和毅力的确值得我们学习，如果让我整天面对那样复杂的界面，我可能早就崩溃了。（比方说，一个界面上放40个以上的控件，并且填写一个表单需要滚三屏，都是很可怕的）
我只能说，我是个懒人，不喜欢复杂的东西，解决问题喜欢用简单的方法，各种东西的使用我也愿意选择简单的。
其实，对于设计界面的人来说，或者说叫做交互设计师来说，设计最简单的界面，让用户能够尽快地上手使用，并且所有的使用习惯都与用户的传统习惯相符，本身就是对客户的一种尊重，另外，在市场上，一个产品是否能够取得成功，往往界面设计的好坏会起到非常重要的作用，因为简单易用的界面，会让人真正感受到其中的美，并赢得更多的用户。
上面我们所说的是最终用户所要面对的东西，而对于我们这些程序员整天所要面对的代码，又应该如何呢？我觉得代码的简单就在于——直接能看懂
我们在工作中，不可避免地会需要维护别人的代码，而我们自己编写的代码也经常会由别人来review和维护，那么代码的简单之美就非常重要了。
想要直接看懂代码，我觉得必不可少的有几点：
简短——每个方法都应该尽可能地短，有人提倡每个方法不超过四行，暂时我觉得还达不到那个标准，不过我们至少可以达到的是，每个方法只做一件事。曾经见过非常可怕的代码是有超过五层的if嵌套，而且每个嵌套里面的处理代码都无法显示在一屏之内，我直接就崩溃了，哈哈。
命名准确——这个应该是最有利于在维护的时候理解代码的了。业界中提倡的自解释代码也正是如此，如果变量、方法、类等等的名称都能够准确地表达出它的意义，那么阅读代码就和阅读说明书一样，自然所有的工作就都变得简单了。
恰当的注释——在某些时候，注释还是非常必要的，甚至对于自解释代码，有时还是有必要用注释来说明一下，毕竟其中还有计算机语言无法说明的业务逻辑在里面。当然，注释不应该是越多越好，某些项目中规定一定要有30%的注释量，还是有些值得商榷的。
最后想说说关于数据库的设计，我觉得这其中也必须应该贯彻简单就是美的原则，我们应该达到的标准是——直接能理解。
好的数据库设计对于系统的开发和维护都是非常重要的，特别是对于一些MIS、ERP、MRP等管理软件，数据库的设计在系统的架构中会起到举足轻重的作用。
我想应该把握下面的几个原则：
表中字段不要太多——每个表的字段数应该控制在30个之内吧，这个标准可能会因项目而异，只是一个基本的概念。想象一下吧，当在项目中遇到一个数据表的定义中有超过100个字段的时候，是不是感觉到很难处理呢？我在工作的过程中遇到过多次，这种大而全的表往往就是问题的多发地段。
名称合理——有些项目中，为了预防，往往会使用一些备用字段，或者放一些不一定代表什么意义的字段，它们的的名称可能就是一个字母带数字，比方说a1 a2 a3……这种字段真的是维护者的噩梦，它们可能在不同的情况下代表不同的意义，那样我们不仅仅需要一份数据库说明书，还需要针对每个字段在不同情况下的说明书。如果能够避免这种情况，每个名称都清晰地代表自身的意义，那么难度就会大大降低。
其实这里的原则和编码的原则基本是相通的，毕竟暂时我还是以程序员的角度来看待这个问题的。
总之，简单就是美，就是美啊就是美，你是不是也这么认为的呢？:)