※ 引述《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)