Skip to content
New issue

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

架构金杂谈 #6

Open
langmao opened this issue Dec 25, 2015 · 4 comments
Open

架构金杂谈 #6

langmao opened this issue Dec 25, 2015 · 4 comments

Comments

@langmao
Copy link
Member

langmao commented Dec 25, 2015

  • 问:设计模式有什么作用
    答:封装变化点,将来这些方法变了,只改一处。
  • 问:为什么代码变量简写得如此销魂
    答:减少字节量,我的缩写都是压缩里不可能压缩掉的(言外之意就是不可能再简写了,所以编译器会很省空间)。
  • 问:以上两点带来的好处呢
    答:快速开发,我写东西,能比不用的人快40%
@coxo
Copy link
Member

coxo commented Dec 25, 2015

以下是本人的记录,作为补充
源自金大师的一行代码

o = $[EX]({
   play:EF // 默认启动震动时间
   width:....
}) 

主要是谈论EX和EF简写使用的原因

  • EX是extend
  • FE是false

展开讨论:

1.循序设计模式原则,封装变化点,将来这些方法变了,只改一处
2.减少字节量,我的缩写都是压缩里不可能压缩掉的
3.快速开发,我写东西,能比不用的人快40%

金的感想:
1、维护着想
2、将来修改很简单,只改一处,不用所有的js都改
比如我的extend我要扩展一下,改成我自己的方法,我只改一处

狼猫/会一/leo感想:
疑问:extend未来改变概率有多大? false改动的概率有吗?
观点:够用就行,命名就应该清楚明白,
例子:写IOS 那名字的长度,那些IOS 不是都跪了

@langmao
Copy link
Member Author

langmao commented Dec 25, 2015

  • 金大神的第一点没有错,甚至可以说是必要的,为此我们可以就 一下问题展开讨论(大熊绝对是“封装变化”的铁杆粉丝和殿堂级大神----大熊说两句@daxiongjun
    _设计模式在软件开发过程中的的应用_

  • 金大神的第二点我觉得是错误的,或者说是舍本逐末,如果真的用极限思维来思考的话,确实编译器(解释器)对

    var a;
    var long_long_long_longa;

    这两个变量的解析速度是有差异。为此我们可以就一下问题展开讨论(懂的大神求赐教)
    _程序编译,执行(词法分析,语法分析,字节码执行----这种问题会不会让人觉得很装x 😹)_

@langmao
Copy link
Member Author

langmao commented Dec 25, 2015

  • 金大师问题:为什么跨域不在后端实现呢,非要前端去实现,后端技术多成熟啊

@coxo
Copy link
Member

coxo commented Dec 25, 2015

很多都是根据业务场景来决定的。并不是说你想怎么搞就怎么搞的。解决方案这些东西。你能说那些是必要的吗?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants