84669 person learning
152542 person learning
20005 person learning
5487 person learning
7821 person learning
359900 person learning
3350 person learning
180660 person learning
48569 person learning
18603 person learning
40936 person learning
1549 person learning
1183 person learning
32909 person learning
若优先保证代码规范性,会导致产生许多冗余字符促使增加不必要的体积,使用户体验降低。若优先保证体积最小而去压缩代码,就会损失基本的代码规范性,导致可读性差。这两个应该怎样权衡呢?
开发环境保证规范性提高开发效率和可读性,生产环境压缩。html一般是不用压缩的。一个页面gzip压缩后没多大。占一个页面流量最多的是图片。至于css、js,合并压缩是前端优化的基础。如果要求首屏大小,图片延迟加载才是更有效的方法。
减小体积压缩这些事情应该交给构建工具去做,所以跟代码规范应该不冲突啊
先规范了再说。。都2015年了,带宽没那么差了,不差那几k或几十k了
如果一开始没有规范,猿会说等写完了整理,然后,项目没有写完的时候。
这两者并没有矛盾。
开发时,自然要注重规范性。
运营时,自然要进行压缩合并。
谁会把dev代码直接扔上生产环境?
发布的时候肯定要压缩的啊,像css,js之类的,都压缩到单行里去,也有压缩html的,但是html压缩没多大意义,就那么大一点点。开发过程中当然要注意代码规范了,这个误不了多少事。
如果是前端的话,现在的一些自动化构建工具例如grunt等,都会自动帮你压缩再发布的,你开发环境中的代码不会被放到生产环境中,取而代之的是一个app.js之类的被压缩过的文件。如果不用这些工具,也可以自己将代码压缩之后重命名,但是不要忘记保留原来的代码以便以后修改,例如原文件是main.js,那么压缩之后就是main.min.js。
minify、变量混淆可以用专门的工具做 只要遵循特殊的命名准则 你也可以写一个混淆工具比如所有的类比如叫cls_mycls这些 然后约定代码中不能出现"cls_" + "mycls"这样的情况这样我只要全文查找cls_开头的字符串 然后编号替换 就可以得到a0 a1 b0 b1这样混淆后的css了
二者可以得兼 一个生产一个开发环境
开发环境保证规范性提高开发效率和可读性,生产环境压缩。
html一般是不用压缩的。一个页面gzip压缩后没多大。占一个页面流量最多的是图片。至于css、js,合并压缩是前端优化的基础。如果要求首屏大小,图片延迟加载才是更有效的方法。
减小体积压缩这些事情应该交给构建工具去做,所以跟代码规范应该不冲突啊
先规范了再说。。
都2015年了,带宽没那么差了,不差那几k或几十k了
如果一开始没有规范,猿会说等写完了整理,然后,项目没有写完的时候。
这两者并没有矛盾。
开发时,自然要注重规范性。
运营时,自然要进行压缩合并。
谁会把dev代码直接扔上生产环境?
发布的时候肯定要压缩的啊,像css,js之类的,都压缩到单行里去,也有压缩html的,但是html压缩没多大意义,就那么大一点点。开发过程中当然要注意代码规范了,这个误不了多少事。
如果是前端的话,现在的一些自动化构建工具例如grunt等,都会自动帮你压缩再发布的,你开发环境中的代码不会被放到生产环境中,取而代之的是一个app.js之类的被压缩过的文件。
如果不用这些工具,也可以自己将代码压缩之后重命名,但是不要忘记保留原来的代码以便以后修改,例如原文件是main.js,那么压缩之后就是main.min.js。
minify、变量混淆可以用专门的工具做 只要遵循特殊的命名准则 你也可以写一个混淆工具
比如所有的类比如叫cls_mycls这些 然后约定代码中不能出现"cls_" + "mycls"这样的情况
这样我只要全文查找cls_开头的字符串 然后编号替换 就可以得到a0 a1 b0 b1这样混淆后的css了
二者可以得兼 一个生产一个开发环境