js代碼結構設計（JavaScript框架設計）

本文目錄一覽：

• 1、javascript框架是什麼意思？有什麼作用？怎麼理解？最好舉個例子
• 2、js編程: 根據搜索值過濾樹結構
• 3、如何寫出規範的JavaScript代碼
• 4、什麼是js框架？
• 5、用JS設計一個頁面,在頁面上顯示信息”現在是XXXX年XX月XX日XX點XX分XX秒(星期X),歡迎您到訪我的站點”.
• 6、如何設計一個基於Node.js和Express的網站架構

javascript框架是什麼意思？有什麼作用？怎麼理解？最好舉個例子

淺談js框架設計 在這個JavaScript框架隨處亂跑的時代，你是否考慮過寫一個自己的框架？下面的內容也許會有點幫助。

一個框架應該包含哪些內容？

1.語言擴展

大部分現有的框架都提供了這部分內容，語言擴展應當是以ECMAScript為基礎進行的，不應當依賴任何宿主環境，也就是說，作為一個框架的設計者，你應當保證你的語言擴展可以工作在任何宿主環境中，而不是僅僅適合瀏覽器環境。你必須保證把它放到WScript,SpiderMonkeyShell,Rhino Shell,Adobe ExtendScript Toolkit甚至FlashActionScript等環境中都能正確的工作，舉個現實一點的例子setTimeout不可以出現在其中，你也不能用XMLHTTP載入腳本運行，儘管它們看起來很貼近語言。保持這一部分的獨立性可以讓你方便的移植你的框架到其他宿主環境下。　

2.數據結構和演算法

JS本身提供的內置對象非常有限，很多時候，框架應該提供一些數據結構和演算法來幫助使用者更好的完成邏輯表達。但我認為隨便翻本數據結構或者演算法書用JS挑幾個實現了加到框架中是不負責任的，多數數據結構應當以庫的形式存在而非框架。框架中的數據結構應該足夠常用而且實現不是非常複雜的，可以考慮的如集合、哈希表、鏈表、有序數組以及有序數組上的二分搜索。對JS來說，對象是一個天然的字元串哈希表，而集合很容易在哈希表上實現，因此只需要處理掉Object的內置方法，我們就可以實現一個高效的集合或哈希表。

3.DOM擴展

JS主要應用於Web開發，目前所有的框架也都用於瀏覽器環境，那麼，瀏覽器端環境里重點中的重點DOM當然也是框架的擴展目標了，如果一個框架不提供DOM的擴展，那麼其實基本沒什麼用處了。需要注意的是，DOM擴展也有w3c的標準可依，所以，不要嘗試為各種瀏覽器做一些奇怪的擴展，比如FF下面的element們的prototype，框架的編寫者應當無視它們。DOM擴展的主要任務之一是兼容性，不同瀏覽器上的DOM實現相差很多，框架必須消除這些實現帶來的差異，提供統一的訪問方式。當然，做為框架，應當提供一些更為方便的介面，將宿主提供的DOM對象用js對象封裝是個不錯的想法，但是同時這也很可能會造成內存泄露，所以做這事之前，了解內存泄露是必要的。實際上，自己想像的擴展遠不如W3C的設計，比如如果你能更完整地實現XPath，你就能比JQuery做的更好。

4.AJAX擴展

大部分現有框架出現的原因都是因為AJAX，所以如果你想設計一個受歡迎的框架，AJAX是必須要做的。跟DOM擴展很相似，AJAX擴展的主要任務是兼容和內存泄露，對AJAX的核心組件XMLHttpRequest對象，必須在IE6中使用ActiveX創建，而ActiveX又有各種版本，而隨之而來的內存泄露和兼容性變得非常麻煩，比如：事件函數名大小寫、this指向、事件函數的null賦值。處理好這些兼容性的基礎上，可以做進一步的工作，提供一些常用的實現。應該指出的是，除非你確定你提供的介面比原來的更好，否則不要改變原來的XMLHttpRequest對象的介面，比如寫一個Request函數來代替open和send，如果你不清楚W3C的專家們為什麼這麼設計，請不要把他們想像成傻瓜。我想自己另外寫一個兼容且內存安全的XMLHttpRequest加入到自己框架的命名空間里，使它從外部看上去跟W3C描述的XMLHttpRequest一模一樣是不錯的辦法，對XMLHttpRequest我認為唯一可以考慮的修改是提供onsuccess事件。當然針對一些複雜功能的AJAX擴展也是可行的，比如HTMLHttpRequest類似的擴展可以讓AJAX初學者喜歡你的框架。

