上面這個笑話卻是聽起來聽funny的。這讓我聯想到，我們在實際的專案中，應該什麼時候提供介面？
說道這裡大家會想到的是什麼？當然是**抽象三元則了：dry、yagni、rule of three。簡單的介紹下這三個。dry， don『t repeat yourself，是物件導向設計原則中經常被用到的原則之一，他的意思很簡明，不要重複自己，意指在開發過程將通用的功能提出來作為介面供別人呼叫，避免**重複。這個聽起來很有道理，想一下，一旦我更改了需求，有時候我僅需要更改底層的介面就好了。
yagni，you aren't gonna need it，是敏捷開發中提倡的，叫做你不會需要他了，意指你自以為有用的功能，實際上都是用不到的。用於敏捷開發過程中，快速的完成功能。這裡聽起來他和dry是乙個死對頭，乙個提倡物件的抽象話，找到通用的介面，另外乙個則倡導不要把精力放在抽象化上面，你只要完成你自己的就可以了。但是反觀這兩種理論都有自己的道理，於是出現了另外乙個角色：rule of three。
rule of three，我稱它為第三次原則，意指當這個功能第三次被用到的時候，你將有必要把他做成乙個介面。理由是如果乙個功能或者函式被用到了兩次，那麼沒有必要花時間去抽象它，但是當這個介面第三次被呼叫的時候，你將考錄該把這個介面抽象化了。
上面說了很對是否應該抽象話的問題，相信大家已經有些了解了。下面我說下我個人的意見。
做code review的時候，經常會聽到這樣的聲音，我這樣子（可能增加了複雜性）
做是考慮到以後有人會用，所以提供了乙個比較通用的介面。我們先分析一下這樣的情景，以後會用到是什麼時候？我清楚的記得，我為了通用性，曾把乙個布林型別硬是存成了字串型別，可是結果是到現在也沒有出現當時我考慮到的別人會用的情況。其次，乙個功能可以有不止乙個的解決方法，我們又如何確保我們提供的介面在被人用的時候，他會覺得用的很舒服。
說了這些，好像都是在只颳風不下雨，那我們到底該什麼時候提供介面呢？我的回答是，最近
一、兩個迭代會用到的時候。比如我們在做乙個前台的排序，使用者可以改變某一型別的幾個子模組的顯示順序。而這個功能在這次迭代中有用到，且不止一次，但是在不同的卡上。那我就完全有必要把它抽象程乙個介面，方便呼叫。可以看到這個迭代中我們會用到它不止一次，那我完全有理由去做。而且更讓人驚呆的是，我們的下乙個迭代竟然又有兩三個地方用到了排序，而且大家用這個介面很容易的實現了功能，畢竟我向大家提到過這個介面的使用，可以看出我抽象話它是正確的。
總之來說，抽象不抽象是看到底有沒有具體的需求，一味的空想給人以空穴來風的感覺。到底有沒有用誰也不知道，只是覺得可能有用。所以當你男朋友生日快到來的時候再準備介面吧。
創業，你準備好了麼
很多人提到創業就認為，很簡單啊，某天突發奇想，有個idea，找幾個人一拍腦袋，可行，然後製作原型，發布，或者找找風投。對於小idea，賺一票就走，這或許可行，但要是稍大的專案，考慮可持續發展的，就不行了，人無遠慮必有近憂，你的團隊足夠強大麼？未來是不可預知的，所以本文不打算討論個別的特例，當然成功就...
敏捷專案實施，你準備好了麼？
敏捷是最新的流行趨勢，如果你還沒有在用，那值得一試。不過在開始前，最好先確認一下你準備好了麼。下面分享一點個人經驗。1.為什麼引入敏捷？這是乙個目標設定問題。僅僅因為敏捷很流行，希望學習，還是因為敏捷是另乙個 銀彈 很簡單的乙個標準，如果沒有目標，怎麼能夠確認成功？所以在實施敏捷前問問為什麼會對你非...
微軟大會Ignite，你準備好了麼？
微軟每年都會有一次技術盛會，這個盛會在很多國家都會舉行，他的名字叫 teched 我參加的最近的一次teched是2013年的那次，之前也曾在51cto發表過幾次大會記錄，如 不過相信中國區的同學都會發現，teched2014消失了，其實也不能說是消失了，只是這一次，中國區的teched缺席了。令人...