明天要发给项目开发小组的js规范的个人建议，希望经验丰富者能够帮提出改善建议，非常感谢

Question

别人doc文档里写的是编码规范，
你在这里却是写的系统构架和一些技术细节，貌似风马牛不相及。
如果是实在提不出对编码规范的建议，把这个交上去也行吧。ps. 你是sina的？

Answer 1

整理了下，今天上班后发给了项目组，不过可能是我写的太多太乱的原因，基本没人看呵呵。
===================================================================================================
1. 这份规范大概90%上都是书写编码上的规范（而我们js在这方面并不是主要问题），个人认为编码书写规范应该有，但不必太过于详细，大家都能看得懂就 OK，否则大家都太专注于细节很容易因小失大，忽略了整体的把握度。我所真正是关注是规范是否能提高项目可控性而并非完全的执行效率，后面是我的观点，但不一定可行，但是希望大家能说出自己的想法和心目中的解决方案，毕竟规范是给大家制定的。
2. 规范要由始至终围绕最终目的进行。比如说：提高开发速度，增强项目可控性，可维护性，减少大家之间重复劳动，能够应付需求的频繁变动，提升程序效率(有的时候效率和可控性是互相矛盾的，所以要有所取舍，权衡轻重)等。千万不要为了制定规范而制定规范，那样就失去规范实际的意义了。
针对改善项目可控性我提出如下建议：
a) 强调代码重用和和程序间采用多层结构：重用的好处不必多说，提几个可以重用的地方。首先:ajax请求数据接口可以被多个业务逻辑所共享，第二是js所使用的模板也可以被多个业务逻辑共享，第三是标准库可以共享（这点在规范体现很好），至于为什么要使用多层次结构主要目的是结构更清晰，维护更方便。我相信谁都不想看到一套代码入过从头写到尾，而没有任何函数把。
具体实施步骤：
1. 所有ajax请求或其他的关于数据的请求放到vlib/core/module下，在此目录下的子目录根据不同的数据源划分。
2. 所有与js模板有关的统一放到一个大家都同意的template目录
此目录下的子目录根据不同的功能划分。
3. dev/目录依然作为业务逻辑处理用,用于组织调用1,2和基类库
原因分析：针对ajax请求我们可以把它想象成数据接口，既然是接口就是可以被共用，比如说我们的视频实时点击数接口，多少页面在使用，如果按照今天开会的时候那样试问我们要复制多少份？如果某一天我们的ajax请求的php接口变了我们要修改多少份js？这样的请求在我们播客不是少数，好友列表，用户视频列表，评论数据，专辑列表，我们为什么不把他们单独的独立出来，就像我们的PHP中的module一样，供大家所使用，虽然这样来讲代码的总长度没有减少，但是如果处理的好的话代码总体长度也不会增加，而带来的受益是相当可观的。
之前我们的PHP改版豆豆把mvc这种思想引入进来我认为是很成功的，我们js为什么就不能引入进来。个人强烈建议把业务逻辑、数据、表现层相互分离。如上面三点所说，一个是作为数据接口用，另外存放作为页面展示给用户的模板，既然是大项目，效率很重要，但可控性同样重要，况且这样跟效率并不冲突。
b) 基本类库要足够强大，可扩展性要好，可重用的后期要补充：毕竟基类是最被频繁使用的东西，如果初期设计不好，直接影响开发效率，比如说目前最为突出的 dialog类，大家为什么会复制，就是原先的功能满足不了需求，之后我会提出我能想到的dialog当前需要功能，也请大家补充。
c) 尽量不要使用拼串来达到页面展现的目的,除非像宋健所说就拼几个字，一眼就能看出来，但如果是大篇幅的拼串很不好，我不知道大家为什么对我那个js模板类那么讨厌，确实是稍微大了点，但效率的影响不在这上，针对他的应用很多，我们新浪的邮件也使用了这个，我没看到影响了多少，相反降低了相当多的开发成本。大家仔细想想，如果我们的业务逻辑很复杂，而模板类可以显著降低复杂度，复杂度降低了，我们的业务逻辑就少了，业务逻辑少了，代码量自然就下来了，而且别忘了一点，使用模板页面设计师是可以直接在上面修改的，我们拼完的串人家是没法在上面修改的，无形的增加了沟通成本。
3. ajax跨域问题
我们二版采用变通的方式，通过document.write( <script   src=aa.js   /> )来实现或提交表单后页面重定向到同域名下，但这样增加了业务复杂度，我们可以借助于FLASH做桥来实现跨域的问题，具体是否可以实现要测试后在做结论，当前我忙于最近访客和好友这两个功能的实现，忙完后我会找正业来完成此事或有别人来代我解决。
这个问题解决了，相信我们的JS的业务逻辑复杂度会大大的减少。我们是播客，所以不用考虑我们的用户是会不支持FLASH的问题。
4. $尽量作为保留关键子，我们说不上没准那天回引进第三方开源框架，而开源框架很多都回使用$以后冲突就很难修改，$可以换成别的符号，但如果实在太麻烦可以考虑不换。
5. 针对第三方开源代码，我想大家反对的原因就是因为他很大把。所以我同意尽量少用或不使用，但是一旦使用了我不建议肆意改动起源代码，首先做法很不好，而且将来更新版本的时候很麻烦。
6. 我心目中的理想目录结构（暂时想到的）：
vlib
doc/保持不变
test/保持不变
util/保持不变
core/
module/下面是封装了的ajax调用，以及从其他数据源获取的数据
effects/   js特效，比如说我们的dialog
validate   /   常用的有效性验证
thirdClass/第三方类库，比如说js模板类，由于第三方类库用PHP解析可能很麻烦，所以请考虑用PHP分析JS中加的注释   //#include   path方式
dev/按照功能分
pub/保持不变
7. 规范一旦定下来后必须严格执行（可能当初PHP规范我自己就没有执行好，这次大家可以互相监督，我没执行好我重写），如果认为规范有问题，可以提出来，确实有问题可以随时修正规范，任何人不可能事先想的那么全，规范也不可能制定出来后马上就很合理，国家宪法还总是修正呢，但是既然是规范，我不想让他变为白纸，毕竟是很多人花费很多精力整理出来的，请大家珍惜。
8. 关于dialog实现的注意事项（下面这些是我在设计好友对话框的时候遇到过的实际问题，如果我们的dialog在设计中遇到了这样的问题可以参考js/friend/friendDialog.js里的实现）
a) 页面如果在框架页里，弹出的对话框要在top层，此时注意下这个时候的偏移位置应该是相对于当前页面的偏移位置加上IFRMAE相对于top页面的偏移，所以要考虑多次递归来算出这个偏移量。
b) 提供获取对话框打开的iframe里的document对象的接口，方便对iframe里的进行处理
c) 对话框应该提供iframe高和宽能够自适应iframe页面内的元素大小的功能，可以自动调用，而且必要的时候可以手动调用，手动调整大小。
d) 提供关闭对话框接口（不要仅仅是点按钮才能关闭，而且要求点对话框的外部还能自动关闭，具体实现可以参考BLOG和相册）
e) 提供给ifrme里的对象自动赋予事件的能力，给IFRAME里的元素赋予事件和给当前页赋予事件是有区别的，有的时候IFRAME里的e.target或e.srcElement并不能获取到产生事件的源对象；  
f) 对话框打开的位置可以根据鼠标的位置，点击元素的位置，默认屏幕居中，和自定义位置三种方式来确定。
g) 可以根据需要选择是否需要阴影
h) iframe里的内容可以通过指定url方式添加进去，也可以通过html串的方式添加进去，但以HTML串的方式添加进去有几点需要注意：页面中引用的 JS和CSS会失去作用，不能产生效果、短时间内连续两次document.open在火狐下会有明显的闪动（这个主要是在有loading处理的时候会两次document.open）,在火狐下如果在短时间内连续两次document.open向里面写数据，由于火狐写的会有些延迟，所以会造成写线程冲突而出错，或过早的调用页面自适应大小会导致页面显示不完整。