软件设计,简单就是美

很多大师级的任务都会告诉我们,简单就是美
服务器君一共花费了367.470 ms进行了4次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

我们经常会听到这样一句话——简单就是美,或者是这句话的各种变体,而且这句话不限于行业,不仅仅是在软件业,在各种涉及到设计艺术的领域,很多大师级的任务都会告诉我们,简单就是美。

在这里我当然只想针对软件开发相关的内容来谈,其实我们要解决的问题就是——到底要多简单呢?

UI设计:不需培训直接能使用

还记得曾经看过的基本讲述交互设计知识的几本书,其中都提到了,最简单也是最美的界面设计,就是用户直接就明白怎么用,而不需要长期的培训,对于这一点我深以为然,并且努力把这一点贯彻到自己所做的系统中。曾经记得自己帮朋友写了一个简单的库存管理系统,界面上没有菜单,只有几个必要的按钮,采用的是Office 2007的ribbon样式,并且精心挑选了几个意义鲜明的图标。朋友使用的时候,就告诉我,这个东西比他之前用过的财务软件好多了,那个东西培训了两个月还是不会使用,而且其中有太多用不到的字段,虽然不需要填写,但是看起来也比较别扭。而我这个东西,当时特意就没告诉他如何使用,只是说,很简单,看看就会了。达到的效果也很让我自己满意,真的是看看就会用了,哈哈。

其实想想成功的产品,比方说最近大卖的ipod、iphone、ipad等一系列苹果的东西,每一种的设计都是超级简单,没有过于复杂的界面和操作,这种美不用我说,已经得到了无数人的认可。

复杂的界面真的非常考验人,曾经见过最复杂的界面还是出现在对日项目中,同样最复杂的报表也在对日项目中,日本人对于基础知识的培训和学习,以及对复杂情况的耐心和毅力的确值得我们学习,如果让我整天面对那样复杂的界面,我可能早就崩溃了。(比方说,一个界面上放40个以上的控件,并且填写一个表单需要滚三屏,都是很可怕的)

我只能说,我是个懒人,不喜欢复杂的东西,解决问题喜欢用简单的方法,各种东西的使用我也愿意选择简单的。

其实,对于设计界面的人来说,或者说叫做交互设计师来说,设计最简单的界面,让用户能够尽快地上手使用,并且所有的使用习惯都与用户的传统习惯相符,本身就是对客户的一种尊重,另外,在市场上,一个产品是否能够取得成功,往往界面设计的好坏会起到非常重要的作用,因为简单易用的界面,会让人真正感受到其中的美,并赢得更多的用户。

代码的简单就在于:直接能看懂

上面我们所说的是最终用户所要面对的东西,而对于我们这些程序员整天所要面对的代码,又应该如何呢?我觉得代码的简单就在于——直接能看懂。

我们在工作中,不可避免地会需要维护别人的代码,而我们自己编写的代码也经常会由别人来review和维护,那么代码的简单之美就非常重要了。

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

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

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

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

数据库的设计:直接能理解

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

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

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

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

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

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

本文地址:http://www.nowamagic.net/librarys/veda/detail/772,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/772

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

现代魔法研究协会欢迎你

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《大话设计模式》 程杰 (作者)

《大话设计模式》通篇都是以情景对话的形式,用多个小故事或编程示例来组织讲解GoF(设计模式的经典名著——Design Patterns: Elements of Reusable Object-Oriented Software,中译本名为《设计模式——可复用面向对象软件的基础》的四位作者Erich Gamma、Richard Helm、Ralph Johnson,以及JohnVlissides,这四人常被称为GangofFour,即四人组,简称GoF)总结的23个设计模式。本书共分为29章。其中,第1、3、4、5章着重讲解了面向对象的意义、好处以及几个重要的设计原则;第2章,以及第6到第28章详细讲解了23个设计模式;第29章是对设计模式的全面总结。

更多计算机宝库...