1.关于多人协作。如果分支B是建立在分支A的基础上，那么当分支A出现问题时需要返回到分支A进行修改时，分支B的工作难道就要被废弃吗？
所以应该写好接口，比如在开发分支B时，记录下它是基于分支A的哪些改动；然后当分支A不得不返回修改时，只要分支A再次实现了分支B所依赖的接口，那么分支B就是可用可直接移植的。在这里的“接口”，是指数据的存在与数据的操作方式。
2.像git，commit是有顺序的，如果我们reset到一个commit，它前面的commit也必须恢复到文件中——即使这些commit跟我们想reset的commit毫无关系。
git的commit，不应该是线性的，而应该是像零件一样可以拆装，只要实现了同样的接口，就可以装上。一个零件被拆下，只有依赖这个零件提供的接口的零件需要被拆除。现在线性的commit更应该叫history。
3.css的代码排放，不应该基于元素的文档流位置，同一个元素的放一堆；而应该先基于功能在新位置开始书写，再按照文档流排放。
4.所有的效果类（如弹窗，渐变）都必须提供完成时的回调接口。
5.关于以新易旧时的过渡：
简言之，如果重构手法改变了已发布接口（published interface），你必须同时维护新旧两个接口，直到你的所有用户都有时间对这个变化做出反应。幸运的是这不太困难。你通常都有办法把事情组织好，让旧接口继续工作。请尽量这么做：让旧接口调用新接口。当你要修改某个函数名称时，请留下旧函数，让它调用新函数。千万不要拷贝函数实现码，那会让你陷入「重复代码」（duplicated code）的泥淖中难以自拔。
6.css的z-index需要维护文档
7.我认为，在if-else或者for中有变量声明时，var声明确实应该移到function的最前面；但当非这种情况还把var移到最前面的话，会使得读代码时看不懂这个变量是从哪儿开始起作用的。
7.1 反对，声明都提前能知道函数内部用了什么变量标识，可以避免写var data时，把原来就存在的data变量覆盖。
8.语义化和低耦合是不可调和的矛盾。低耦合是去界使得组件更容易融入其他界，语义化是描界使得组件具有约定俗成的形状。
9.有时候我们需要替换变量，但因为js函数与作用域绑定，所以：
9.1 当我们不能改变作用域的值时，这时候就不能直接把将来需要替换的对象写在作用域中，而是放在作用域的一个对象的属性上。如：
ctrl.step[1](function(data){//这里data是传入的数据，我们可能想在step的处理中把data原来的对象替换成新的对象
data = {text: 'I am new'};//但这样，只是对函数内部的变量data的引用指向一个新对象，而data原来的对象并没有变化
})
这种时候有一个简单的方案：
ctrl.step[1](function(n){
n.data = {text: 'I am new'};//把将来需要替换的对象写在一个对象n的属性data上
})
9.2 有时候我们可以换种思路，直接改作用域中的值；而作用域外部并非保存这个内部值，而是保存对这个内部值的get函数，每次需要使用这个内部值时就调用get函数获取作用域内的值；因此当内部变量变化时外部也能获取到变化后的值或引用。
var o = (function(){
var arr = [1.2,3], str = 'string...';
var obj = {
arr: arr,
str: str
}
return {
get: function(key){
return (arguments.length === 0)?obj:obj[key]
},
set: function(key, value){
if(arguments.length === 1)
obj = key
else if(arguments.length>1)
obj[key] = value
}
}
})();
......
ctrl.step[1](function(get, set){
var data = get();
data.arr = [1.3];//这样设置属性原值会发生改变
data = {};//这样原值不会变化
set({text: 'I'm new'});//这是推荐的设置方法
})
10.关于过度解耦
百度不到这个关键词的相关讨论，似乎解耦到极限是业界准则所以不存在"过度"。
但在这篇文章有涉及
http://www.cnblogs.com/guaiguai/archive/2007/09/23/903114.html
《怪怪设计论闲谈篇：职责与解耦的矛盾》
在我看来，以上手段折射到设计和编码的最终产物，其表现形式就是类的大小和数量。密密麻麻的小类我个人也不习惯很难做到，但我仍然觉得，哪怕一个类只有50行，我觉得只要有一点点理由应该这么做那就相当于说必须去做(虚心接受，坚决不改)。在这点上我有点认同Javaeye上前几年鼓吹什么组合子编程的那家伙，只实现很多很多的基础组合子。问题是拆的太散，最后类之间的逻辑对一般人的脑力和项目的成本承受能力就形成了考验。
是的，问题在于拆得太散，一地螺丝扳手，不知道已经用的是怎么个用法、要用时该用哪些。
在看这篇文章前我在想，如果过度解耦，得出的结果会是一个组合体，而不是有特点的一眼就能弄清其功能的东西。
问题就是在于：职责与解耦的矛盾。标题一针见血。
我认为，是否该将某个组合解耦，取决于你要的是一个具有某些功能的成品，还是一些工具。
如果要的是成品，成品是有其特性、职责的，这些一旦解耦就不再是我们期望的成品。
11.解耦是为了复用，我认为把方法看做可重用的数据是一种很有用的关于如何解耦的思考方向。
12.js由于声明提升，程序员喜欢把var声明放到前面。但这样容易在代码复制时，漏复制放在前面的var声明。
12.1 我明白声明提升的意义之一了：可以清楚地看到作用域内的成员，从而清楚地知道其中的函数的活动对象中会留存住哪些数据。
13.把所有css写在一起有个好处是重复命名变量时在一开始就能发现
14.function F(settings){};除非我要在new F()时用到settings，不然绝不传settings而是在外部做extend