阅读 1469

将设计学知识应用于写代码

源于一本书

这本书叫《写给大家看的设计书》。身为一个前端,想着懂一点设计也不错。这对我们的工作是有帮助的。假如此时没有美工帮忙,产品给你个简单的原型图,你也可以通过自己掌握的设计知识,写出不那么难看的界面。

在生活中,懂一点设计学知识,还能提升我们的审美。懂得什么样的设计是好的,甚至能看懂一点其中的门道。

大家熟知的Ant Design。在它的文档中致敬了这本书。且它的设计语言原则中的前四点,亲密性,对齐,对比,重复。就是《大家看的设计书》中提出并着重介绍的设计原则。

所以我推荐这本书给大家,有空可以读一读,很有意思。

应用于写代码

将设计学知识应用于写代码。也是可行的,能使我们代码更工整一些。我们的代码写在文件中,也要讲究布局。把代码当作是文章段落,把代码文件当作一种特殊的新闻简报。

接下来就阐述四项基本设计原则,以及在代码中的应用。

设计四项基本原则

  1. 亲密性
  2. 对齐
  3. 对比
  4. 重复

亲密性

亲密性的思想并不是说所有一切都要更靠近,其真正的含义是:如果某些元素在理解上存在关联,或者相互之间存在某种关系,那么这些元素在视觉上也应当有关联。

看上面这两张图片,第一张图片的女人和小孩,不太确定是什么关系,第二张图片的两人,更像母子,她们更加亲密。 我们也可以让代码有这种亲疏关系,来表达它们直接的关联程度。

我在Ramda的源码里找到一个find函数,作为我们的例子:

function find(fn, list) {
  var idx = 0;
  var len = list.length;
  while (idx < len) {
    if (fn(list[idx])) {
      return list[idx];
    }
    idx += 1;
  }
}
复制代码

现在我们利用亲密性,对其进行改造:

function find(fn, list) {
  var idx = 0;
  var len = list.length;
  var result;
  
  while (idx < len) {
    if (fn(list[idx])) {
      result = list[idx];
      break;
    }
    idx += 1;
  }
  
  return result;
}
复制代码

改造完毕,发现有什么区别了吗?一个方法让我们用两个回车分成了三个区域。变量声明的区域,中间操作过程的区域,返回值的区域。代码就有了它们亲疏关系。在视觉上更清晰。

当然使用卫句的方法也可以这样做:

function manToilet(person){
    if(isLady(person)) return;
    
    // dosomething
    
    return lighterPerson;
}
复制代码

只要是不同的逻辑区域,我们都可以利用回车表达亲疏关系。

不止在方法内部,在方法外,在我们的类内部,同样可以通过回车表达亲密性。

一个react的页面类:

class HomePage extends Component {
    
    onComfirm = () => {}
    
    onCancel = () => {}
    
    
    renderNavbar() { ... }
    
    renderContent() { ... }
    
    render() { ... }
}
复制代码

从方法的分布可以看出,渲染方法更亲密,在一块,响应方法更亲密,在一块。

我个人更习惯使用代码折叠块来区分类内部的不同成员

class HomePage extends Component {
    
    // #region 响应方法
    
    onComfirm = () => {}
    
    onCancel = () => {}
    
    // endregion
     
    
    // #region render
    
    renderNavbar() { ... }
    
    renderContent() { ... }
    
    render() { ... }
    
    // endregion
}
复制代码

项目级别的亲密性,就更加明显了,我们喜欢将同类型的代码文件,放在相同的目录下,如页面文件放在view文件夹下,工具文件放在util文件夹下。

对齐

对齐原则是指:“任何元素都不能在页面上随意安放。每一项都应当与页面上的某个内容存在某种视觉联系”。

对齐会让元素产生视觉联系。我们一直在用这原则,就是代码的缩进,缩进使我们同级别的代码元素,产生对齐。

那么我们怎么更好的利用对齐这个特性呢?我觉得在方法内,可以适当的减少嵌套。让同一级别的逻辑,尽量保持对齐。

过多嵌套会让代码的对齐不那么明显,如:

if (...) {
    if (...) {
        if (...) {
            if (...) {
            }
            else {
                if (...) {
                    if (...) {
                        
                    }
                }
            }
        }
    } else {
        if (...) {
        }
    }
}
复制代码

很显然,多层的if嵌套,会让代码逻辑不清晰,如果再向其中假如些循环嵌套,更糟了。对齐的特性,也消失不见。我们很难找到代码之间的关联。

减少嵌套的方法。

  1. 使用卫句。
  2. 使用switch。(让我们的对齐又回来了)
  3. 拆分代码

我们可以根据具体情况选择不同的减少嵌套的方案。

对比

对比的基本思想是,要避免页面上的元素太过相似。如果元素(字体、颜色、大小、线宽、形状、空间等)不相同,那就干脆让它们截然不同。

对比这两张图,第二张我们能明显区别出白人老头,和黑人小孩。如果他们不同,就让他们截然不同。

在代码中,我们不能让不同的代码字体大小不一致了。我们能做到的是,颜色和书写形式有所不同。

对于颜色,我们只需要在编辑器中,搞一下出色的颜色插件即可,让颜色来区分我们代码中的不同成员。

在这里随便截了一张vue编写的页面代码,人们对颜色是很敏感的,通过不同颜色,我们可以准确的区分出组件名,组件属性,组件的属性值,组件的变量属性值。

还有一种利用对比的方式,就是变量名的书写方式了。

wpsd8f.tmp.jpeg

这是一段C#代码,拿它举例是感觉它比较典型,代码描述了一个方法,方法里有很多的变量。我为各种成员变量制定了一种书写方式。

  1. 类的字段。下划线开头加驼峰命令法。
  2. 类的属性。帕斯卡命名法。名词
  3. 类的方法。帕斯卡命名法。动词/动词+名词。
  4. 局部变量。驼峰命名法。
  5. 类名。帕斯卡命名法。名词

我们规定了各种成员的规则,再来看我们的方法。Checkouted、Navigation是帕斯卡命名法,还都是一个动词,是方法。castPoint是局部变量。_initialPoint是类的字段。RestPoint是类的属性。

如果你熟悉某一套命名规则,你就可以通过对比,得到更多的信息量,进而快速熟悉和理解代码。

重复

重复原则倡导通过通过视觉元素的重复来更好的组织信息和增强作品的整体性。

上图第一张中,能明显看出穿粉衣绿裤的人是一拨人。这就是重复的力量。第二张图缺少重复,就略显杂乱。

重复在代码中的应用就更多了,刚才那段C#代码,也是用了重复的设计原则,通过不断的重复,表达出具有某种特征是某种成员类型。

再来回顾一下这段代码:

class HomePage extends Component {
    
    onComfirm = () => {}
    
    onCancel = () => {}
    
    
    renderNavbar() { ... }
    
    renderContent() { ... }
    
    render() { ... }
}
复制代码

通过render的重复,来表达带render字样的方法,都是渲染方法。通过on的重复,来表达on字样的方法,都是响应方法。以此来达到我们想传达某种信息的目的。

在项目中,我会经常使用Page,ViewModel等这样的单词给文件名作尾缀,宣称它在框架中处于什么样的位置。也是重复的一种用法。

结束语

以上就介绍完成设计原则在代码中的基本应用了。相信利用好设计原则,也可以帮助我们写出更加工整的代码。

关注下面的标签,发现更多相似文章
评论