5.效果

時間效果是最能刺激用戶神經的，漸隱、緩動、滑動、顏色漸變這些都很不錯，其實技術難度也不是很高。拖動效果則是瀏覽器中一個很重要的效果，用滑鼠事件來模擬本來很容易，不過兼容和setCapture也是很麻煩的事情。這一部分內容量力而為就可以了。

7.腳本管理

因為大家非常喜歡C++風格的include或者JAVA風格的import，很多框架提供了基於AJAX的腳本管理，不過同步載入的效率問題是巨大的。之前我們曾經作過各種嘗試，希望找到一個瀏覽器中不用XMLHTTP載入外部js的方法，但是最後得出的結論是：不可能。

關於這個，略微思考就可以知道，Java C++ C#都是編譯型語言，include 和import都是編譯期處理，在js中做到類似的事情是不太可能的。為了實現類似的功能，我想我們可以利用服務端程序或者編寫一個文本工具來實現。

YUI將所有的js文件依賴關係提取出來的做法是可行的，不過這不能算是include的實現方式了，維護依賴關係不是一件很簡單的事情。

8.控制項

EXT的成功告訴我們：提供優質的控制項才是框架的王道。你不能指望優質的擴展會吸引更多使用者。多數人只關心如何快速完成手邊的工作。當然不是所有框架都要提供這部分內容。控制項好壞取決於能力和美工，不過至少要保證框架里的控制項不會內存泄露。

框架設計的若干原則：

1.不要做多餘的事

對這框架設計來說，我認為一個非常必要的原則就是不要做多餘的事情，舉個極端的的例子：

function add(a,b)

{

return a+b;

}

這樣的代碼如果出現在框架中，就是個十足的笑話。不過大多數時候，事情不是那麼明顯，很多框架試圖用某種形式在JS中”實現”OOP，但是實際上，JS本身是OO的（ECMA262中明確指出來的，不像某些人所說是基於對象云云）只是有一些語法跟Java等語言不同。那麼顯然這些OOP的”實現”其實是跟上面的例子一樣的道理。另一個例子是Array.prototype.clone

Array.prototype.clone=function(){

return this.slice();

}

2.慎用prototype擴展

很多框架利用修改原生對象的prototype來做語言擴展，但我認為應當小心地看待這件事，毫無疑問這將造成一定的命名污染，你無法保證框架的使用者或者與你的框架共存的其他框架不會使用同樣的名字來完成其他的事情。特別需要注意的是，Object和Array這兩個對象的prototype擴展格外的危險，對Object來說，如果Object被修改，那麼框架的使用者將無法創建一個未被修改的乾淨的對象，這是一個致命的問題，尤其如果你的使用者喜歡用forin來反射一個對象的屬性。Array.prototype修改的危險來自js一個不知有意還是無意的小小設計，對原生的Array來說，任何情況下for和forin的遍歷結果是相同的，而因為無法控制自定義的屬性是不可枚舉的，任何Array.prototype的修改都會破壞這種特性。一方面，我認為不應當推薦用forin遍曆數組，這其中包含著錯誤的語義。另一方面，框架的設計者必須尊重這些使用者，因為對於ECMA所定義的語法而言，它是正確的做法。其中包含著這樣一個簡單的事實：假如你的框架中修改了Array.prototype，那麼一些之前能正確工作的代碼變得不可正確工作。

直接修改prototype看上去非常誘人，但是在考慮它之前應當先考慮兩種可能的方案：

(1)函數

提供一個以對象為第一個參數的函數比如 Array.prototype.each =

function ForEach(arr,f)

{

if(arr instanceof Array)/*…*/;

}

(2)繼承

以return的形式繼承一個內置對象 比如考慮Array.prototype.each=

function ArrayCollection()

{

var r=Array.apply(this,arguments);

r.each=function(){/*……*/};

return r;

}

套用一句名言，不要修改原生對象的prototype，除非你認為必要。不過修改原生對象的prototype確實有一些特殊的用途（就是”必要的情況”），主要體現在2點：文字量支持和鏈式表達。舉一個例子可以體現這兩點：

var cf=function f(a,b,c,d)

