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