GHawk

擴招的理由很簡單，就是為了減少失業率，大家都變成學生去學校念書了，自然就不會有那么多人競爭工作崗位了。
至于4年后學生要畢業，要找工作的問題，那時領導們差不多也該換屆了吧，就留給下一任的新同志去解決好了。

Sun在科技日上轟轟烈烈地宣傳了一陣。
回來試了一下，果然比之前的版本強多了。

可以更進一步Refactoring到Interpreter模式，把switch(op)去掉，給擴展運算符提供支持。

Maven2 的profile filter功能相當好用，每個開發者可以使用自己的profile，而且很容易就可以實現不同的配置策略（debug, production）

BL層確實需要造很多DAO的Mock，開銷巨大。
但這完全取決于后臺采用什么樣的架構。如果用POJO+O/R mapping來構造Domain Model的話，應該還是比較容易測試的，當然這樣就要把BL的測試和mapping的測試分開了。
如果后臺的BL采用Table Module這樣的模式的話，寫起測試來就比較累了，而且這樣的測試代碼對重構的支持不太友好。

@stoneshao
util.concurrent 的確有一個backport可以在1.4jvm上使用
http://dcl.mathcs.emory.edu/util/backport-util-concurrent

自己實現多線程的東西還是比較容易出現問題的，debug和性能分析都可能花費大量的時間，個人感覺還是用現有的庫更容易一些。

Java 5開始內置的java.util.concurrent.locks包里面有pthread-like的Lock和Condition，很方便。

這樣設計是不是更合適？？

class Test implement OPERATION
{
//定義操作對象
//private IOCObject obj;
private IOCINTERFACE obj; //---------------依賴接口而不是類
//public void Test( IOCObject obj)
public Test(IOCINTERFACE obj) //---------------依賴接口而不是類
{
this.obj = obj;
}
public void execute()
{
if(this.obj.validate)
{
//處理業務邏輯
System.out.println(this.obj.getUsername+"hello!");
}
else
{
//異常日志
System.out.println("MB~~~給的什么數據啊~~我叼!")
}
}
}
////////////////////////////////////////////////////////////////////////////////分割線////////////////////////////////////////////////////////////////////////////////////////
/*萬事具備了,借東風吧!*/
public class Main
{
public static void main(String[]args)
{
//做個東風先
//IOCObject obj = new IOCObject ();
IOCINTERFACE obj = new IOCObject(); //---------------依賴接口而不是類

obj .setUsername("KenIT");
//依賴注入了,高興啊!
Test test = new Test(ob);
//完成工作,打完收功
test.execute();
}
}

另外，由接口的實現者來決定接口上的參數，再扔給接口的消費者，未免霸道了些吧，不是很符合DIP。

今天剛剛到手。
隨便翻了翻，的確是本很棒的書。
第一印象就是這本書應該被列入軟件或計算機專業的教科書書目中。

這就好比法規、制度，它存在，但是依然可以違反它。
文檔提供了一個做事的準則和流程，聲明了一些大家都應該知道和遵守的東西。如果一個人連明文規定的東西都無法理解和遵守。那怎么指望他能夠僅僅通過溝通就能遵守團隊的行動準則，成為團隊的一員呢？應該是很有難度的吧。

文檔是UP進行過程控制的手段，XP用來解決過程中采用的是“溝通”。文檔的適用范圍更普遍一些 ，“溝通”雖然便利，但是會受到很多條件的限制。從UP到XP，可以明確知道哪些文檔從“文檔”變成了“溝通”；從XP到UP，卻很難把所有的“溝通”轉化成“文檔?！边@是因為文檔的成本通常比溝通來得高。

Pair Programming（結對編程）吧

XP應該是對老板、客戶、開發人員來說三贏的開發過程。
當然，要實施好XP并不是簡簡單單的程序員個人能力的問題了，從上倒下、從內到外還有一個體制的問題需要解決，更深一層，還有文化上的問題，畢竟XP是強調團隊的。

我們的項目也正為測試的問題而焦頭爛額。對OO的誤解和缺乏接口設計，導致無法寫出簡單清晰的單元測試，現在的單元測試成了Bottom-Up的集成測試，而且在測試系統異常捕獲邏輯的時候無能為力……

這就不太清楚了，這方面的資料和宣傳確實很少。
在www.eiffel.com上有一些客戶應用Eiffel的成功案例?？梢詤⒖家幌?。

可能現在大規模采用DbC還有些問題：
1. 設計的代價過高。對于很多設計師來說要設計出DbC的OO系統，需要很多的學習和經驗。驗證設計出來的契約也相對比較復雜。
2. 執行的開銷過大，畢竟，在運行時每驗證一個Contract就要多消耗一些機器資源。（但是我認為使用DbC所帶來的可靠性比起這些開銷是值得的。）
3. 缺少語言層次的直接支持。Java的assert關鍵字還只是個語法糖而已。不過隨著AOP的普及，相信在這方面很快會有突破的。

