JavaScript完整性编程(纯属个人想法)
何谓完整性编程,是指照这个逻辑模式写,写出的代码逻辑性完整,没有或很少不可预测的bug出现,就算出现了bug,也知道是哪个逻辑环节出现bug。
MVVM双向绑定的,它的编程模式就是完整性编程的一种。
我们先不讨论这。我们从很原始的jQuery操作DOM开始。
实例1.
http://knockoutjs.com/examples/cartEditor.html
这个案例用jQuery思路怎么写?
首先承认MVVM思路的确代码减少很多。但我们暂时不用它。
首先Product依赖于Category,price和Quantity和Subtotal依赖于Product。
我 们不必整个思路出来后,才开始敲代码,因为很可能你已经过度设计了。所谓过度设计,就是你想得很美好,实现起来如果碰到一个隐藏的语言bug,或者框架 bug,或者业务bug,你就瞎了,你的美好设计很可能要推倒重来,这就是古老的软件工程CMMI瀑布式开发的弊端,优端也有啦,后面说,但在现实里总的 来说是弊大于利。CMMI只是理论派,它只假设你在完美环境下编代码。实用性当然打不过实践出来的极限编程。
我们更不必一点思路也没有,就开始敲代码。这样只会令你沮丧。
所以,中庸思路出来了。直觉告诉你,不就是,在页面加载时,初始化Category;在选好Category时,初始化Product;在选好Product时,初始化price和Quantity和Subtotal。对,思路很粗犷,说错也错不到哪。
于 是你,啪啦啪啦敲好了代码。接着你开始测试,发现select没出现啊,呃是UI忘记添加上去了。又啪啦啪啦。嗯,UI出现,选好Category时,初 始化Product;在选好Product时,初始化price和Quantity和Subtotal。嗯,很好很好。
你又开始测试了,我填好所 有数据,当我重新选Category后,price和Quantity和Subtotal都没变,这会让用户觉得很怪异。我应该重置 Product,price和Quantity和Subtotal。嗯,啪啦啪啦,在选好Category事件里,加上重置代码。
呃,你发现还有 个Add product功能没实现。直觉告诉你,如果Category,Product,price,Quantity,Subtotal是一个行,Add product就是添加一行而已。Yes,you are right!啪啦啪啦,嗯,增加了一行,测试一下,可是为什么Category没有下拉列表,呃,是我没有初始化, 你又啪啦啪啦,在点击Add product事件里,加上Category初始化代码。
。。。。
。。。。
。。。。
你发现,你处于一个轮回中,首先你有一个粗狂的编程思路,当然能实现功能,但功能里有隐患(隐藏着bug)。隐患靠测试来发现,或者功能上线了用户反馈来发现(此时修复bug的代价高出n倍http://news.cnblogs.com/n/143130/)。 于是你的功能不变,但隐患没了,也意味着你的代码越来越一团糟。尽管你学了n多设计模式,但别指望没经验的你,能一开始预测到用哪种设计模式,从而后面优 雅地添加代码。也别指望经验丰富的你,能预测到用哪种设计模式,后来发现弄巧成拙了(当然概率比新手低了,但这个概率可以忽略不计)。
你要跳出这个轮回。
你 不想写好的功能带有不可预测的bug,允许有bug,但可预测。就像,关系型数据库理论,不同表之间的字段,可以用主键外键形成约束。比如表1有字段 a,b,c;a是主键。表2有字段b,d,e;b是主键,同时也是表1字段b的外键。你删除了表1里的数据,表2里的数据也要自动删掉一些。你修改了表1 里的数据,表2里的数据也要自动修改一些。
然后呢,数据库的主外键约束,就是为了保持数据的完整性,我们看到这是一种双向绑定。用到JavaScript编程里面,就出现了MVVM思想,这也是一种双向绑定。但,再次重复,这只是JavaScript完整性编程的一种。
第二种JavaScript完整性编程思路,我的狗皮膏药,可以粉墨登场了。
当然,保持粗狂的编程思路是对的,保持单元测试也是对的,还有要保持的是同事的交流,一个人闷声敲代码,不出功能,容易恼怒泄气。
c依赖b,b依赖a,我怎么才能修改a时,也修改了c,除了双向绑定,还有其它思路吗?
有,三向绑定,四向绑定,五向绑定。。。。。全向绑定。
在这个例子就是,c依赖b,b依赖a,c依赖a,a依赖c,b依赖c,a依赖b。
那么,如何创建全向绑定。
请听下回分解。
下回预告:
浏览器对DOM修改的实时渲染。
MVVM双向绑定的,它的编程模式就是完整性编程的一种。
我们先不讨论这。我们从很原始的jQuery操作DOM开始。
实例1.
http://knockoutjs.com/examples/cartEditor.html
这个案例用jQuery思路怎么写?
首先承认MVVM思路的确代码减少很多。但我们暂时不用它。
首先Product依赖于Category,price和Quantity和Subtotal依赖于Product。
我 们不必整个思路出来后,才开始敲代码,因为很可能你已经过度设计了。所谓过度设计,就是你想得很美好,实现起来如果碰到一个隐藏的语言bug,或者框架 bug,或者业务bug,你就瞎了,你的美好设计很可能要推倒重来,这就是古老的软件工程CMMI瀑布式开发的弊端,优端也有啦,后面说,但在现实里总的 来说是弊大于利。CMMI只是理论派,它只假设你在完美环境下编代码。实用性当然打不过实践出来的极限编程。
我们更不必一点思路也没有,就开始敲代码。这样只会令你沮丧。
所以,中庸思路出来了。直觉告诉你,不就是,在页面加载时,初始化Category;在选好Category时,初始化Product;在选好Product时,初始化price和Quantity和Subtotal。对,思路很粗犷,说错也错不到哪。
于 是你,啪啦啪啦敲好了代码。接着你开始测试,发现select没出现啊,呃是UI忘记添加上去了。又啪啦啪啦。嗯,UI出现,选好Category时,初 始化Product;在选好Product时,初始化price和Quantity和Subtotal。嗯,很好很好。
你又开始测试了,我填好所 有数据,当我重新选Category后,price和Quantity和Subtotal都没变,这会让用户觉得很怪异。我应该重置 Product,price和Quantity和Subtotal。嗯,啪啦啪啦,在选好Category事件里,加上重置代码。
呃,你发现还有 个Add product功能没实现。直觉告诉你,如果Category,Product,price,Quantity,Subtotal是一个行,Add product就是添加一行而已。Yes,you are right!啪啦啪啦,嗯,增加了一行,测试一下,可是为什么Category没有下拉列表,呃,是我没有初始化, 你又啪啦啪啦,在点击Add product事件里,加上Category初始化代码。
。。。。
。。。。
。。。。
你发现,你处于一个轮回中,首先你有一个粗狂的编程思路,当然能实现功能,但功能里有隐患(隐藏着bug)。隐患靠测试来发现,或者功能上线了用户反馈来发现(此时修复bug的代价高出n倍http://news.cnblogs.com/n/143130/)。 于是你的功能不变,但隐患没了,也意味着你的代码越来越一团糟。尽管你学了n多设计模式,但别指望没经验的你,能一开始预测到用哪种设计模式,从而后面优 雅地添加代码。也别指望经验丰富的你,能预测到用哪种设计模式,后来发现弄巧成拙了(当然概率比新手低了,但这个概率可以忽略不计)。
你 不想写好的功能带有不可预测的bug,允许有bug,但可预测。就像,关系型数据库理论,不同表之间的字段,可以用主键外键形成约束。比如表1有字段 a,b,c;a是主键。表2有字段b,d,e;b是主键,同时也是表1字段b的外键。你删除了表1里的数据,表2里的数据也要自动删掉一些。你修改了表1 里的数据,表2里的数据也要自动修改一些。
然后呢,数据库的主外键约束,就是为了保持数据的完整性,我们看到这是一种双向绑定。用到JavaScript编程里面,就出现了MVVM思想,这也是一种双向绑定。但,再次重复,这只是JavaScript完整性编程的一种。
第二种JavaScript完整性编程思路,我的狗皮膏药,可以粉墨登场了。
当然,保持粗狂的编程思路是对的,保持单元测试也是对的,还有要保持的是同事的交流,一个人闷声敲代码,不出功能,容易恼怒泄气。
c依赖b,b依赖a,我怎么才能修改a时,也修改了c,除了双向绑定,还有其它思路吗?
有,三向绑定,四向绑定,五向绑定。。。。。全向绑定。
在这个例子就是,c依赖b,b依赖a,c依赖a,a依赖c,b依赖c,a依赖b。
那么,如何创建全向绑定。
请听下回分解。
下回预告:
浏览器对DOM修改的实时渲染。
合乎自然而生生不息。。。