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