{

/*……..*/

}.$curry(3,4).$curry(5).$run();

如果希望實現類似上面的表達方式，可能就需要擴展Function.prototype，權衡一下的話，如果你認為命名污染的代價是值得的，那麼也是可以提供給使用者的。

一個比較討巧的辦法是把選擇權利交給使用者，提供一個擴展器：

function FunctionExtend()

{

this.$curry=function(){/*……*/};

this.$run=function(){/*……*/};

}

如果用戶喜歡可以FunctionExtend.apply(Function.prototype); 如果不喜歡擴展 則可以

var r=function(){/*……*/};

FunctionExtend.apply(r);

3.保持和原生對象的一致

不知你有沒有注意到，內置對象Function Array等都有這樣的性質：

new Function()跟Function的結果完全一致（String Number Boolean這種封裝型對象沒有這樣的性質）

如果框架中提供的類也具有這種性質，會是不錯的選擇。這僅僅是一個例子，如果你注意到了其他細節，並且讓框架中的類和原生對象保持一致，對使用者來說是非常有益的。

4.尊重語言 尊重用戶

編寫框架應該尊重依賴的語言環境，在對原有的元素修改之前，首先應該考慮到原來的合理性，任何語言的原生環境提供的都是經過了精心設計的，在任何修改之前，至少應該考慮這幾點：效率、命名規範、必要性、與其他功能是否重複。如果你沒有付出至少跟語言的設計者相當的工作量，你的做法就是欠考慮的。

編寫框架也應該尊重用戶的所有習慣，將編寫者的喜好強加給使用者並不是框架應該做的事情。框架應該保證大部分在沒有框架環境下能運行的代碼都能在框架下正常工作，這樣用戶不必為了使用你的框架而修改原有的代碼。

5.規範命名和使用命名空間

減少命名污染可以讓你的框架跟其他框架更好地共存。很多框架使用了命名空間來管理，這是良好的設計。命名應該是清晰且有實際意義的英文單詞，如前面3所述，為了保持和原生對象的一致，命名規則最好貼近原生對象，比如類名第一字母大寫，方法名用駝峰命名。捎帶一提prototype中的$實在是非常糟糕的設計，無法想像$出現的目的僅僅是為了讓使用者少寫幾個字母。這種事情應該交給你的用戶在局部代碼中使用

js編程: 根據搜索值過濾樹結構

1，不要著急看一些複雜網頁效果的代碼，這樣除了打擊自信心，什麼也學不到。2，別急著加技術交流QQ群，加牛人QQ。如果找張三丰交流武功。3，看網上什麼多少天精通JS，啥啥啥從入門到精通，這種教程直接跳過吧，太多的事實證明，以一種浮躁的心態去做任何事都會以失敗而告終。4，千萬別去弄啥電腦培訓，花了錢和時間不說，關鍵是學不到東西。本來買兩本好書自學3個月能學會的，他們硬是能折騰兩年。JavaScript DOM編程藝術學習Javascript用《JavaScript DOM編程藝術》來入門最好不過了，老老實實看兩遍，看完了就會對JS有一個大概的了解，整本書都圍繞著一個網頁效果例子展開，跟著老老實實敲一篇，敲完之後，會發現這個效果不是常在網頁中看到么，發現自己也能做出來網上的效果了。JavaScript高級程序設計有的書是用來成為經典的，比如犀牛書；還有些書是用來超越經典的，顯然這本書就是這種，可以去Ferris這個教程看看他寫的這些效果，看看源代碼，怎麼樣，是不是覺得有一部分很簡單了，嘗試著跟著他寫一寫這些效果。

如何寫出規範的JavaScript代碼

