本文由大漠根据Hugo Giraudel的《Understanding Reference Boxes for CSS Shapes》所译，整个译文带有我们自己的理解与思想，如果译得不好或有不对之处还请同行朋友指点。如需转载此译文，需注明原作者相关信息http://www.sitepoint.com/keep-sass-simple/。
——作者：Hugo Giraudel
——译者：大漠
还有两个月时间，我使用Sass就有两年时间了。几乎每一天，在工作中，在家里，在项目中，都有人问我，怎么更好使用Sass。很高兴他们这么相信我，每天能为他们提供帮助，我感到非常高兴。
有些需求是合理的，有些需求是烦死人的。嘿嘿，我们可以从任何地方开始。也有些是抽象的。每个人都希望使用Sass能变得更简单（其他预处理器也在做这样的事情）。包括我在内，我也一直在这么做。
让我们来优化
那天我被问及到如何做到这点：
.class {
width: 20px;
}
.other-class {
width: em(.class:width);
}
基本上,使用em()函数将.class宽度转换到.other-class。仔细想想，在Sass中如果离开上下文，要将px单位转换成em单位，其实蛮困难的，而且这里还要从一个选择器引值到另一个选择器中。
甚至Stylus——这是很出名，非常强大的一款预处理器。他也做不到。充其量，只能在相同的代码块中引用值(也就是属性查找)。显然Sass要保守得多，他是做不到的。
注：如果你曾经也想要这样做，这并不是一件什么坏事。因为有很多人都有过这样的想法，你只不过是其中的一位而以。
我们可以做的
好吧，让我们接受上面的需求在Sass中使用确实是一个错误。你想看一个更有争议性的示例吗？Sass 3.4新增了一个新的功能特性，就是促进选择器传递的函数。这些特性注定了Sass能像处理list一样处理选择器，比如selector-nest()，selector-replace()等等。
尽管如何努力，至今我还没有找到一个合理的用例来说明选择器函数。有很多人在Twitter上用这些示例试图来说服我：
//Sass 3.40.rc.3
@mixin context($old-context, $new-context) {
@at-root #{selector-replace(&, $old-context, $new-context)} {
@content;
}
}
li {
float: left;
ul {
display: none;
@include context('li', 'li:hover') {
display: block;
}
}
}
编译出来的CSS:
li {
float: left;
}
li ul {
display: none;
}
li:hover ul {
display: block;
}
我同意这么做是一个很聪明的方法，但我并不觉得这是一个简单的方法。我认为他把事情整得更为复杂。我觉得不应该在任何地方让代码变得复杂化。
为什么不像这样写呢？
li {
float: left;
ul {
display: none;
}
&:hover ul {
display: block
}
}
现在这样就简单了。这样是可以理解的。我觉得有时候我们用的东西，我们只知道他的存在，并不是因为我们应该使用它们。
我们怎么在这里
在某种程度上，我觉得非常惭愧。我使用Sass做了一些疯狂的事情(例如这里和这里)。向大家推荐他的特性，可能没有足够掌握好这些技术，这些技术大多是都还只是实验阶段。
我是这不是很明显。当你写了十几于的Sass代码，却只输出了几行的CSS代码，你应该觉得这个Sass是有问题的。让人觉得意外的是，这种带有凝问的Sass代码依然还在生产中使用。
就像你给人太多权利，他就会滥用这些权利。更糟糕的是，他可能还会想要更多的权利。就像我们使用CSS预处理器一样，变量不够用，就有了混合宏mixin。有了函数。也有了数组。我们还在想要更多。但从未停下脚步来思考我们在做什么，我们为什么要这么做。
我也没有停下脚步来做思考，直到我将以前用到的CSS经验与一些没有开发经验的人员共享时，我才发现，我这样疯狂的做法并不是一个很好的选择。很高兴，我意识到了这点。
我们应该一起放弃Sass？
这一点不是这篇文章要说的，特别是Sass有什么毛病。你应该听说过这么一句话：
Preprocessors do not output bad code. Bad developers do.
当你知道如何使用Sass和如何不使用Sass时，Sass是一个有用的工具。在使用混合宏或函数数，有一些人认为使用Sass绝对没有错。即使是复杂的，只要他们不要搞得太复杂，那么复杂就变得不复杂了。
只要你控制的妥当，嵌套并没有什么不好。就我个人而言，我并不太喜欢嵌套，因为他让代码变得更难阅读。
当伪类和伪元素出现时，我非常的喜欢他们，但我认为，很快他们就会在嵌套中乱用，像下面的示例，摘自这篇文章：
.tabs {
.tab {
background: red;
&:hover {
background: white;
.tab-link {
color: red;
}
}
.tab-link {
color: white;
}
}
}
对于我来说，我宁愿多写一点：
.tabs .tab {
background: red;
&:hover {
background: white;
}
}
.tab-link {
color: white;
.tabs .tab:hover & {
color: red;
}
}
而且你知道吗？第一个示例用了176个字符，而第二个示例只用了152个字符。所以深层嵌套并不一定适合。
它的乐趣
是的，它是非常有趣的，我也知道这点。我写了一个Json解析器，输出Sass，可以按位运算字符，只不过不是SCSS。做这个事情的过程，它是非常有趣的。
做这样的工程不仅有趣，而且也很有用。在做这些事情的时候，我意外的发现了Sass的一些小Bug(#1090、#1265)。此外，我理擅长用Sass做一些意想不到的事情。每个项目只定义三个变量并不是件好事。但你推动的事情变得更有意义。
但你需要在哪里结束。你需要知道，你做的事情走得有多远，怎么控制你的代码。我差不多花了两年的时间和在一个大型的项目中实践自己的想法。一切注定了不是什么都能用，在生产环境上并不是可以让你来做实验。这样不只是带来错误，还会带来很大的危险。
比如，我在考虑使用@extend来控制跨Media Queries，我们应该要学会变通。我把这一部分做为DoCSSa的一部分。可以做到自行引用。的确是这样，除了打破层级，使用%placeholder来做扩展是最好的，因为CSS的移来移去难免会出问题。
这种技术是一种实验。它不是用于一个大型的框架中，我想可以帮助大家解决一些实际需求。用于生产这是不应该的，至少还没有考虑周全，没有意识到用上将产生的后果。然而，这种方式还是用上去了。
结论
保持不断地去实验。不要停止对Sass的学习，他是令人敬畏的。只要在真实的项目中，你知道自己在做什么。最重要的是保持事情的简单。少即是多。
译者手语：整个翻译依照原文线路进行，并在翻译过程略加了个人对技术的理解。如果翻译有不对之处，还烦请同行朋友指点。谢谢！
如需转载烦请注明出处：
英文原文：http://www.sitepoint.com/keep-sass-simple/
中文译文：http://www.w3cplus.com/preprocessor/keep-sass-simple.html