昨天下午被老大喊去談話了，主要還是對近半年的一個工作總結，一些體會，和一些建議。
這半年主要完成了2個framework，參與了整個開發流程，完成了它們的需求，設計，開發，測試，支持，維護，文檔整個流程，我一直也在問自己什么樣的框架是一個好框架，我想我首先其實也是一個framework的用戶，我們寫framework的也不會什么都從頭做起，重復的去發明輪子，已有的framework也會拿過來用，這會減少開發的成本和周期，所有framework的目的都是方便application developer的開發，方便他們的使用，對于他們來說framework完成技術的細節，他們只要關心業務的邏輯，而且這些framework用起來都要很簡單，簡單的使用，完成強大的功能。當然framework的可重用性也要很強，不然framework只能給每個特定的application使用，這就和application自己開發一個framework就沒有區別了，所以framework還要考慮到各個項目的可重用性，在某些特殊的情況下，framework也不可能滿足所有的需求，這時application用戶就需要在framework上加入他們的特殊的邏輯，這些邏輯是特定于這個application的需求的，不是通用的，這時候就要求我們的framework是易擴展的，插件式的，還要注意的是雖然我們已經做到了這些，但是如果我們開發的framework跑起來的時候，如果性能很差，影響了application的正常邏輯，這也是致命的錯誤，所以我們還需要關心framework的性能，這可能比application關心他們的性能更為重要，因為一些復雜的技術細節是由framework完成的，復雜的技術使用起來可能消耗的資源比較多，我們的framework又是給所有application用的，如果性能太差影響范圍也很大，如何來提升framework的性能也是至關重要的，至少我們要追求我們的代碼質量，每一行代碼都要細細品味；可讀性當然不能太差了，framework的源代碼，application是可以從clearecase或者maven上獲取的，對于一個developer來說可能更習慣于看代碼而不是看文檔，所以代碼和測試就是最好的文檔，在開發消息集成框架的時候，也體會到了單元測試的重要性，如果什么問題都放到集成測試的時候去測的話，修一個bug可能要花半天的時間，所以單元測試也是很重要的，到目前為止，我還是不能完全做到測試驅動開發，一個是因為schedule定的比較緊，自己寫測試的水平也不夠到家，所以有時我也會沖動的先寫代碼邏輯，但是事后我也會補上我的測試代碼，因為自己在看一些開源framework時候，一下子也不知道每個類是干嘛的，所以就會先看測試，從測試中去了解程序的邏輯，測試其實也是一些小的sample，可以指導developer如何去使用，所以詳細的單元測試是免不了的。細節上的實現需要注意的就更多，比如我們公開的api是給application用戶調用的，如果一個api是發送消息的，你取得名字是和發送消息無關的，application用戶使用起來就比較麻煩了，他們可能還需要打開很長的developer guide，來找哪個api可能完成發送消息的功能，如果找不到，他們就會call你了，那自己不是自找麻煩嗎，所以每個public的api名字一定要取的簡潔明了，開發上的每個細節都要注意，細節決定成敗，實現模式出中文版了，這本書明年還是要翻翻的。Framework是寫完了，滿足了這個版本的需求，但是developer會有一些反饋，比如哪里用起來不方便，哪里還是不能滿足要求，或者又有了什么新的技術也需要加入到framework當中等等，這時我們就要去改代碼了，改代碼是很頭疼的一件事，我是這么認為的，而且改了一行代碼，什么東東都要重新測一遍，這就不說了，但是如果時間很長的話，我們可能對一些代碼的實現細節，甚至對哪個模塊該干什么已經忘得一干二凈了，所以就要求我們寫的framework的可維護性要比較強，開發人員發現問題應該比業務用戶強多了，那就更要求我們的代碼要高內聚，松耦合，滿足這些OO的原則，加上很好的模式設計，使我們的framework更易維護，重用，擴展，重構等。寫的很亂，想表達的就是寫好一個framework需要注意的問題，呵呵。