javascript 技术要点汇总
2012-5-6 22:22:31 阅读106 评论3 62012/05 May6
1.Dom机制
浏览器读取html页面后，会把节点放到内存生成一个Dom树对象。所有对Dom的操作，都是利用对Dom对象方法的调用来实现更新修改删除添加等操作。
1）.对于Dom的修改，要记得最小化页面重绘。比如要添加多个节点，记得用fragment,更新大片html,用text來操作一次重绘，避免用循环对Dom进行修改等。。因为每次Dom变化，都会引起很多属性的变化，包括wdith ,height ,offsetWHTL..cliendWHTL,scrollWHTL。
2) .合理的利用冒泡机制，理解事件委托方法，大量事件的时候，优先选择委托方式，让代码脱离文档，同时对于Dom的属性操作也脱离文档流。
3) .要懂得html以及Css,很多效果并非必须用js不可，有些逻辑限制了html的布局方式，掌握了这点，就可先入为主，和builder沟通制作方法。
4）理解盒模型。
2.要懂得各个浏览器的分辨
浏览器分化严重，userAgent已经无法聪明的辨知浏览器版本，并且我们需求的不是浏览器版本，而是对于某个特定功能是否支持，所以，用特殊函数进行测试。
1）用addEventListener监测事件。來针对支持标准的内核进行事件处理
2) 在支持querySelector的浏览器下用最新的选择接口。
3）有时候用css的fixed比计算定位更准确，不需要考虑resize
4) 有时候，用-webkit-transform : translate來移动比计算位置来的更快，更有时候，还有硬件加速
浏览器读取html页面后，会把节点放到内存生成一个Dom树对象。所有对Dom的操作，都是利用对Dom对象方法的调用来实现更新修改删除添加等操作。
1）.对于Dom的修改，要记得最小化页面重绘。比如要添加多个节点，记得用fragment,更新大片html,用text來操作一次重绘，避免用循环对Dom进行修改等。。因为每次Dom变化，都会引起很多属性的变化，包括wdith ,height ,offsetWHTL..cliendWHTL,scrollWHTL。
2) .合理的利用冒泡机制，理解事件委托方法，大量事件的时候，优先选择委托方式，让代码脱离文档，同时对于Dom的属性操作也脱离文档流。
3) .要懂得html以及Css,很多效果并非必须用js不可，有些逻辑限制了html的布局方式，掌握了这点，就可先入为主，和builder沟通制作方法。
4）理解盒模型。
2.要懂得各个浏览器的分辨
浏览器分化严重，userAgent已经无法聪明的辨知浏览器版本，并且我们需求的不是浏览器版本，而是对于某个特定功能是否支持，所以，用特殊函数进行测试。
1）用addEventListener监测事件。來针对支持标准的内核进行事件处理
2) 在支持querySelector的浏览器下用最新的选择接口。
3）有时候用css的fixed比计算定位更准确，不需要考虑resize
4) 有时候，用-webkit-transform : translate來移动比计算位置来的更快，更有时候，还有硬件加速
关于重构。
2012-4-28 0:21:12 阅读26 评论0 282012/04 Apr28
今天和同事叨叨，讲了一下我目前的现状，因为需求误导，我在重构我前两天刚完成的工作。
同事问是不是以前的不能用。我说肯定是能用的。。改改就行，但是代码结构有问题，本身就有部分不合理的逻辑在里面，所以，我才重构一下。
说起来重构，我很有感触。重构是一种自我否定。每次在自我否定的时候，都深受懒惰的自己和时间的压迫，导致自己左右为难，重构一部分功能，首先以前的代码缺陷是有，但是未必无法运行，那么重构来讲，只是满足了自己的代码完美强迫症。在此重构需要时间，那么从时间上和进度上，很可能会导致迭代计划失效。
程序员最大的敌人就是懒惰。
在此不讨论技术细节。
假设现在进度时间剩余一个月，某个功能发现缺陷，经过研究发现改改也能用，耗时三天，但是重构后，肯定不会出问题，耗时两周。很多主管都毅然考虑修改。在此选择上，有几个理由：没有完美的代码，对于代码的优化是无止境的。。所以，修改是可以接受的。在达到商业目的后，可以有优先级的对于项目缺陷进行修改，也不失为一种上策。
不过很多的情况下，需求业务相互耦合，比如某个服务有缺憾，那么依赖此服务接口的其他服务都因为此缺陷导致偏离正常编码方式和部署方式。在此情况下，一个链式的反向传染就会出现。后期可能会追加更多的人力于修复此缺陷导致的损耗，间接成本不可控。
还有一种情况，在重构损耗进度的情况下，整体开发并行调度都会收到影响，那么每一条开发链和此重构依赖，进度都会受到影响，那么为此错过有时间行为的商业目的实现就很悲催。
唉。两条叉路口。很为难。
同事问是不是以前的不能用。我说肯定是能用的。。改改就行，但是代码结构有问题，本身就有部分不合理的逻辑在里面，所以，我才重构一下。
说起来重构，我很有感触。重构是一种自我否定。每次在自我否定的时候，都深受懒惰的自己和时间的压迫，导致自己左右为难，重构一部分功能，首先以前的代码缺陷是有，但是未必无法运行，那么重构来讲，只是满足了自己的代码完美强迫症。在此重构需要时间，那么从时间上和进度上，很可能会导致迭代计划失效。
程序员最大的敌人就是懒惰。
在此不讨论技术细节。
假设现在进度时间剩余一个月，某个功能发现缺陷，经过研究发现改改也能用，耗时三天，但是重构后，肯定不会出问题，耗时两周。很多主管都毅然考虑修改。在此选择上，有几个理由：没有完美的代码，对于代码的优化是无止境的。。所以，修改是可以接受的。在达到商业目的后，可以有优先级的对于项目缺陷进行修改，也不失为一种上策。
不过很多的情况下，需求业务相互耦合，比如某个服务有缺憾，那么依赖此服务接口的其他服务都因为此缺陷导致偏离正常编码方式和部署方式。在此情况下，一个链式的反向传染就会出现。后期可能会追加更多的人力于修复此缺陷导致的损耗，间接成本不可控。
还有一种情况，在重构损耗进度的情况下，整体开发并行调度都会收到影响，那么每一条开发链和此重构依赖，进度都会受到影响，那么为此错过有时间行为的商业目的实现就很悲催。
唉。两条叉路口。很为难。
如何做好一个产品
2012-3-23 0:20:47 阅读14 评论2 232012/03 Mar23
今天太晚，话不多说，
送所有处于开发期的产品经理/老板两句话：
议事者，身在事外，宜悉利害之情。
任事者，身居事中，当忘利害之虑。
送所有处于开发期的产品经理/老板两句话：
议事者，身在事外，宜悉利害之情。
任事者，身居事中，当忘利害之虑。
做一个网站，要用什么技术去实现？
2012-3-21 21:54:00 阅读66 评论0 212012/03 Mar21
经常有朋友问我：
“莫大，我要做一个门户型网站，你说我用现成的开源cms呢，还是招人开发一个？开源cms虽然快，但是我有很多想法它不能实现，有一定的局限性，招人开发一个倒是很容易满足业务需求，但是周期长。。”
“莫大，我要做一个网站，你说我用thinkphp呢，还是用ci呢？还是yii呢？这些框架都有各自特点，但是都有一定问题，think文档很全，ci开发迅速，老牌框架更放心，yii很诱人，某个高手强烈推荐我用。。”
“莫大，我要做一个交互性挺强的web app，前端实现，我用jquery呢，还是yui3呢？jquery插件多，开发很迅速，算是轻量级的吧。。但是yui模块化很容易开发，要不我自己开发个简单版本框架，后期维护就更容易了，不会过度依赖于社区框架版本，自由掌控前端代码，跟业务结合更容易？”
“莫大，我做一个社区网站，你说我用php呢，还是ruby呢？php好招人，执行效率高，大负载量有很多成熟解决方案，但是ruby开发很快，产品迭代效率搞，负载问题，可以服务器扩容解决。。或者我用python?python，豆瓣用python做的，好像很不错啊。。”
“莫大，我服务器配置，是走vm解决方案呢，还是继续走传统的单机centos？vm虚拟化后续扩展业务我很方便，可是现在我的技术员没有接触过，centos可以保证顺利上线，可是我略微担心业务量上来，扩容是问题啊。。要不我买商业机房的解决方案得了。。省心。。可是如果自己可以做，就不用浪费那么多成本了。。”
“莫大，那个啥，那个啥，就是那个啥，我应该那个啥？”
“莫大，我要做一个门户型网站，你说我用现成的开源cms呢，还是招人开发一个？开源cms虽然快，但是我有很多想法它不能实现，有一定的局限性，招人开发一个倒是很容易满足业务需求，但是周期长。。”
“莫大，我要做一个网站，你说我用thinkphp呢，还是用ci呢？还是yii呢？这些框架都有各自特点，但是都有一定问题，think文档很全，ci开发迅速，老牌框架更放心，yii很诱人，某个高手强烈推荐我用。。”
“莫大，我要做一个交互性挺强的web app，前端实现，我用jquery呢，还是yui3呢？jquery插件多，开发很迅速，算是轻量级的吧。。但是yui模块化很容易开发，要不我自己开发个简单版本框架，后期维护就更容易了，不会过度依赖于社区框架版本，自由掌控前端代码，跟业务结合更容易？”
“莫大，我做一个社区网站，你说我用php呢，还是ruby呢？php好招人，执行效率高，大负载量有很多成熟解决方案，但是ruby开发很快，产品迭代效率搞，负载问题，可以服务器扩容解决。。或者我用python?python，豆瓣用python做的，好像很不错啊。。”
“莫大，我服务器配置，是走vm解决方案呢，还是继续走传统的单机centos？vm虚拟化后续扩展业务我很方便，可是现在我的技术员没有接触过，centos可以保证顺利上线，可是我略微担心业务量上来，扩容是问题啊。。要不我买商业机房的解决方案得了。。省心。。可是如果自己可以做，就不用浪费那么多成本了。。”
“莫大，那个啥，那个啥，就是那个啥，我应该那个啥？”
关于互联网产品设计的混乱思考
2012-3-20 23:49:36 阅读72 评论0 202012/03 Mar20
收到需求，要做一个滚动条效果。
仔细研究产品图，略微发现是应用界面过于华丽，默认的拖动条很是扎眼，产品和UI们给出的解决方案是自己写一个组件來搞定它。
不是第一次遇到这种为了界面美观而做很多过度设计的情景。在设计者眼中，既然出来这个方案，那么他们已然具备了充分的理由來说服开发者去执行，无非是提升界面质量，增强用户视觉感受一类。
工作中如果没有效果的沟通产生，那么执行力会下降很多。我不在产品位置，无法评价此类行为，我要做的，仅仅是执行。
嗯，多说无益，直接动手。用时半天，调试两个小时，各版本基本上运行通过。
实现思路简单如下：
如果内部HTMLElement高度大于外部包裹元素高度，那么滚动条出现，设置外部dom 的padding-right为滚动条宽度，进行拖动事件绑定处理。如果内部元素高度或者外部的高度发生改变，那么重新调用build函数进行重绘滚动条属性。
滚动条的拖动把用内部高度和包裹高度的比例來实现，给出最小的高度。
开发思路清晰，没有遇到额外的坎，顺利交付。交付的时候，我再三声明，此拖动条完全无法跟浏览器默认拖动条效果相比较，如果可能，请务必优先用默认拖动条，如webkit的可以用css改写样式。
身为设计者，开发者，最好能控制住产品的应用复杂性。复杂性杀死一切。它把所有人的生活给搞砸了，它令产品难以规划，开发，测试，发布，还带来了安全挑战，并最终导致用户和开发者沮丧不已。
仔细研究产品图，略微发现是应用界面过于华丽，默认的拖动条很是扎眼，产品和UI们给出的解决方案是自己写一个组件來搞定它。
不是第一次遇到这种为了界面美观而做很多过度设计的情景。在设计者眼中，既然出来这个方案，那么他们已然具备了充分的理由來说服开发者去执行，无非是提升界面质量，增强用户视觉感受一类。
工作中如果没有效果的沟通产生，那么执行力会下降很多。我不在产品位置，无法评价此类行为，我要做的，仅仅是执行。
嗯，多说无益，直接动手。用时半天，调试两个小时，各版本基本上运行通过。
实现思路简单如下：
如果内部HTMLElement高度大于外部包裹元素高度，那么滚动条出现，设置外部dom 的padding-right为滚动条宽度，进行拖动事件绑定处理。如果内部元素高度或者外部的高度发生改变，那么重新调用build函数进行重绘滚动条属性。
滚动条的拖动把用内部高度和包裹高度的比例來实现，给出最小的高度。
开发思路清晰，没有遇到额外的坎，顺利交付。交付的时候，我再三声明，此拖动条完全无法跟浏览器默认拖动条效果相比较，如果可能，请务必优先用默认拖动条，如webkit的可以用css改写样式。
身为设计者，开发者，最好能控制住产品的应用复杂性。复杂性杀死一切。它把所有人的生活给搞砸了，它令产品难以规划，开发，测试，发布，还带来了安全挑战，并最终导致用户和开发者沮丧不已。