復(fù)用性,維護(hù)性,可讀性
效率編程
作為一個小白的思索.
剛開始學(xué)的時候,是不怕重復(fù)的,
反倒是希望重復(fù)的.
因?yàn)槲乙由钣∠?進(jìn)行記憶, 所以如果有寫的機(jī)會,
我是愿意寫的.
后來基本會寫了之后,
就會發(fā)現(xiàn)總會出現(xiàn)好多重復(fù)性的東西.
比如 我每次寫一個html 都要有 一系列的基本結(jié)構(gòu)標(biāo)簽,
比如 每次寫 js 總會用到很多 for 循環(huán), if else , 或者每次獲取dom元素,
都要寫 document.getElementByClassName,
有段時間, 感覺很浪費(fèi)時間, 效率很低,
我就想, 能不能用 代碼提示來解決.
到今天用的是hbuilder , 也許我要改成 vs-code,
因?yàn)槠渌硕荚谟眠@個,,不過,可能是剛開始就用了hbuilder的原因,
我用的很舒服, 就是整個軟件的 ui丑了一點(diǎn)點(diǎn),
當(dāng)時,用hbuilder 對 常用的 一些結(jié)構(gòu), 比如for,if,還有好多一些, 都進(jìn)行了代碼提示的封裝.
當(dāng)然 hbuilder 本身對代碼提示做的也很好.
不得不說,這確實(shí)節(jié)省了我很大的時間.
這里有個小注意是,
剛開始封裝的提示, 使用起來會很慢, 因?yàn)闆]記住,而且相比習(xí)慣的碼字,似乎更慢.
而且知識點(diǎn)記憶起來都嫌累,何況還要記憶一些無關(guān)的.
但還是試著用了起來, 結(jié)果無一例外 熟悉了之后,絕對比原來的快.
也就是說, 假設(shè)熟練度最后會達(dá)到一樣的水準(zhǔn)時, 用提示絕對比 碼字要快.
后來就常聽說,要模塊化封裝.
為了復(fù)用性,維護(hù)性,可讀性.
首先,我覺得,復(fù)用性的實(shí)現(xiàn)是 最基本原理是,
變量的取值?
只要我 var a = 10 聲明一個變量,
那么 我可以在下面多次引用這個 a
如果該變量是個函數(shù) 那就 a();
這就完成了最基本的復(fù)用啊.
也就是說,我們想要完成復(fù)用,
首先就要封裝成一個變量.
一個可以訪問的變量.
所有的變量都可以訪問嘛?
什么是不能調(diào)用該變量的地方?
- 函數(shù)的限制
function fn () {
var a = 0
}
console.log(a);// 報(bào)錯
fn();
console.log(a);//報(bào)錯
函數(shù)內(nèi)部的變量, window中是無法訪問的.
(里層函數(shù)的變量,外層函數(shù)是無法訪問的.)
但函數(shù)內(nèi)部是可以訪問 window的.
依次可以實(shí)現(xiàn),變量私有,防止全局污染.
如何才能訪問函數(shù)內(nèi)部的變量?
需要在函數(shù)內(nèi)部返回一個 window 能夠訪問的接口.
可以用return 返回,用window的變量接收的方式
var a = (function () {
var b = 3;
return b
})();
console.log(a);// 3
可以是 在 函數(shù)內(nèi)部,把變量定義在 window上.
var a;
(function () {
var b = 3;
a = b;
})();
console.log(a);
可以在定義變量的時候, 直接定義在該函數(shù)身上.
(說實(shí)話,我碰到的這種用法挺少的.)
function name() {
name.a = "a";
}
console.log(name.a);// undefined , 因?yàn)楹瘮?shù)還沒執(zhí)行, name.a 還未被創(chuàng)建賦值.
name();
console.log(name.a);// "a"
或者也可以定義在原型鏈上,
原型鏈并非new才會創(chuàng)建.函數(shù)定義的時候,就已經(jīng)創(chuàng)建了.
通常是為了繼承,原型鏈上定義的一般是函數(shù)
function name() {
}
name.prototype.a = "a"
還有就是,返回的實(shí)例上, 需要用window的變量來接收該實(shí)例
function Name () {
this.a = "a"
}
var instance = new Name();
console.log(instance.a);
當(dāng)然也可以不用變量接收.
console.log(new Name().a);
但要記住,不用變量接收時,就無法完成復(fù)用啊!
- 對象的限制.
var item = {};
item.a = "a";
item 可以說是定義在了 window上,
但嚴(yán)格來講 a 不能說是定義在了window 上, 而是定義在了item上?
當(dāng)然我們可以通過 item 獲取 item.a
我想說的是,雖然歸根到底,應(yīng)該算是定義在了window上,
但如果找不到正確的路徑,也是無法訪問的.
- 存在于其他文件的限制.
另一個文件的變量,
如果不引用文件,就無法訪問該變量.
我說了句廢話,,
如果我想訪問另一個文件的變量怎么辦?
第一種,復(fù)制粘貼啊,我直接把代碼復(fù)制過來.
別笑, 作為一個小白, 我經(jīng)常這樣.
甚至我有想過,干脆把整個插件的js, 用代碼提示存起來,
需要的時候, 直接兩個提示代碼就能生成整個文檔.
我覺得這沒什么好笑的.
雖然還沒這么試過, 但應(yīng)該也是有一定的便利性.
第二種方式是,文件引入,
文件一旦引入就會擁有同一個window了.
就可以訪問該變量了.
當(dāng)我說想要實(shí)現(xiàn)復(fù)用的時候,
實(shí)際上,我是出于想減少一些重復(fù)性的勞動,
而我發(fā)現(xiàn)寫同一個項(xiàng)目的時候,
常常會書寫同樣的字符,
同樣的語句,
同樣的結(jié)構(gòu),
同樣的功能(或者類似的功能)
寫不同的項(xiàng)目的時候,
也會常常書寫同樣的字符,語句,結(jié)構(gòu),功能.
所以我要抽象出那些看似類似的部分,
分析那些類似的部分的概念到底是什么,
然后封裝成一個變量.
重復(fù)引用,就完成了復(fù)用.
但當(dāng)我們說為了效率編程,實(shí)現(xiàn)復(fù)用的時候,
一般是指可執(zhí)行的代碼的復(fù)用,
而不是 數(shù)據(jù)的復(fù)用.
我們可以把一些代碼封裝成函數(shù).
或者我們可以把所有的代碼 都看成是函數(shù).
var a = 0
可以看成是
var a;
function test () {
a = 0
}
test();
呵呵,是有點(diǎn)牽強(qiáng).
但這樣一個函數(shù),可復(fù)用性高嘛?
我們有一種下意識的判斷,感覺復(fù)用性不高啊.
感覺不會經(jīng)常用啊?為什么呢?這個感覺從何而來?
我想了一下,
首先是這個概念.
這個函數(shù)的概念是, 我讓 a = 0;
只適用于 變量 a 啊
我們可以改成
var a;
function test (a) {
a = 0
}
test(a);
咦? 感覺復(fù)用性強(qiáng)了一點(diǎn)?
這個概念變成了, 我傳的任何變量,都要變成0
適用的數(shù)據(jù)變廣,復(fù)用性就增強(qiáng)了?
那依照這個思路,
我們可以改成這樣?
var a;
function test(a) {
if(Array.isArray(a)) {
var len = a.length;
for(var i = 0; i < len; i++){
a[i] = 0;
}
}else{
a = 0
}
}
test(a);
這個概念就變成了,任何數(shù),或者任何數(shù)組的元素,都會變成0
復(fù)用性增強(qiáng)了嘛?
不知道,反正我覺得,想要判斷復(fù)用性強(qiáng)不強(qiáng),
首先應(yīng)該看他的概念,和他的需求.
如果這個需求很廣泛,概念復(fù)用性就會越強(qiáng)?
像 + - * / 這些概念的復(fù)用性就非常強(qiáng).
思而不學(xué)則殆,
思考一會兒
不行的時候,就要看別人的.
如何設(shè)計(jì)循環(huán)避免代碼重復(fù)褥符，提高代碼復(fù)用性
感覺這位在寫這一篇的時候,是跟我一樣的小白.
沒錯啊,
剛開始我接觸數(shù)組和循環(huán)的時候,也覺得能省好多重復(fù)性代碼.
也許應(yīng)該再換一個角度思考.
我們剛才在上面說到,概念才是能夠判斷復(fù)用性的關(guān)鍵.
實(shí)際上,根據(jù)經(jīng)驗(yàn)是這樣的.
我們再寫某些項(xiàng)目,某些代碼的時候,
我們有時,能夠感覺到,咦? 某些需求的類似.
這些需求的解決的背后,存在某種相同的東西.
我們只需要把這些東西抽象出來弄成概念,
再把這個概念,
弄成插件,就可以完成一個復(fù)用性相對高的代碼了?
這需要什么?
需要學(xué)會去觀察自己寫代碼的思路和概念,
我們寫代碼的時候,必然都可以翻譯成某些概念的吧?
或者說,我們寫一個項(xiàng)目的時候,
總是會存在一個思路的吧?
而不同的項(xiàng)目,總會有一些思路是類似的吧?
我們觀察這些需求,觀察這些思路.應(yīng)該是很有必要的.
或者我們也可以觀察自己寫的代碼,
如果我能發(fā)現(xiàn)我寫的不同代碼之間的重復(fù)的地方,類似的地方,
我就能抽象出來,
比如,我總用 if else? 或者getElementByTagName?
又或者我們可以問題為導(dǎo)向.
每次寫代碼的時候,不會總是一帆風(fēng)順,
總會遇到各種各樣的問題,
也許這些問題一直分析,一直抽象,能夠抽象出一些類似的地方?
其實(shí)常常有時候,我會遇到某些問題,某些需求,
但我無法提出正確的問題.
其實(shí)我感覺,這幾方面我都很懶.
先到這里?
不同的項(xiàng)目,需要的js 代碼不同,
有時需要代碼塊 a , 不需要 b
那就可以把 a 和 b 分成不同的文件.
作為一個小白, 剛開始,我很反感這種文件的引入,
感覺動作很大,而且很不熟悉.
現(xiàn)在覺得這還真是天然的模塊化.
第一種函數(shù)里的變量,
可以對我的代碼產(chǎn)生影響,但我有可能完全無法訪問.
第二種對象里的變量,
可以對我的代碼產(chǎn)生影響, 但我總有路徑可以訪問.
第三種, 只要引入了,就受到第一,第二種的影響.
我要轉(zhuǎn)變思路的是, 第三種才有可能是常態(tài),正常狀態(tài),
也就是多個文件的組合,或者將代碼分割成多個文件.
這樣我才能按需要隨意組合.
極端情形是,
我希望每個功能, 比如 function add (x,y) {return x + y};
就這一個函數(shù),我希望他都能拆分成一個獨(dú)立的文件.
為什么?
因?yàn)?按照拆分的思想,
終極狀態(tài)時, 最后我運(yùn)行的代碼中,
不存在我不需要的代碼,不需要不會運(yùn)行的代碼.一句都沒有.
不過很明顯,這樣做的話, 可能我的代碼里,可能會出現(xiàn)很多很多的引入.
滿篇都可能是 import
不過,終極想象是, 我們擁有類似webpack 構(gòu)建工具,
每個包,都會附帶依賴圖,
不需要我們自己去一個一個去添加?
并且最后會打包成一個完整的文檔.
而不是互相依賴的多個文檔.
上面的思路是,不停的拆分,
也就是顆粒度變小,降低復(fù)雜度,提高耦合度.
我個人覺得最理想的狀態(tài)是,所有的插件,所有的組件,所有的依賴,
我都非常的清楚,我明白每個細(xì)節(jié)的原理,我知道每個內(nèi)部的結(jié)構(gòu)設(shè)計(jì)思路.
甚至每個代碼我都能手寫出來.
但這是不可能的.(可能嘛?)
因?yàn)槿祟惖男畔⑻幚砟芰κ怯芯窒薜?
而且如果我必須知道,所有插件的內(nèi)部原理才能用這個插件的話,
那很明顯,這個學(xué)習(xí)成本太高了.
所以我們編程追求的另一個方向是,黑箱子,面向接口,高內(nèi)聚.
也就是, 我們只需要有哪些接口,每個接口可以放哪些參數(shù),怎么樣放參數(shù),
還知道最后的效果是什么.就可以了.
我們只需要知道通過某個接口,參數(shù)和效果之間的簡單粗暴的因果關(guān)系就可以了.
很明顯,這樣子會大大提高學(xué)習(xí)效率,使用效率.
也就是說, 最好是,封裝成, 內(nèi)部原理什么都不需要知道, 但操作起來特別方便.
效果還特別好.就可以了.
說著說著,感覺就是電腦和手機(jī)嘛.我給用戶提供一個iphone,用不著用戶會 編程,
不會編程,并不影響用戶用手機(jī).手機(jī)內(nèi)部的原理可以一概不知,但用戶知道操作和效果之間的因果關(guān)系.
按照這種標(biāo)準(zhǔn),最好的插件就是,傻瓜式操作,根本不用學(xué)習(xí)什么東西.
反正就是特別好用.
其實(shí)到現(xiàn)在為止我也有這個疑惑.
我總懷疑我算不算是個編程人員.
因?yàn)榭偢杏X,我壓根不理解所謂的"底層原理",
什么是底層原理呢?我發(fā)現(xiàn)縱向上永遠(yuǎn)都存在底層原理.
比如說,當(dāng)我是用戶的時候, 我只會打開瀏覽器看視頻,
現(xiàn)在我大概明白瀏覽器是個怎么回事, 知道有 html,css,js,
知道有dom, 有渲染,有網(wǎng)絡(luò)請求,
可你發(fā)現(xiàn)每個的背后都有所謂的底層,
比如瀏覽器的js引擎內(nèi)部是怎么回事?
渲染引擎是怎么回事?
可是我懷疑即使我知道這倆怎么回事,
還是會存在"底層原理",
操作系統(tǒng)的原理,或者還有更底層的.
如果從這個角度來講,
那些用word的也算不算是一種 編程人員?(應(yīng)該不算?)
問題很自然的就來了.
我們需不需要知道"底層原理"?
答案是需要的.但又需要分情況.
首先,按照我在學(xué)校學(xué)習(xí)的整個經(jīng)驗(yàn)來看,
從來都是先學(xué)理論基礎(chǔ),然后再學(xué)這個理論的應(yīng)用.
總是從基礎(chǔ)開始,從理論開始.
這樣子學(xué)習(xí)是對的,從某種角度來講也是最有效率的.
我們?yōu)槭裁葱枰?底層原理"?
首先,以一個插件為例, 我們深刻理解的他的內(nèi)部結(jié)構(gòu)和設(shè)計(jì)原理,
肯定對于我們正確,有效的應(yīng)用該插件是有幫助的.
特別是,有時候,我們會遇到這個插件的期望效果和實(shí)際效果不一樣的時候.
或者,總會遇到使用范圍的問題,
盡管文檔的操作說明里可能寫的"很完善",
但我們有時候還是要不停的去"試一試",
某些情況的時候, 會有怎么樣的特殊表現(xiàn),諸如此類.
你比如說,margin塌陷,
vertical-alighn的表現(xiàn).
光看文檔的時候,很難完全理解,或者很難完全掌握操作和效果之間的所有因果關(guān)系.
甚至我學(xué)習(xí)jq的時候也有類似的感覺.
此時我就感覺非常的"累",這種累是因?yàn)?我記憶這些因果關(guān)系的時候,
是沒有理論支撐的,或者說,我是硬背的,
我沒有一個更好的理論來解釋這個因果關(guān)系.
這個時候,知道一點(diǎn)"底層原理",就有助于我們解釋,理解.
到目前為止,
我的前端的學(xué)習(xí)過程,很明顯不是完全依照,先基礎(chǔ)理論,再 應(yīng)用這樣的模式.
常常是,先應(yīng)用,先學(xué)會怎么用, 知道是用來干什么的,
掌握差不多之后,再返回去理解他的底層結(jié)構(gòu)和設(shè)計(jì)原理是什么.
這樣的學(xué)習(xí)方式,實(shí)際上效率也挺高的.
而且從某種角度來講也更合理.
因?yàn)榭梢栽诓欢淼臅r候就可以用了.
知道越多的底層原理,我們就越能應(yīng)用的更好, 我們的應(yīng)用范圍就會越高.
但學(xué)習(xí)底層原理是需要學(xué)習(xí)成本的.
我們要解決一個問題,可能面臨兩個選擇,
一個是我理解了底層原理之后, 在去解決這個問題.
另一個是我找到別人設(shè)計(jì)的超牛逼的插件,組件,框架 只需要按照文檔傻瓜式操作,
我就能立馬解決這個問題.
你說我選擇哪一個?
我覺得必然要先選牛逼的插件啊!
因?yàn)?我面臨的實(shí)際選項(xiàng)其實(shí)是, 我是要先解決問題? 還是要先學(xué)習(xí)?哪個更重要.
我覺得既然用高效率的方式解決問題,能更省時間,必然應(yīng)該是先解決問題,
然后慢慢去研究怎么實(shí)現(xiàn)的.
就好像,有一把槍擺在我面前, 前面有個問題是老虎,
我是先一槍崩了它再說,還是先設(shè)計(jì)一個矛,在設(shè)計(jì)一個刀,在設(shè)計(jì)一個弓箭,
在研究一下火藥,在更深入研究一下制鐵技術(shù),最后再弄出一個槍來干掉那個老虎?
也許老虎都睡著了.
當(dāng)然了,我相信這也是絕大多數(shù)編程人員的選擇.
做出這個選擇很必然,但問題是,我用腳指頭想的(瞎猜的)是,
可能存在很多編程人員的思路就變了.
他的思路就變成, 我要針對這把槍去練習(xí)槍法.要百步穿楊.
或者變成,有沒有更好的槍?更好用的槍?
也就是,他不太可能再好好研究武器的歷史,槍的內(nèi)部構(gòu)造原理什么的.
(我可能也是這樣的)
但我的合理想象是, 知道槍的內(nèi)部原理,就相當(dāng)于學(xué)習(xí)內(nèi)功,
知道了內(nèi)功總是比較容易成為高手, 而且更容易適應(yīng)新出的招數(shù).
(如果想走的更遠(yuǎn),就必須學(xué)習(xí)底層原理,到到底什么所謂的底層原理就要另外思考了)
回到正題.
正題是什么?
我們之所以提到底層原理的原因是,
所有好的插件啊,文檔啊,他們的也會教你,
但他們確實(shí)好啊,就是想讓你用更少的學(xué)習(xí)成本,學(xué)習(xí)更傻瓜式的操作方式.
更傻瓜式的因果關(guān)系.
正題是,必然的一個現(xiàn)象是, 我會用,但我不知道其內(nèi)部原理.
肯定有啊,你敢說你用的所有的api 的背后結(jié)構(gòu)原理都了解的一清二楚?
我想說的是,
黑盒子,面向接口的編程是必須的.
換言之,我上面講的個人覺得的理想狀態(tài), 我知道所有插件的底層原理,然后再用,是不現(xiàn)實(shí)的.
(話題回來的好不自然,好牽強(qiáng).)
我想了想,想要面向接口,實(shí)現(xiàn)黑盒子,
我們就要定義好功能,定義好需求,定義好概念,
所謂的高內(nèi)聚,我猜是不是就是這樣的,
先進(jìn)行細(xì)的拆分,減小顆粒度,
然后根據(jù)功能,需求,概念進(jìn)行內(nèi)聚.封裝成整體,實(shí)現(xiàn)黑盒子.
上面的過程,先是降低顆粒度,然后內(nèi)聚生成的黑盒子的顆粒度又變高了.
這里就必須插入另一個話題了.
暫且稱為顆粒度的高低的問題.
顆粒度越低,其復(fù)用性就越強(qiáng).適用范圍越廣.
顆粒度越高,其目的性就越強(qiáng).適用范圍可能會縮小.
比如, for() if else ,這個算不算api? 我們假設(shè)算.
這個的復(fù)用性,適用范圍就太廣了,
對應(yīng)的基本概念是, 遍歷, 以及 如果.
再看數(shù)組的幾個方法 forEach every some reduce
嚴(yán)格來講, 這個是 通過 arr 和 for 循環(huán)組合而來的.
對應(yīng)的概念是, 對數(shù)組進(jìn)行遍歷操作.
對數(shù)組進(jìn)行遍歷操作后要么篩選,要么判斷,要么返回某個值.
這個顆粒度變高了點(diǎn), 但適用范圍依然非常的高.
我們現(xiàn)在想干什么? 想找出什么決定一個插件,功能的適用范圍?