可以參考一下這篇文檔 http://www.iturls.com/Articles/doc/XP_Value.pdf
XP也具有一定的局限性。Agile Process也并不只有XP而已，可以試試其他的過程。有了實踐和總結，應該會有提高的。

的確有投機之嫌，說敏捷過程的東西太少了，就幾章而已。^_^

To Samuel Cai,
說的有道理。
寫的時候一直在斟酌哪樣的例子比較合適，因為OCP相當抽象，所以選出好的例子很難，要說明一定要以某種模式實現OCP很困難，我的這個例子有點類似書中OCP那章一開始那個Client/Server的例子。不過，要舉出違反OCP的例子倒是不少。最典型的就是通過RTTI（運行時類型鑒別）+ switch 或是 if-else 來進行設計。這樣的用法越多，封閉性就越差，模塊的剛性也就越強。OCP主張在設計中采用多態等動態機制取代靜態機制。當然，通過配置文件的方式進行模塊的動態配置也是實現OCP的一種手段。

UP和Agile都是工程過程實踐的總結，林德彰先生說過“UP是正楷，XP是草書。先學好了UP，才能學好XP；先學XP再學UP就會亂套。”
Agile強調的是“代碼是真正有價值的東西?！边@同樣也是實踐的結果。二位對于過程有不同的看法并不能說明孰是孰非，這只是在不同的實踐內容和階段上的總結。在過程的選用問題上，只有不斷地實踐才是前進的方向。

越是需要操作的靈活性，對象映射的對象性自然就會下降。這樣倒不如不用ORM，直接寫JDBC和SQL，但是這對整個系統的架構會產生很大的影響。要指望Mapping和持久層沒有性能損失是做不到的。就像吃海鮮，你越是要新鮮的海鮮，就越要放棄復雜的加工和運輸手段。這個問題的解決可能不是ORM能夠勝任的，或許更大程度上依賴于數據庫系統。
軟件設計是一種trade-off，技術本身沒有優劣之分。工程師所要做的就是如何把各種技術融合到一起。性能或是對象性操作的獲得也遵循這一原則。

^_^加油！

就是Martin C的那本^_^

現在的越來越像是用面向過程的方式開發的了，OO的蹤跡越來越淺了。也許是因為我沒系統地用過C,或是我用不好面向過程方法，我覺得非OO的設計正在把這個系統變得越來越丑陋。（我沒有貶低面向過程方法的意思，好的面向過程設計應該也有它優美之處吧^_^）大家花費時間和精力寫出來的代碼沒有什么重用性可言。大家在設計上下的工夫太少了……

讀書筆記一直沒開始寫。究其原因，這本書實在寫得太貫通了，OO的五大原則都是相互牽扯的，設計模式也是綜合運用的。讀書心得頗多，而整理歸納需要花些時間。既然決定要做，就該認真去做，不會敷衍了事的。

我本來在制造業，轉行轉了兩年，才轉到軟件行業。對工作看得很穿了。應屆畢業生，對社會的了解不多，當時找工作也很盲目。我想，當時，無非就是希望找個既能學到東西又能賺到大錢的公司，次一級么，只能賺到錢或是只能學到東西也行。雖然，最后進了一個公司賺錢不算少，但是做的事情實在是…… 感覺自己的青春就這樣浪費了，于是往外跳。因為是轉行的，沒什么實際經驗，IT現在搶飯碗的人又多。投出去的簡歷一度沒有結果。曾經懷疑自己這樣堅持是否有意義。直到今年，情況才漸漸好轉，群碩、花旗都給了我offer，但最后都沒有選擇去那里?，F在在一家小公司，因為覺得現在的老板不是一個浮躁的人，并不是趁著IT紅火的時候來卷錢的“商人”。最后，我明白了自己的需求：不是快速賺大錢，而是好好利用青春時光，充實自己的閱歷，牢固自己的基礎，做自己喜歡的事情。

對于應屆生，最重要的是清楚自己真正想要的，可以是錢，是知識，是健康…… 無論做什么事，之前請先明確目的，再制定計劃實施?？赡芎髞砗芏嗍聲阆胂蟮牟煌?，但是請你在心中牢記自己選擇，堅定地去實踐。道路可以不同，但是目標不應該偏離。

在這樣的一個團隊中開展xp是比較費力。我覺得XP倒不是要個人能力怎么高，而是團隊的平均水平比較一致，水平低就一塊兒低，水平高就一塊兒高，這樣用于溝通和理解的花費就比較小了。
另外，測試也很重要，XP的快速原型迭代依賴于優良的測試案例。也是迭代得以推進的必要條件。

在Agile的實施方面有沒有比較好的Guide？
請高手多多賜教！