Re: [問題] 有架構化的Java Script

看板Ajax作者TonyQ (沉默是金。)時間15年前 (2010/09/19 14:45)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串2/5 (看更多)

※ 引述《ThreeDay0905 (三天)》之銘言： : ASP.NET寫久了 : 目前的Project逐漸把重心轉移到js上面， : 變成.NET純粹只提供資料 : 用js做主要的處理 : 但是遇到一個問題，js的程式碼實在太亂而且很難維護起 : 雖然說js可以寫成物件導向 : 只是因為必須有一個讀取文件的動作 : 變成要針對這頁面挑選這頁要用的函式庫 : 可是又要考量到下載的問題，不可能丟一堆js檔上去 : 還要去壓縮或著組成同一個檔案 : 變成整個架構變得很混亂 : 請問板上的前輩都怎麼去架構一個js專案 : 讓程式碼可有系統的再利用 : 也不會讓頁面的程式碼變得這麼凌亂呢比較常見的作法是把所有用到的 lib 打成一包，雖然這樣對第一次的瀏覽效能會比較有所損傷，所以要搭配把script放在 </body> 的作法。但是考慮到瀏覽器的快取效果，「在大部分的情形下」，這樣會比分別讀取大小不一的 script 檔效果來得好，即使你把他們打包成一個。這個問題要討論的我個人會分析成以下幾個面向 1.流量傳輸問題 - javascript file 的總大小 2.連線數問題 - javascript file 的總數以上兩點是比較偏瀏覽器環境的限制，基本上是處於比較好解決的那塊，常見是 yui compressor 搭配一些簡單的 shell script 跟規範工作流程，要費點功夫但不會很難搞定，而且這比較屬於一次性的環境建設。一般來講會把專案的原始碼跟發布的過程中，去進行一個 deploy 的程序，在那時透過自動化程序來對 script 進行壓縮的動作。所以重點放在底下的東西： 3.javascript 再利用的可能性. 基本上當他跟頁面的結構綁死時，絕大多數頁面的行為是很難再利用的。能夠再利用的多是已經「元件化」（component）的東西，舉個例子 , jQuery datepicker , 諸如此類的. 所以這邊提到如何去組織一個頁面的script ，首先就要先把 script 區分成兩個區域，一個是環境，諸如 javascript lib (ex.jQuery/prototype/YUI...) 或者一些 plug-in，這些比較不會有異動，而且比較有可能一起共用的要分開來看。（上面這些是比較有機會/需要打包成一包的，因為共用性高。）再來就是實際各頁面各自需要的邏輯。然後基本上非常不建議把script 寫在 html裡，當你有多個 script function 散落各個頁面區域的時候，光找定義跟思考這些定義的複雜度就可以讓你找到死了... 寫成 .js 雖然有些人會詬病 js file變多，但是考慮到cache 、可能需要打包跟頁面邏輯分離的程度，這樣個人覺得比較好。也不建議寫 onclick = "xxxx" , onchange="xxx" , 除非你的環境沒有提供你任何 databinding 的 js tool , 理由是你很有可能會移除實做或改名時 ,忘了移除這個事件binding. 當然適當的用註解去提示 event binding 在哪裡這是無傷大雅 , 但最好還是建立一致性的規則(ex.某頁面的就統一放在某檔案..etc)比較好. Quick fix is quicksand. ----------------------------------------------------- 再來是頁面 script 的內容。這其中其實你會發現大部分你寫 javascript ，基本上都可以透過「被影響到的dom」來分成很多小圈圈。比方說 form validation 會針對 form 做， lightbox 可能會做在連結或圖片上之類的。這時候你就可以看看這些目標元件出現在其他頁面的可能性高或低，比方說form validation 的再利用性通常是非常非常的低，還有一些奇怪的飛來飛去之類的 animtation ，通常可利用性也很低，這就可以歸類在頁面 script ，通常能 component 化的機率很低。有些的可利用性則可能很高。（當然，這要看你用什麼思維去設計。）比方說常見的作法之一是用 class 去識別某些特定的行為，像是 <a href="xxx" class="light-box" /> （只是比方），然後自動在環境層級去 apply light-box效果。或者是 <input type="text" class="date" /> 自動 apply datepicker 。這種的通常都很明確，比方說只針對一個dom元件去作操作的，或者是針對列表去作處理的等等。 ----------------------------------------------------- 以上這些是比較正常的介紹，以下實際比較會踢到的鐵板。 ----------------------------------------------------- 通常最頭痛的是一些需求變動之後，或者是過度過度過度過度過度客製化的結果。通常會是很複雜的實做，比方說點A跳BC、點C跳DE、點F跳AB，點D跳CDF，有一堆 if-else 跟奇怪的 mapping rule 。這種就不要太強求要維護性或看懂了， dirty requirement make dirty result . 但至少開個 function ，把所有有關的實做丟進去就是了，有要維護的人至少知道這些爛code 只在這function，不能因為少部份爛code把整個程式都污染成一團義大利麵。（換句話說，就是讓他變黑箱啦，當然單位要盡可能小，如果整個專案都黑箱那就不用玩了。）講到這裡就又必須提到 global variable 要特別小心用，因為黑箱搭配全域變數很容易會出事。XD 特別是在第一層定義的 var , 因為會直接被當成 window成員 , 更容易在存取時出事。 for example , 有些人可能不知道這件事 . <script type="text/javascript"> var hello ="hello"; // it means window.hello ="hello"; </script> 這就會造成類似這樣的悲劇 http://jsfiddle.net/QMwHm/ 其實 js 這種動態語言比較講求「自律」，所以要要求品質還蠻困難的，特別在時程趕時，寫出什麼鬼東西都有可能。XD -- 基本上元件化就是重新利用 js 的理想解之一... -- I am a person, and I am always thinking . Thinking in love , Thinking in life , Thinking in why , Thinking in worth. I can't believe any of what , I am just thinking then thinking , but worst of all , most of mine is thinking not actioning... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 111.83.16.69 ※ 編輯: TonyQ 來自: 111.83.16.69 (09/19 14:46) ※ 編輯: TonyQ 來自: 111.83.16.69 (09/19 14:48)