无它，纯学习的代码，看效果用的。纠结啊，原来好多JS中的方法都没有用过。亏我以前还想转前端：
insertAdjacentText方法，在指定的地方插入html内容和文本内容。
insertAdjacentHTML方法：在指定的地方插入html标签语句
原型：insertAdajcentHTML(swhere,stext)
参数：
swhere: 指定插入html标签语句的地方，有四种值可用：
1. beforeBegin: 插入到标签开始前
2. afterBegin:插入到标签开始标记之后
3. beforeEnd:插入到标签结束标记前
4. afterEnd:插入到标签结束标记后
stext：要插入的内容
参考：http://blog.csdn.net/helanye/article/details/4496061
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- <html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
- <title>测试insertAdjacentHTML</title>
- <script language="javascript"><!--
- function addsome() {
- document.getElementById('test').insertAdjacentHTML("afterBegin", "<h1>在文本前容器内插入内容afterBegin</h1>");
- document.getElementById('test').insertAdjacentHTML("beforeEnd", "<h2>在文本后容器内插入内容beforeEnd</h2>");
- document.getElementById('test').insertAdjacentHTML("beforeBegin", "<h4>beforeBegin在文本前容器外插入内容</h1>");
- document.getElementById('test').insertAdjacentHTML("afterEnd", "<h5>afterEnd在文本后容器外插入内容</h2>");
- }// --></script>
- </head>
- <body onload="addsome()">
- <div id="test">原始内容</div>
- </body>
- </html>
效果：
FF下无效，IE下有效。webkit下有效。
Over
看到这个CSS属性的时候，我真的纠结了半天，border-top-width，看这个词组的含义，我还以为是边框顶部的宽度，最初我以为是边框边的宽度，但看了手册后，才发现原来是BODER的高度，粗细之类的。
后来看到了这里的介绍：http://school.mzoe.com/css/pr_border-top_width.html，才小小的了解了一点：
定义
border-top-width 属性设置元素的上边框的宽度。
只有当边框样式不是 none 时才起作用。如果边框样式是 none，边框宽度实际上会重置为 0。不允许指定负长度值。
注释：请始终把 border-style 属性声明到 border-width 属性之前。元素只有在获得边框之后，才能改变其边框的宽度。
-------
同时也介绍了说这个值是可以通过JS来改变的。反正不管怎么样，我已经明白了
看到getBoundingClientRect方法，是用phpstorm进行跳转的，跳转到原始文件中，居然提示我是@browser IE，@return TextRange
一下子就闷了，还好有google，找到了一篇 文章（不好意思，不是专业做前端的，对于这些函数所以都不太了解，也没有去看什么 w3cschool之类的教程）
找到了这篇 文章才知道：
http://younglab.blog.51cto.com/416652/386540
-
-
-
-
-
-
OK，我也不多介绍了，看一下原文中对于这一点是怎么解释的：
XML/HTML代码
- 页面左上角由一个元素，紧贴浏览器的左边和上边，在除IE外的浏览器，包括基于IE内核的搜狗浏览器（360垃圾浏览器及TT浏览器未测试）都能正确的获取到各个属性的值，而在IE中，每个值都会比正常值多出两个像素，例如，正常的left值为0，在IE中为2；
-
- 这是因为IE中document.documentElement.clientTop并不为0（尽管已设置html、body的margin和padding为0），所以在IE中获得的值要减去document.documentElement.clientTop的值。
更多的资料还是去看原文吧：http://younglab.blog.51cto.com/416652/386540
嗯，这里不是在做广告
主要是昨天小朋友参加了某保险公司的一个小活动，其实 也是棒约翰举办的一个小活动。
想来和肯德基一样，是做为那种亲子活动或者是其他的一些活动一样。
小朋友和我们一起去逛了一下，玩的非常开心，看到服务员在做pizza，并同时自己放上了那些作料之类的，小东西非常非常开心
他们还参观了棒约翰的厨房，估计他也记不住有啥东西。
对于他来说，可能做pizza的游戏和吃pizza是最开心的事情了。
晚上回到家中，兴奋和每个人在说自己做pizza了。（其实就是服务员做完面饼，他们只是放了放作料而已）
代码重构是所有人的噩梦。怎么样重构一系列代码，是一件非常重要的事情。
在没转这篇文章之前，我的重构都是先从部分非关键代码开始重构，而且把这一部分慢慢的独立成一个模块，在采用新的架构的时候，这一块也可以被嵌入的新的架构中。
当然在其中也会遇到一系列的问题，但这样来说会轻松一点。
OK，让我们来看原文吧。
原文是来自：http://coolshell.cn/articles/5201.html
你曾去想重构一个很老的模块，但是你只看了一眼你就恶心极了。文档，奇怪的函数和类的命名，等等，整个模块就像一个带着脚镣的衣衫褴褛的人，虽然能 走，但是其已经让人感到很不舒服。面对这种情况，真正的程序员会是不会认输的，他们会接受挑战认真分析，那怕重写也在所不惜。最终那个模块会被他们重构， 就像以前和大家介绍过的那些令人销魂的编程方式中的屠宰式编程一样。下面是重构代码的几个阶段，文章来自：The 7 stages of refactoring，下面的翻译只是意译。
第一阶段 - 绝望
在你开始去查看你想要重构的模块的，你会觉得好像很简单，这里需要改一个类，那里需要改两到三个函数，重写几个 函数，看上去没什么大不了的，一两天就搞定了。于是你着手开始重构，然后当你调整重构了一些代码，比如改了一些命名，修理了一些逻辑，渐渐地，你会发现这 个怪物原来体型这么大，你会看到与代码不符甚至含糊不清的注释，完全摸不着头脑的数据结构，还有一些看似不需要方法被调了几次，你还会发现无法搞清一个函 数调用链上的逻辑。你感到这个事可能一周都搞不定，你开始绝望了。
第二阶段 – 找最简单的做
你承认你要重构的这个模块就是一个可怕的怪物，不是一两下就可以搞定的，于是你开始着干一些简单的事，比如重新命名一下几个函数，移除一些代码的阻碍，产生几个常量来消除magic number，等等，你知道这样做至少不会让代码变得更糟糕。
第三阶段 – 再次绝望
但是接下来的事会让你再次撞墙。你会发现那些代码的瑕疵是些不痛不痒的事，改正这些事完全于事无补，你应该要做 的事就是重写所有的东西。但是你却没有时间这么干，而这些代码剪不乱理还乱，耦合得太多，让你再一次绝望。所以，你只能部分重写那些不会花太多时间的部 分，这样至少可以让这些老的代码能被更多的重用。虽然不完美，但是至少可以试试。
第四阶段 – 开始乐观
在你试着部分重构这个模块几天之后，随着重构了几个单元后，虽然你发现改善代码的进度太慢了，但此时，你已知道代码应该要被改成什么样，你在痛苦之 后也锁定了那些那修改的类。是的，虽然你的时间预算已经超支，虽然要干的事比较多，但你还是充满希望，觉得那是值得的。你胸中的那团火又被点燃了。
第五阶段 - 快速了结
在这个时候，你发现你已花了太多的时间，而情况越来越复杂，你感到你所面对的情况越来越让你越到不安，你明白你自己已经陷入了困境。你原本以为只需 要一次简单的重构，然而现在你要面对的是重写所有的东西。你开始意识到原因是因为你是一个完美主义者，你想让代码变得完美。于是你开始在怠慢你文档，并想 找到一个捷径来重写老的代码，你开始采用一些简单而粗暴，快速而有点肮脏的方法。虽然不是很完美，但你就是这样去做了。然后，你开始运行测试做UT，发现 UT报告上全是红色，几乎全都失败了，你恐慌了，于是快速地fix代码，然后让UT 能工作。此时，你拍拍自己胸口，说到，没问题 ，于是就把代码提交了。
第六阶段 – 修改大量的Bug
你的重写并不完美，虽然其过了测试，但是那些UT测试对于你的新的代码有点不太合适，虽然他们都没有报错，但是他们测试得范围太小了，没有覆盖到所 有的情况和边界。所以，在这以后，你还需要几周或是更长的时间不得不来修正越来越多的bug，这使得你的设计和代码在每一次quick-fix后就变得越 来越难看。此时，代码已经不像你所期望的那样完美了，但你依然觉得他还是比一开始要好一些。这个阶段可能历经几个月。
第七阶段 - 觉悟
经过了6个月，你重写的模块又出了一个比较严重的bug。这让你重构的那个模块变得更难堪。你发现出的这个问题是和当初的设计不一致，你还发现被你 重构掉的那段老的代码并不是当初看上去的那么坏，那段老的代码确实考虑到了一些你未曾考虑到的事情。这个时候，你团队里有人站出来说这个模块应该被重构或 是重写，而你却不动声色地一言不发，并希望那个站出来的人能在几个月后能觉悟起来。
——————
不知道这是不是你的经历，我经历过很多次这样的事。对于很多维护性质的项目，我犯过的错误让我成了一个实实在在的保守派，我几乎不敢动，那怕看到代 码很不合口味。当然，那些从来没有写过代码的敏捷咨询师一定会说用TDD或是UT可以让你的重构更有效也更容易，因为这样会让他们显得更我价值，但我想告 诉你，这种脱离实际的说法很不负责任，这就好比说—— 我在杀猪的时候遇到了一些麻烦，因为我对猪的生理结构不清楚，或是这本来就是一头畸形的猪，导致我杀的猪很难看，而伟大的敏捷咨询师却告诉我，要用一把更快更漂亮的刀。软件开发永远不是那么简单的事，杀猪也一样。
-----------------------
不过我想，更多的时候，安排你重构一份代码的时候，你可能想到的就是我情愿重写一份也不愿意重构，对着数据库结构和一些业务逻辑，然后就开始重写了。只是这样的写法，后面遇到的问题会非常非常多。你呢？也是这样的吗？
