开发中有一类“麻烦”是必须按照某种规则（思路）写代码，这类麻烦是不能省的。

sass让css实现模块化开发，值得注意的是模块化并不是把一个大文件分拆成几个小文件而已。依赖上下文的小文件拆出去不旦不能复用反而有害。看个例子a.scss：

%mod { … }
.mod-foo {
  @extend %mod;
  //…省略100行
}
//…省略1000行

将复杂的.mod-foo拆出去，a变成：

@import "b";
%mod {…}
@include foo;
//…省略1000行

b.scss为:

@mixin foo {

  .mod-foo {
    @extend %mod;
     //…省略100行
  } 
}

此时b依赖%mod，外部环境必须有%mod，在依赖很多的情况下b实际上难以维护。若进一步把通用的部分拆成c.scss：

%mod {…}

问题是在a里引c还是在b里引c？a里引的好处是一次引用，下面的代码包括引用的模块都可以用。b里引的话，a里及其它地方用到c的地方还要引c，这时就显得“麻烦”。这种“麻烦”不能省。模块的依赖显式声明出来是很有必要的。

再看另外一个案例，其中用了一套开源的font icon - ionicons，用的时候：

<span class="ion-heart"></span>

开源库总是会带有自己的前缀，如“ion-”。考虑到以后更换，通用和业务最好隔离开（反向依赖），在自己的项目里这样，用自己的前缀:

<span class=“ic-heart"></span>

css是:

@import "../ionicons/ionicons”;
.ic-heart {
  @extend .ion-heart;
}

随便打开一些知名网站，通常会看到这样的html:

<div class="search-panel-fields search-hp-fields search-common-panel”>

…
</div>

层叠的class名非常影响阅读代码。无非为了省事复用一些规则，更好的写法是：

<div class="search-panel”>

…
</div>

css的写法也许会“麻烦”些，将search-panel-fields, search-hp-fields, search-common-pane的通用部分抽成%common-panel：

%common-fields{
  //...省略
} 
%common-panel {
  //...省略
}

.search-panel {
  @extend %common-panel;
  @extend %common-fields;
}
.search-common-pane {
  @extend %common-panel;
}
.search-hp-fields {
  @extend %common-fields;
}

开发中有些“麻烦”是不能省的。看似简单的代码，值得再进一步反思一下。

扫码关注w3ctech微信公众号