“我们都经历过重构app,将每个页面分配给团队中的一个人，实现协同开发，但是页面的结构和样式，每个人都会按照自己的方式来实现，这样就很不方便团队的管理，每个人写的都不一样，代码管理困难，您是否有用于创建和实施SASS项目的建议，或者技巧，博客之类的？”
我曾经也有过这样的苦恼，试图让一大群开发人员在没有现有代码标准或风格指南的情况下达成共识，现在我觉得你最好的选择就是先构建标准框架。但是这样可能和应用程序的当前部分之间存在巨大差异，但是在后续的开发中，无论是修复错误还是重构，你都可以问“这符合我们的CSS标准吗？”
第一步
我们必须了解什么是模块化CSS,以及他的好处是什么？不是自己吹嘘。我的这篇演讲可以有助于开发人员更好的理解它的概念。除此之外，我还会向团队推荐SMACSS书籍。 我很幸运能让一位经理开办一个强制性的读书俱乐部，团队中的每个人都必须阅读一本书并参加会议讨论。
第二步
一旦围绕模块化CSS的优势达成某种程度的共识，就可以将您团队的代码标准整合在一起。您既可以自己编写，也可以采用其他团队的。 我强烈推荐Harry Robert的CSS指南，或许补充了Hugo Giraudel的Sass指南。
我一直在为Tempest制作CSS标准文档，我对此感到非常满意。 这是一个很不情愿的工作，试图记录和标准化几年的现有代码实践。 如果我从头开始，我可能会很难切换到BEM命名约定和StyleLint默认格式规则。 不是因为它们是最好的标准，而是因为它们是既定标准，更容易达成一致。
第三步
创建模式库，记录您的模式并将其列在中心位置有两个原因：首先，它可以帮助您的设计人员查看已存在的模式并避免重复。 其次，它可以帮助您的开发人员开始考虑可重用模块与独特页面。
关于通用的Sass技巧：
- 多使用mixins,【Use mixing instead】;
- 尽可能的使用变量，理想情况下，您几乎没有在Sass文件中看到硬编码的数字。 这样可以更容易地避免幻数，并且在代码审查提供方便。
- 将变量保存在中央_variables.scss文件中，以便于查找，并帮助团队记住Sass中的变量是全局变量。
- 使用main.css文件来负责加载其他Sass文件， 这有助于鼓励您的团队编写更小，更好的范围Sass文件并避免膨胀。
- 理性情况下，每个模块都应该独立，不受其他模块的影响。 如果每个模块都有自己的Sass partial，那么强制执行此操作的一种方法是随机更改部分加载的顺序。如果这个规则被打破，那么你模块是有漏洞的。
这是一个非常广泛的主题，有许多截然不同的观点。 最重要的是让您的团队同意标准，无论标准是什么。 在一天结束时，你不能阻止一个开发者去做一些非团队标准的事，但是团队有了统一的标准后管理团队的代码规范就容易多了。
