【经验】关于编程

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