本人在開發工作中就曾與不按規範來開發的同事合作過，與他合作就不能用”愉快”來形容了。現在本人撰寫此文的目的除了與大家分享一點點經驗外，更多的是希望對未來的合作夥伴能夠起到一定的借鑒作用。當然，如果我說的有不科學的地方還希望各路前輩多多指教。下面分條目列出各種規範要求，這些要求都是針對同事編碼毛病提出來的，好些行業約定的其它規範可能不會再提及。1. 保證代碼壓縮後不出錯對於大型的JavaScript項目，一般會在產品發布時對項目包含的所有JavaScript文件進行壓縮處理，比如可以利用Google Closure Compiler Service對代碼進行壓縮，新版jQuery已改用這一工具對代碼進行壓縮，這一般會去掉開發時寫的注釋，除去所有空格和換行，甚至可以把原來較長的變數名替換成短且無意義的變數名，這樣做的目的是加快文件的下載速度，同時也減小網站訪問帶來的額外數據流量，另外在代碼保護上也起到了一點點作用，至少壓縮後的代碼即使被還原還是沒那麼容易一下讀懂的。要想代碼能正確通過壓縮，一般要求語句都要以分號正常結束，大括弧也要嚴格結束等，具體還要看壓縮工具的要求。所以如果一開始沒有按標準來做，等壓縮出錯後再回去找錯誤那是浪費時間。2. 保證代碼能通過特定IDE的自動格式化功能一般較為完善的開發工具（比如Aptana Studio）都有代碼”自動格式”化功能，這一功能幫助實現統一換行、縮進、空格等代碼編排，你可以設置自己喜歡的格式標準，比如左大括弧{是否另起一行。達到這個要求的目的在於方便你的開發團隊成員拿你代碼的一個副本用IDE自動格式化成他喜歡或熟悉的風格進行閱讀。你同事需要閱讀你的代碼，可能是因為你寫的是通用方法，他在其它模塊開發過程中也要使用到，閱讀你的代碼能最深入了解方法調用和實現的細節，這是簡單API文檔不能達到的效果。3. 使用標準的文檔注釋這一要求算是最基本的，這有利於在方法調用處看到方法的具體傳參提示，也可以利用配套文檔工具生成html或其它格式的開發文檔供其他團隊成員閱讀，你可以嘗試使用jsdoc-toolkit。如果你自動生成的API是出自一個開放平台，就像facebook.com應用，那麼你的文檔是給天下所有開發者看的。另外編寫完整注釋，也更方便團隊成員閱讀你的代碼，通過你的參數描述，團隊成員可以很容易知道你編寫的方法傳參與實現細節。當然也方便日後代碼維護，這樣即使再大的項目，過了很長時間後，回去改點東西也就不至於自己都忘記了當時自己寫的代碼是怎麼一回事了。4. 使用規範有意義的變數名使用規範有意義的變數名可以提高代碼的可讀性，作為大項目開發成員，自己寫的代碼不僅僅要讓別人容易看懂。開發大項目，其實每個人寫的代碼量可能都比較大，規範命名，日後自己看回自己的代碼也顯的清晰易懂，比如日後系統升級或新增功能，修改起代碼來也輕鬆多了。如果到頭髮現自己當初寫的代碼現在看不太懂了，那還真是天大的笑話了。當然，使用有意義的變數名也盡量使用標準的命名，比如像這裡：var me = this也許沒有var self = this好，因為self是Python中的關鍵字，在Python中self就是通常語言this的用法。再看下面一個例子，加s顯然比沒有加來的科學些，這樣可以知道這個變數名存的是複數，可能是數組等： var li = document.getElementsByTagName(‘li’) var lis = document.getElementsByTagName(‘li’) 5. 不使用生偏語法JavaScript作為一門動態腳本語言，靈活性既是優點也是缺點，眾所周知，動態語言不同層次開發人員對實現同樣一個功能寫出來的代碼在規範或語法上會存在較大的差別。不管怎麼樣，規範編碼少搞怪，不把簡單問題複雜化，不違反代碼易讀性原則才是大家應該做的。比如這語句：typeof(b) == ‘string’ alert(b)應該改為：if (typeof(b) == ‘string’) alert(b)，像前面那種用法，利用了運算符解析機制：如果檢測到前語句返回false就不再檢測後面語句，在代碼優化方面也有提到把最可能出現的情況首先判斷，像這種寫法如果條件少還好，如果條件較多而且語句也長，那代碼可讀性就相當差。又比如：+function(a){var p = a;}( ‘a’)應該改為：(function(a){var p = a;})( ‘a’)，其實function前面的+號與包含function的()括弧作用是一樣的，都是起運算優先作用，後者是常見且容易看明白的防止變數污染的做法，比如好些流行JavaScript框架就是採用後面這種方式。再說個降低代碼可讀性的例子，如：function getPostionTxt(type){return type == 2 ? “野外” : (type == 3 ? “商城” : (type == 4 ? “副本” : null));}應該改成：function getPostionTxt(type){var typeData={“2″:”野外”,”3″:”商城”,”4″:”副本”};if (typeData[type]) return typeData[type]; else return null;}。如果type是從0開始不間斷的整數，那麼直接使用數組還更簡單，這種結果看起來就清晰多了，看到前面那種多層三元表達式嵌套頭不暈嗎。6. 不在語句非賦值地方出生中文語句中不應該出現中文我想一般人都知道，雖然這樣做不影響程序運行，但是顯然有背行業標準要求，當然我們也不是在使用”易語言”做開發。關於這一個問題，我本來不想把它拿出來說的，但我確實遇到有人這樣做的，也不知道是不是因為他的英語實在太爛了，至少還可以用拼音吧，另外尋求翻譯工具幫忙也不錯的選擇。我舉例如下，像以下寫法出現在教學中倒還可以理解：this.user[‘名字’] = ‘張三’ 或者 this.user.名字 = ‘張三’7. 明確定義函數固定數量的參數固定數量參數的函數內部不使用arguments去獲取參數，因為這樣，你定義的方法如果包含較多的腳本，就不能一眼看到這個方法接受些什麼參數以及參數的個數是多少。比如像下面： var $ = function(){return document.getElementById(arguments[0]);}應該改成：var $ = function(elemID){return document.getElementById(elemID);} 8. 不必熱衷動態事件綁定雖然知道事件可以動態綁定，比如使用addEventListener或者使用jQuery的bind方法，也知道採用動態事件綁定可以讓XHTML更乾淨，但是一般情況下我還是建議直接把事件寫在DOM節點上，我認為這樣可以使代碼變得更容易維護，因為這樣做，我們在查看源代碼的時候就可以容易地知道什麼Element綁定了什麼方法，簡單說這樣更容易知道一個按鈕或鏈接點擊時調了什麼方法腳本。9. 降低代碼與XHTML的耦合性不要過於依賴DOM的一些內容特徵來調用不同的腳本代碼，而應該定義不同功能的方法，然後在DOM上調用，這樣不管DOM是按鈕還是鏈接，方法的調用都是一樣的，比如像下面的實現顯然會存在問題： function myBtnClick(obj) { if (/確定/.test(obj.innerHTML)) alert(‘OK’); else if (/取消/.test(obj.innerHTML)) alert(‘Cancel’); else alert(‘Other’); } a herf=”javascript:;” onclick=”myBtnClick(this)”確定/aa herf=”javascript:;” onclick=”myBtnClick(this)”取消/a 上面例子其實在一個函數內處理了兩件事情，應該分成兩個函數，像上面的寫法，如果把鏈接換成按鈕，比如改成這樣：input type=”button” onclick=”myBtnClick(this)” value=”確定” /，那麼myBtnClick函數內部的obj.innerHTML就出問題了，因為此時應該obj.value才對，另外如果把按鈕名稱由中文改為英文也會出問題，所以這種做法問題太多了。10. 一個函數應該返回統一的數據類型因為JavaScrip是弱類型的，在編寫函數的時候有些人對於返回類型的處理顯得比較隨便，我覺得應該像強類型語言那樣返回，看看下面的兩個例子： function getUserName(userID) { if (data[userID]) return data[userID]; else return false; } 應該改為： function getUserName(userID) { if (data[userID]) return data[userID]; else return “”; } 這個方法如果在C#中定義，我們知道它準備返回的數據類型應該是字元串，所以如果沒有找到這個數據我們就應該返回空的字元串，而不是返回布爾值或其它不合適的類型。這並沒有影響到函數將來的調用，因為返回的空字元串在邏輯判斷上可被認作”非”，即與false一樣，除非我們使用全等於”===”或typeof進行判斷。11. 規範定義JSON對象，補全雙引號使用標準肯定是有好處的，那麼為什麼還是有人不使用標準呢？我想這可能是懶或習慣問題。也許還會有人跟我說，少寫引號可以減輕文件體積，我認為這有道理但不是重點。對於伺服器返回的JSON數據，使用標準結構可以利用Firefox瀏覽器的JSONView插件方便查看（像查看XML那樣樹形顯示），另外你如果使用jQuery做開發，最新版本jQuery1.4+是對JSON格式有更高要求的，具體的可以自己查閱jQuery更新文檔。比如：{name:”Tom”}或{‘name’:’Tom’}都應該改成{“name”:”Tom”}。12. 不在文件中留下未來確定不再使用的代碼片段當代碼調整或重構後，之前編寫的不再使用的代碼應該及時刪除，如果認為這些代碼還有一定利用價值可以把它們剪切到臨時文件中。留在項目中不僅增加了文件體積，這對團隊其它成員甚至自己都起到一定干擾作用，怕將來自己看回代碼都搞不懂這方法是幹什麼的，是否有使用過。當然可以用文檔注釋標籤@deprecated把這個方法標識為不推薦的。13. 不重複定義其他團隊成員已經實現的方法對於大型項目，一般會有部分開發成員實現一些通用方法，而另外一些開發成員則要去熟悉這些通用方法，然後在自己編寫模塊遇到有調用的需要就直接調用，而不是像有些開發者喜歡”單幹”，根本不會閱讀這些通用方法文檔，在自己代碼中又寫了一遍實現，這不僅產生多餘的代碼量，當然也是會影響團隊開發效率的，這是沒有團隊合作精神的表現，是重複造輪子的悲劇。比如在通用類文件Common.js有定義function $(elemID){return document.getElementById(elemID)}那麼就不應該在Mail.js中再次出現這一功能函數的重複定義，對於一些複雜的方法更應該如此。14. 調用合適的方法當有幾個方法都可以實現同類功能的時候，我們還是要根據場景選擇使用最合適的方法。下面拿jQuery框架的兩個AJAX方法來說明。如果確定伺服器返回的數據是JSON應該直接使用$.getJSON，而不是使用$.get得到數據再用eval函數轉成JSON對象。如果因為本次請求要傳輸大量的數據而不得以使用$.post也應該採用指定返回數據類型（設置dataType參數）的做法。如果使用$.getJSON，在代碼中我們一眼能看出本次請求伺服器返回的是JSON。溫馨提示：jQuery1.4後，如果伺服器有設置數據輸出的ContentType，比如ASP.NET C#設置 Response.ContentType = “application/json”，那麼$.get將與$.getJSON的使用沒有什麼區別。15. 使用合適的控制項存儲合適的數據曾發現有人利用DIV來保存JSON數據，以待頁面下載後將來使用，像這樣：div id=”json”{ “name”:”Tom”}/div，顯然這個DIV不是用來界面顯示的，如果非要這樣做，達到使用HTML文件進行數據緩存的作用，至少改成用隱藏域來存這數據更合理，比如改成：input type=”hidden” value=” { “name”:”Tom”}” /。其實也可以利用window對象來保存一些數據，像上面的例子，我們可以在AJAX請求頁直接包含這樣的腳本塊：scriptwindow.userData = { “name”:”Tom”};/script，當在AJAX請求回調函數中執行完$( “#MyDiv “).html(data)後，在window上就馬上有了這一變數。如果採用第一種方法，將不可避免eval(document.getElementById(“UserData”).innerHTML)。如果在window對象存放大量數據的話，這些數據不用時要及時手動清理它們，它們是要等瀏覽器刷新或重啟後才會消失的，這就會增加內存開銷。16. 永遠不要忽略代碼優化工作代碼最優化是每個程序員應該努力達到的目標，也應該成為程序員永遠的追求。寫代碼的時候，不應該急著把功能實現出來，要想一下如何寫代碼，代碼的執行效率才是較好的。舉個例子：假設有定義getElementById的快捷方法functoin $(elemID){return document.getElementById(elemID)}，那麼有人可能會寫出這樣的代碼$(“MyDiv”).parentNode.removeChild($(“MyDiv”))，其實這裡執行了兩次getElementById DOM查找，如果改成這樣將更好：var myDiv = $(“MyDiv”); myDiv.parentNode.removeChild(myDiv)。還好getElementById的DOM查找算比較快，如果換成getElementsByTagName則更應該注重優化了。jQuery開發團隊也有提醒大家要注意這方面的問題。當然，代碼優化技巧也是需要個人不斷積累的。曾有朋友跟我說他寫網站後台代碼從來不用考慮優化的，因為他們網站用的是至強四核伺服器，我覺得這是很可笑的。17. 會分析策劃文檔，能用面向對象方法進行介面定義和代碼組織這一能力對於每一個程序員來說都是非常重要的，這也是決定一個程序員水平高低的一個重要因素。能夠把需求細化並抽象出不同的類，然後有條理地編寫代碼，使代碼結構清晰，可讀性高，代碼易於維護，不至於太過程化而且雜亂無章，這樣才算是一個優秀的程序員。

什麼是js框架？

Javascript框架是指以Javascript語言為基礎搭建的編程框架。

JavaScript框架如今正融入到屬於自己的Web和移動應用程序中，構建後端API和豐富的前台客戶端是一大趨勢，而這些又多由JavaScript框架編寫而成。

在開發前台界面時應用API，便會更加熟悉API，也會對工作內容了如指掌，當應用該項技術編寫客戶端，編寫頂級iPhone或者Android應用程序就會變得非常容易。

在JavaScript框架出現之前，開發人員只能在頁面上進行jQuery操作。這種方式很容易引起開發人員對編碼操作的困惑，而且也不易管理。

Backbone是最初的領跑者，提供了一個基本的結構和組織以及開發者友好的框架，如Angular和Ember。

擴展資料：

javascript的特點：

1、一種解釋性執行的腳本語言。

同其他腳本語言一樣，javascript也是一種解釋性語言，其提供了一個非常方便的開發過程。

2、一種基於對象的腳本語言。

其也被看作是一種面向對象的語言，這意味著javascript能運用其已經創建的對象。因此，許多功能可以來自於腳本環境中對象的開發方法 與腳本的相互作用。

3、一種簡單弱類型腳本語言。

javascript是一種基於java基本語句和控制流之上的簡單而緊湊的設計，從而對於使用者學習java或其他c語系的編程語言是一種非常好的過渡。

4、一種相對安全腳本語言。

javascript作為一種安全性語言，不被允許訪問本地的硬碟，不允許對網路文檔進行修改和刪除，只能通過瀏覽器實現信息瀏覽或動態交互。從而有效地防止數據的丟失或對系統開發的非法訪問。

參考資料來源：百度百科-JavaScript框架

用JS設計一個頁面,在頁面上顯示信息”現在是XXXX年XX月XX日XX點XX分XX秒(星期X),歡迎您到訪我的站點”.

script

//setTimeout

var info = “現在是”+date.getFullYear()+”年”;

info += (date.getMonth()+1)+”月”;

info += (date.getDate())+”日”;

info += date.getHours() + “點”;

info += date.getMinutes()+”分”;

info += date.getSeconds()+”秒”;

info += “（星期”+(date.getDay()+1)+”）”;

/script

運行模式

JavaScript是一種屬於網路的高級腳本語言,已經被廣泛用於Web應用開發,常用來為網頁添加各式各樣的動態功能,為用戶提供更流暢美觀的瀏覽效果。通常JavaScript腳本是通過嵌入在HTML中來實現自身的功能的。

是一種解釋性腳本語言（代碼不進行預編譯）。

主要用來向HTML（標準通用標記語言下的一個應用）頁面添加交互行為。

可以直接嵌入HTML頁面，但寫成單獨的js文件有利於結構和行為的分離。

如何設計一個基於Node.js和Express的網站架構

推薦使用Webstorm打開項目。打開項目後，代碼結構如下圖所示：

在主體結構中從上到下介紹。 app 文件夾包含了所有後端代碼； build 文件夾中包含了最新資料庫備份； config 包含有網站整體的配置； logs 文件夾包含網站後端記錄的日誌文件； node_modules 是包含所有的 node.js 依賴包（源代碼中初始沒有此文件夾，運行 npm install 命令後所有載入的依賴包放置在此文件夾中）； public文件夾包含了所有的前端代碼，包括JavaScript、less、圖片、Webfont等； .bowerrc中定義了 bower 管理前端庫的下載地址； bower.json 則配置了項目需要的前端庫；.jshintre-client 和 .jshintrc-server 分別為前後端JavaScript代碼規範檢查規則；.travis.yml 為[travis]（travis-ci.org/）自動編譯配置； app.js 為node.js啟動腳本文件； build.sh 為單獨編寫的自動發布bash命令；gruntfile.js為 grunt 配置文件；newrelic.js為 newrelic 的配置文件，用於監控網站性能； package.json 包含了所有node.js依賴包配置。

項目後端結構

項目後端代碼架構如下圖所示：

主要分為兩大部分： app 和 config 。 app 裡面按照職責不同來分類，每個腳本文件對應於不同的模塊； api 文件夾包含了所有api對應的業務邏輯代碼， helper 放置一些公用方法，如郵件發送、日誌記錄、資料庫連接等等； templates 放置的是靜態郵件模板； views 是後端頁面模板，使用了 handlebar 模板引擎，其中 http 中放置系統錯誤顯示頁面， layouts 放置模板頁； routes 是 express 對應的路由配置，所有的頁面和API的路由配置都在這個文件中。 config 文件夾中為系統配置，按照不同環境分為開發和現場兩個環境配置， all.js 放置共通配置， development.js 放置開發環境對應配置而 production.js 放置線上環境配置。配置內容包括郵件發送、資料庫連接及一些第三方API所需的key等等。

項目前端結構

項目前端代碼結構如下所示：

前端代碼全部放置於 public 文件夾下。 data 目錄包含一些靜態json格式數據，後期可能會考慮放到資料庫中。 helper 中是瀏覽器下載引導頁面； images 包含了所有項目中用到的圖片，我們盡量使用第三方的圖片伺服器保存圖片，一些小圖標也盡量使用webfont。 JavaScripts 文件夾包含所有JavaScript文件，其中 app 子目錄放置業務代碼，業務代碼都是按照業務不同封裝成了不同的 angularjs controller； debug 子目錄放置調試用代碼，而 libs 方式前端JavaScript庫，項目中使用得JavaScript庫有angularjs 、 jQuery 及一些插件； clients.js 是所有ajax請求函數； erealm.js 是angularjs的主模塊； language.js 包含了所有多語言配置，目前支持中英文。stylesheets 包含了所有的css樣式及webfont，除了第三方庫之外，自定義的樣式全部使用了 less 。作為一種慣例，項目中添加了 humans.txt 文件，表明項目的作者信息。有關humans.txt，可以參考官方網站 humans.txt 。

自動化構建工具

項目自動化構建使用 grunt 。grunt的使用涉及開發、調試、發布階段。開發階段使用了圖片壓縮和前端代碼格式美化，使用的工具是 imagemin 和 jsbeautifier ，運行grunt prepare 命令。調試階段使用了代碼規範檢查、less編譯、自動添加瀏覽器前綴、自動載入運行nodejs並打開瀏覽器、實時監控代碼變化並刷新頁面等。開發中，使用 grunt 命令即可，為默認grunt命令。發布階段包含了JavaScript及css合併壓縮，並在文件路徑上添加哈希值來避免瀏覽器緩存問題，同時刪除開發環境中使用的代碼，使用 grunt build 命令即可把代碼切換為發布環境。

具體的使用grunt方法及相關工具的介紹，後期會有專門的技術文章講解，這裡不會詳細設計技術細節。

後期持續的改進點

項目完成的比較倉促，但是我們盡量保持代碼的整潔和可維護性，一些編碼方式也借鑒當前流行的最佳實踐。但理想是美好的，現實總是不會做到那麼完美，需要不斷的完善。目前存在的問題是後端代碼結構不夠清晰、整體代碼中無用代碼還沒有來得及移除。框架上期望把 jQuery 去掉，只使用 Angularjs ，目前只做到了盡量不用jQuery 中的方法。小圖標的使用上 Bootstrap 和 Font Awesome 重複，後期會逐步刪除 Font Awesome 而只使用 Bootstrap 中帶的小圖標。目前，最大的問題是項目沒有完整的自動化測試，這個後期會逐步添加。

總結

以上是這個開源項目的整體技術結構介紹。在這個項目中，我們會持續使用最流行的Web技術，希望得到大家的持續關注，如果有開發者能一塊貢獻一些代碼，我們將會非常高興。我們已經在github.io上構建了一個技術平台來發布Web技術文章，網址是blog.erealm.cn。博客網址也同樣開源，使用了 Jekyll 構建。 Jekyll 非常強大，最大的特點是使用markdown格式來發布文章。博客的代碼在這裡： github 。

我們做這個開源的項目的目的有兩個，其一是通過這個項目來展示我們做Web項目的實力，及培養團隊技術水平。其二是藉助這個項目，能和同行們有個技術上的互動和交流。如果我們的項目能讓一些新手們學到一些做Web項目的經驗，我們就很知足了。技術是不斷革新的，而國內Web技術向來是落後於國外好幾年，這個是不爭的事實。我們erealm團隊樂意為國內Web貢獻自己的力量，也歡迎國內同行們和我們交流Web開發經驗。