We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The text was updated successfully, but these errors were encountered:
以下是本人的记录,作为补充 源自金大师的一行代码
o = $[EX]({ play:EF // 默认启动震动时间 width:.... })
主要是谈论EX和EF简写使用的原因
1.循序设计模式原则,封装变化点,将来这些方法变了,只改一处 2.减少字节量,我的缩写都是压缩里不可能压缩掉的 3.快速开发,我写东西,能比不用的人快40%
金的感想: 1、维护着想 2、将来修改很简单,只改一处,不用所有的js都改 比如我的extend我要扩展一下,改成我自己的方法,我只改一处
狼猫/会一/leo感想: 疑问:extend未来改变概率有多大? false改动的概率有吗? 观点:够用就行,命名就应该清楚明白, 例子:写IOS 那名字的长度,那些IOS 不是都跪了
Sorry, something went wrong.
金大神的第一点没有错,甚至可以说是必要的,为此我们可以就 一下问题展开讨论(大熊绝对是“封装变化”的铁杆粉丝和殿堂级大神----大熊说两句@daxiongjun) _设计模式在软件开发过程中的的应用_
金大神的第二点我觉得是错误的,或者说是舍本逐末,如果真的用极限思维来思考的话,确实编译器(解释器)对
var a; var long_long_long_longa;
这两个变量的解析速度是有差异。为此我们可以就一下问题展开讨论(懂的大神求赐教) _程序编译,执行(词法分析,语法分析,字节码执行----这种问题会不会让人觉得很装x 😹)_
很多都是根据业务场景来决定的。并不是说你想怎么搞就怎么搞的。解决方案这些东西。你能说那些是必要的吗?
No branches or pull requests
答:封装变化点,将来这些方法变了,只改一处。
答:减少字节量,我的缩写都是压缩里不可能压缩掉的(言外之意就是不可能再简写了,所以编译器会很省空间)。
答:快速开发,我写东西,能比不用的人快40%
The text was updated successfully, but these errors were encountered: