wueddie

最近開始在Unix下讀一些源代碼.下面是一點體會.
1. 工欲善其事,必先利其器
我開始的時候是用find xargs 和 egrep 配合來搜索關鍵字, 看代碼的效率很低.后來裝了ctags,方便多了.最初沒有裝ctags, 是因為覺得可能裝起來費勁, 其實還是很容易裝的,也就是那么幾步, google一下就搞定了.

2. 要及時實踐.
雖然開始是讀代碼的方式比較笨,不過這種干勁非常有用,只有動手實踐了,才有可能取得進步.否則的話,我可能還是停留在閱讀書本上代碼的階段.

3. Unix下的工具看起來不如Windows的工具異用.其實不然,可能是門檻搞一些.多數人象我一樣因此不敢去碰它.入門以后,會發現其實Unix下的工具真是短小精悍. 就拿VIM + Ctags 閱讀源代碼來說,覺得性價比高.符合80/20原則.

如題。
同名的Bean配置兩次。根據配置文件的載入順序，后定義的Bean生效。
看來還得自己小心，不能過于依賴Spring自己的檢查機制（只能在單文件中檢查重復的bean配置）。

J2EE項目中基本都是遵循分層架構的，自然包結構也是基于分層的。DAO層有DAO package。service 層有service package。在這些包下面再根據模塊劃分子包。

我覺得另一種可行的方案是根據模塊劃分包，如果包比較復雜，比如有超過十個的類，再根據層來劃分子包。一般的模塊比較簡單，無需劃分子包。

從高內聚，低偶合的原則來說，這樣劃分具有更高的內聚性。如果按層劃分。其實同層的類并入多大的關系。考慮一下DAO層。這些DAO之間有多少聯系？

新劃分方法的好處是如果需要修改某個模塊，修改的地方相對集中。因為都位于一個包內。

現在分層架構已經非常普遍，沒有必要在包的劃分上體現分層架構。在類名上體現分層架構即可。就是說分層架構無需通過包結構來體現。

新的劃分方案可能有一個問題。各個模塊之間可能有實現上的冗余。如果采用這個方案，需要在這點上采取預防措施。

當然這還是想法，沒有在項目中實踐。希望大家能指出這個方法可能帶來的問題。

最近看了一些項目代碼，了解了它得架構和設計。基本上很佩服。因為這些代碼是幾年以前寫的。但是很多書中提到的模式，原則都得到了運用。但是也有一些地方有不同看法，我覺得很多地方用得并不恰當。
1. 濫用繼承。比如在類結構中已經用了模板模式，照理說子類按照需要覆蓋模板中的實現即可。可是不知出于何種目的。有的子類卻是抽象的，需要從該抽象子類再次擴展，導致繼承樹不必要的深。
2. 濫用接口。經常看到接口中定義了一堆的方法，而且該接口只有一種實現。這種接口純粹是擺設，這樣的接口根本不能指望它有穩定性。實際情況是接口將隨著實現的改變而改變。你說要這樣的接口干嗎？
3. 喜歡抽象出框架，但是這些框架對于當前的應用來說真實不必要的復雜。事實上沒有增加重用，反而降低了代碼的可讀性。
4. 濫用工廠模式。大家不是覺得模式很難實際運用嗎。真想用模式嗎？那還不簡單。給每個對象都定義一個工廠類不就的了嗎？說心里話，我真看不出那些工廠模式到底實現什么設計上的好處。
5. 抽象的能力不夠。在一個分頁的實現中。把查尋字符串抽象到了一個類中。正確的方法應該是把查詢結果抽象出來。
項目在進化的過程中很容易變得越來越難維護，畢竟很多不同的思想和不同人的代碼揉和到了一起。出現各種問題也是正常的。
希望在別的項目中能引以為戒。

今天成功的完成了一個游戲--孔明鎖

簡單的說,道具就是六根長方形木條, 其中五根都是有榫頭的, 另一根則是直木.
這六根木條最終搭成三個方向互相穿透的立體形狀.

這個玩具我上個周末在黃山買的.試過四次, 一直沒有成功.
今天吃過晚飯, 無意之中和老婆合作完成了.

基本上,我的分析能力還是可以的. 能夠抓住要點.
但是動手能力不如我老婆, 眼看就要成功的時候,還是老婆眼疾手快, 完成最好一塊.

其實剛玩的時候, 我就總結出一些基本要領.盡管不是成功的法則.但是能避免不必要的失敗

1. 要以唯一的一根直木為思考的出發點.

2. 有兩個方向各有兩個木條和該直木相交. 其中一個方向需要居中的榫頭(剛開始只是總結出這點).
另一個方向需要偏左或者偏右的榫頭(今天才總結出這個要點).

3. 分析已經有的木條榫頭的形狀, 合理的組合不到20種.

4. 通過手工試驗. 再摸索出一些規律, 養成空間的感覺. 半個小時應該可以完成.


我很少寫Blog.為什么今天例外了.
因為我需要一些東西來證明自己的智商還在. 我說的智商是與具體知識不太相關的一種能力.
都說成功離不開自信. 自信不僅僅是一種信念. 應該通過對自己能力的檢驗來建立自信.

每次項目結束，都會發現有一堆的Bug。如何分析這些Bug，避免重蹈覆轍。

有兩種分析方法， 根據Developer在修復Bug時選擇的CommonCause，選擇比重最大的CommonCause，

然后從各個方面分析RootcCause。總結出可以改進的地方。

我很難理解這種方法，主要是覺得每次都是泛泛而談，對減少BUG沒有真正的幫助。

(我確信這種分析方法沒有太大的意義,因為缺乏對底層原因的了解. 而且Developer在選擇common Cause的時候完全可能沒有合適的而任選一個.經常看到的一個例子是缺乏UT. 這個就不一定是真正的原因,事實往往是做了UT卻沒有發現出Bug.這種分析方法是典型的不深入實際的浮夸作風, 依賴統計的數據而沒有看到統計數據事實上可能存在問題. 這樣的工作肯定效率不高. )

下面是我的一些思考。
分析的基礎應該是Bug，而不是commonCause。直接從CommonCause開始分析，至少可能遺漏一下重要有價值的發現。
有些Bug是有可能避免的。而有些bug可以說沒有什么好的對策。我們應該集中分析有可能避免的Bug。
至于如何分析具體Bug是否能避免，首先應該是造成該Bug的Developer自己分析，讓大家知道Bug是如何形成的，然后由大家集體決定。（這樣做的風險是大家能否接受。）
其次根據Bug引入的時間，和最終測試出的時間，總結有沒有可以改進的大方。
能夠由developer改進而消除的Bug。是最有希望避免再次發生的。
比如，有些bug是打字錯誤造成界面上顯示的內容有瑕疵，一個可行的改進是每次都從需求文檔拷貝。
注意必須要有措施能保證該經驗能被所有Developer知道。
另一個例子是，我有一次，是的，我有一次再修正bug是沒有清除徹底。在總結的時候我掌握了全局查找、替換的技巧。有效地避免了類似的錯誤再次發生。

并非所有錯誤都能由devloper來消除，有一些只能由Tester來消除。比如，一般來說，Tester總是比Developer對界面敏感，更能發現界面bug。
我覺得隨著單元測試的進步，現在對Developer的測試水平的要求也提高了。這也許不盡合理。developer對實現花了很多精力，他不可能在測試上達到同樣的水準。

Why we need Interface? The most important benefit come from the fact: The code depend on the interface no need to care about the implementaion class. and if the implementation class is changed later, the client code no need to update.
This is the feature of Ploymophism of OOP, such as Java. 

In some projects, the struts framework was adopted, so all the field need to be persisted is in ActionForm. In order to avoid that the Service layer /DAO layer will depends on the struts. One way is to define a interface which have getter and
setter to access all the fields need to be persisted. The design is like this:

XXXActionForm --------> XXXInterface <--------------ServiceLayer/DAO Layer
                                          most of them are 
                                          getter and setter
 
I can understand this concern, it seems follow the paterns in Enterprise Application Architecture Pattern. but I can not agree this kinds of design. I believe this is misuse of interface.

First, in this kinds of design, if we add some fields, we need update the actionForm, them also need to update interface.
It is boring, and in this case, the interface can not provide any abstraction so the interface need to evolve as the implementation changed.

Second, there is only one  kind of implementaion in the system, so the interface can not provide the benifit from making use of polymorphism.

In a word, we can get nothing design benefit from Interface in this case, And Have burden to keep the implementaion and interface synchronized.

今天我用Solaris的sort命令排序如下內容。
 <ref bean="NoteDDO100"/>^M
 <ref bean="NoteDDO101"/>^M
 <ref bean="NoteDDO102"/>^M
 <ref bean="NoteDDO103"/>^M
 <ref bean="NoteDDO104"/>^M
 <ref bean="NoteDDO105"/>^M
 <ref bean="NoteDDO106"/>^M
 <ref bean="NoteDDO107"/>^M
 <ref bean="NoteDDO108"/>^M
 <ref bean="NoteDDO109"/>^M
 <ref bean="NoteDDO110"/>^M
 <ref bean="NoteDDO111"/>^M
 <ref bean="NoteDDO112"/>^M
 <ref bean="NoteDDO113"/>^M
 <ref bean="NoteDDO114"/>^M
 <ref bean="NoteDDO115"/>^M
 <ref bean="NoteDDO116"/>^M
 <ref bean="NoteDDO117"/>^M
 <ref bean="NoteDDO118"/>^M
 <ref bean="NoteDDO119"/>^M
 <ref bean="NoteDDO120"/>^M
 <ref bean="NoteDDO121"/>^M
得到的結果如下：
 <ref bean="NoteDDO121"/>
 <ref bean="NoteDDO119"/>
 <ref bean="NoteDDO118"/>
 <ref bean="NoteDDO117"/>
 <ref bean="NoteDDO116"/>
 <ref bean="NoteDDO115"/>
 <ref bean="NoteDDO114"/>
 <ref bean="NoteDDO113"/>
 <ref bean="NoteDDO112"/>
 <ref bean="NoteDDO111"/>
 <ref bean="NoteDDO109"/>
 <ref bean="NoteDDO108"/>
 <ref bean="NoteDDO107"/>
 <ref bean="NoteDDO106"/>
 <ref bean="NoteDDO105"/>
 <ref bean="NoteDDO104"/>
 <ref bean="NoteDDO103"/>
 <ref bean="NoteDDO102"/>
 <ref bean="NoteDDO101"/>
 <ref bean="NoteDDO120"/>
 <ref bean="NoteDDO110"/>
 <ref bean="NoteDDO100"/>

請注意粗體的內容， 看到這樣的結果，我覺得真是不可思議。
有誰能解釋一下嗎？或者這是solaris的Bug。

Programming to Interface 是OOD的基本原則之一。
但是不等于說只要應用了Interface就符合Programming to Interface的原則。
我對以下使用Interface的情形有不同看法。
為DDO建立一個接口（Interface）。然后當DDO跨層使用時，我們用該接口作為參數類型。
我認為這是沒有意義的，根本實現不了Programming to Interface 的初衷。
1. Programming to Interface 的好處之一是可以為不同的實現提供統一的接口。但是這個案例中，只有一個DDO，對應這一個Interface。
2. Programming to Interface 的好處之二是當實現改變時，interface可以保持不變。這樣Programming to Interface 部分的代碼就可以不用隨實現的改變而改變。但是這個案例中，一旦DDO發生了改變，Interface也需要發生改變。
總之，這這種情形下，增加一個接口純屬多余，沒有增加任何價值，反而增加了維護接口的麻煩。
這也說明正確應用Programming to Interface 是多么重要。否則再漂亮的法則一旦濫用，誤用，不僅沒有任何好處，而且可能造成額外的負擔。
造成這種誤用的關鍵原因是，DDO并非一種理想的Object，getter和setter沒有足夠的抽象程度，不能提煉成接口。勉強用上接口也是徒勞的。

今天成功的安裝了Eclipse的UML插件。
要點如下：
1. 在eclipse下建立links目錄，之下再建立任意文本文件如links.txt，內容為
PATH=.<插件所在目錄>
2. 如果Eclipse啟動之后沒有自動識別到新的插件。刪除eclipse下的configuration 下除了config.init外的所有文件。如果誤刪config.init文件，則Eclipse不能啟動。