【經驗】關於編程

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