104f22695e872d6d4965c3ce7b1cdf7.png
事情的开始是这样的
项目要重构UI，然而老孟的css功力很浅很浅，对sass更是一知半解。学习机会来了~~
情况不妙
原项目是用ionic搞得，框架本身提供了茫茫多的sass变量提供给开发者进行自定义主题，长下面这样：
ionicsass.png
梳理了一下老代码发现事情没那么简单，主要问题如下：
- 原开发者丝毫不理会官方方案，所有主题相关的样式均使用高权重选择器强硬覆盖。
- 所有主题样式全挤在app.scss一个文件里。
- pages各玩各的，缺乏通用样式，冗余代码太多。
- 老员工们并不怎么会ng，没有拥抱组件化，通用组件~~零
dark.jpg
规范的推进势在必行......
出于上述问题，修改官方提供的改变量方式可以扔一边了~~我的方案如下：
- 少覆盖多扩展，绕开问题1的坑。
- 制定规范防止问题2，问题3恶化。
- 至于问题4，放弃吧。想解决这个问题需要对其他员工进行培训，成本太高。介于公司性质和洒家的江湖地位，这事儿别想了。
关于方案1
其实方案1并不合理，但我一己之力难以改变其他组员的错误使用方式，这是一种将错就错的妥协。关于此事儿我一句也不想提。
关于方案2
所谓难者不会，会者不难。对不起，我是难者。（；´д｀）ゞ全写在app.scss显然不靠谱。老孟坚信好的项目是结构美丽的。谷歌一下如何布置sass的结构，推荐下面这篇影响力较大的文章，其他优秀文章不一一列举了。
https://www.sitepoint.com/architecture-sass-project
说得很细，由于ng本身的组件化特性，就没必要搞得像文中那么复杂了。暂定结构如下：
//main.scss单纯作为入口，引入所有文件。
// Modules and Variables
@import './modules/_all.scss';
//Base
@import "./base/_layout.scss";
//Cover
@import "./cover/footer"
解释一下：
modules文件夹放变量和函数们，简化写法，易于迭代。
base文件夹存放通用的碎片样式。比如居中之类的非业务性的写法。
cover是对ionic提供的组件的覆盖与扩展。其实叫components更合适，但angular对component的‘私有’样式另有写法，结合目前的状况（看问题一），干脆叫cover了。
剩下的工作就是往上搬砖了。
做个总结吧:
纯主观看法：
- 不做一票儿买卖,写一步想两步，考虑日后的迭代和扩展。
- 适度抽象，sass有变量和各种继承写法，纯css可以用属性和类名控制（我对此也没啥经验，说这话有点虚）。
- 业务是业务，组件是组件，框架是框架。分开管理别抱团。
- 勤看官网少吃亏！经验主义不可取。
硬广结尾：
这个官网不是我做的...
