That way I want to stay

這是我的個人主頁，有興趣的同學大家互相關注一下：
http://www.tuijianba.com/9889.html

最近一直在開發一款IDE，本來設計的目標只是一個單機版的客戶端，不會連接任何服務端。后來用戶突然加了一項需求，想要訪問數據庫，去查詢一些數據。 其實這本來也不是什么怪異的需求，只是一種C/S系統而已。那時候剛聽到這個需求的時候，馬上想到的是，用hibernate, ibatis還是直接用JDBC。不如用ibatis吧，只需要查詢幾個表的幾個字段而已，這一項剛好足夠。 可是要增加數據庫的支持時，心里特別的別扭，這款IDE的目標客戶是遍布各個地方的，這一點就決定了，我們不可能用C/S的方法。 后來是在online system上加了一個web service，讓這個IDE去調用。這樣任何地方都可以訪問這個服務了。 就算不論這一點，在考慮要用客戶端直接連數據庫的時候，心里面就像吃了螞蟻似的，非常不爽。不知道是因為B/S系統做多了，還是因為覺得客戶端直接連數據庫本身就是一種不對的做法，總之現在已經有點不喜歡C/S結構的系統了，或者說，不喜歡客戶端/數據庫服務這樣的系統。 不知道諸位程序員同
文章來源:http://blog.csdn.net/Wingel/archive/2007/01/25/1493585.aspx

?程序員有個偏好，那就是實現，他們喜歡把東西實現出來。這是一個優點，實現能力越強的人，一般編程能力也越強，我們也就可以說，他的技術越強。
　　但是喜歡實現卻又是程序員的缺點，因為他們在實現一樣東西的時候，經常會不想去理會其他的事情。比如說，程序員接到一項任務時，普通的程序員就馬上會開始動手。稍微好一些的程序員則會仔細思考一下再動手。可惜，這樣子也是程序員管理能力欠缺的一個原因。
　　當你的能力足夠的時候，你應該懂得，把分配給你的任務計劃一下，看看多久完成，如果你要把這個任務分塊的話，嘗試估計一下各個塊的完成時間。不要因為擔心預計得不準，就不去估計。因為有個計劃給領導，絕對比沒有的強。
　　開發經驗逐漸增多的情況下，你已經有能力相對準確的計劃自己的任務了。這時候你應該去找你的領導，把他今年可能會分配給你的任務看一下。這件事情很重要，因為你不做的話，你還只是一個程序員。因為你對自己的能力已經有了充分的認識，也能相對準確的估計你的開發進度了。你可以好好把今年的任務計劃一下，把更新好的進度表給你的領導。因為他對你開發進度的估計，怎么樣都沒有你自己估計的準確。你能給一份計劃，他會很開心。
　　現在，你已經有能力計劃自己整年的開發情況了。
　　但是計劃會改變。　　
　　我們要擁抱計劃的變更！
　　你跟客戶，或者負責需求的人熟嗎？只有時刻掌握著需求的變化，才能時刻把握好自己的計劃。
　　你跟QA熟嗎？QA對你這個人開發質量的印象如何？清楚自己的開發質量，才能保證把事情做好的能力一直在進步。
　　你跟領導熟嗎？你保證你做的事情領導都知道嗎？你想做什么領導也知道？
　　你敢不敢說，所有跟你有關的情況，都盡在你的掌握？
　　會不會覺得這些很像空話，很不實際！
　　但是有做總是有好處的！
　　你做得越多，你越過程序員就越快。因為你不能，也不想只是單線程的程序員！

???? 前了陣子，做了個firefox下的插件，在了解它的插件運作的過程中，才發現，原來程序還可以是這樣組成的。
??? 我們現在的所有B/S程序，UI上就是由HTML＋JavaScript組成的，而它這樣的局限就是，這樣的UI只能在瀏覽器上運行；而且它的UI會比較簡單，不能像桌面程序中的一些效果。
??? 前面那個問題，其實很容易回答，大部分桌面程序也只能在Window上運行，大部分人都會裝Windows，但是大部分人也都會裝瀏覽器。
??? 而后面這個問題，就是我要說的內容了。Firefox里面所有界面上的布局，都是用類似于HTML的XUL語言生成的，它比HTML支持更多的UI，更方便的一些操作。
??? 當你發現，用HTML就可以構造出一個功能非常復雜的GUI時，當你發現光光html就可以做出一個Firefox那樣的界面時，當你發現，Firefox這個平臺上所有的程序都是由HTML組成時，這就是我的驚異了。
??? 當你發現，其實用HTML就可以做出所有的GUI程序時，這就是Moliza的思路了（其實NetBean的RPC中各個Plugin的UI的思路跟這個有點類似）。
??? 當你發現，你要打開一個程序，你只需要一個瀏覽器，打開一個網頁，其余啥都不用做時，這就是Google的思路了。
??? 這就是我的感覺。
??? 而且我在做這個Firefox的插件時，我一直感覺我在用AJAX，其實AJAX的思路，最有價值的就是，UI上每次變更，不需要刷新整個頁面，不需要 Reload整個UI，只需要變更它需要變化的部分，就像桌面程序一樣。而你在用Firefox的時候，你會感覺到Firefox在刷新什么東西嗎？

敏捷開發的必要技巧完整版.rar ?或者 下載

鏈接： 第14章結對編程.rar ? 或者 下載

結對編程的好處：

聯合兩人的知識去對付一個難題。

知識互相傳遞。

更有效的查錯跟糾錯。

程序員都很開心。

減少員工離職的損失。

?

結對編程需要的一些技能：

用代碼解釋已有的設計結構。

用例子來解釋。

用圖表來解釋設計思路。

如果你無法把你的設計思路表達清楚，把代碼寫出來。

讓比較迷惑的搭檔來寫代碼，這樣他就可以較好的融入你的概念。

經常的休息。

經常的更換搭檔。

具體內容請下載pdf觀看。

下載地址： 第13章測試驅動編程.rar? 或者? 下載

TDD及它的優點

?

??? 上面這種編程的方式，就叫“測試驅動編程Test Driven Development (TDD)”，因為我們總是在寫真正代碼之前寫一個通不過的測試，然后再寫真正的代碼，讓測試通過。

??? 跟測試后行的開發方式相比，它有如下好處：

??????????????????????????????????????????????????????

??? 1.為了更容易的寫單元測試，我們會廣泛的使用接口（比如StudentRegistryChecker等）。這個會讓單元測試代碼很容易讀跟寫，因為測試代碼里面沒有多余的數據。如果我們不用TDD而是直接寫實現的話，我們經常會使用現成的類（比如StudentSet），測試為了調用現成的類，就不得不創建很多多余的數據，創建很巨型的對象，就像Student或者Course。

???

??? 2.因為廣泛的使用接口，我們的類之間就不會藕合（比如EnrollmentSet就一點都不知道StudentSet的存在），因此重用性更好。

?

??? 3.寫單元測試的時候，很容易就可以為一個行為寫一個測試用例，讓它通過，然后為另一種行為寫另一個測試用例。也就是說，整個任務會被劃分成很多小的任務，獨立完成。如果我們不用TDD而直接實現的話，我們很容易就會同時把所有的行為都實現了。這樣花的時間長，而且在這相當長的時間里面，寫的代碼都是沒有測試過，不能保證準確性的。相反的，用TDD的話，我們只實現要測的行為的代碼。它只花費很少的時間（幾分鐘），而且可以馬上測試。

到 第12章單元測試.rar ?或者 下載 ? 下載pdf。

??? 單元測試跟驗收測試有什么區別？驗收測試測試的是系統的外部行為，而單元測試是測試系統內部結構，它只測一個單元（類，甚至一個方法）。驗收測試屬于客戶的，我們沒有權利決定驗收測試的內容。我們頂多只是幫忙客戶根據用戶例事寫出驗收測試。單元測試屬于我們，因為系統里面有什么類，每個類都做什么，是由我們決定的。客戶就沒有權利涉及了，而且我們也不需要他的參與。我們只是根據我們對這個單元（類）的期望寫出單元測試。因此，這種測試又叫“程序員測試”。

     摘要: 之前講了怎么對代碼進行驗收測試，但如果代碼跟UI相關的話，驗收測試又要怎么寫？  閱讀全文

     摘要: 當你實現了一個用戶例事（user story），你怎么判斷你的代碼是真正的，是用戶真正想要的？  閱讀全文

pdf下載地址：　第9章用CRC卡協助設計.rar
或者：　下載

摘錄一些東西，具體請下附件觀看：

因為在這些卡里面，我們寫上了類名，它的職責，以及它的協作關系，我們管這樣的卡片叫“CRC卡”。CRC就是Class，Responsibility和Collaboration的簡稱。

CRC 卡的典型應用　

為什么用CRC卡，而不用文檔或者更先進的UML工具？

1. 卡片上面的空間很小，這樣就可以防止我們給這個類太多的職責。如果一個類的職責太多的話（比如，超過4個），嘗試以更抽象的方式去考慮一下，將職責劃分。

2.CRC 卡主要是用在探索或者討論類的設計的階段。如果我們覺得這個設計不行的話，我們既不用修改文檔，也不用修改類圖，只要把卡片丟了就行了。此外，一旦設計完成，我們就可以把所有的卡丟了。它們不是用來做文檔的。

?? 3. 如果我們覺得現在的卡片不合適，之前設計的比較好，我們只要簡單的把之前的卡片拿出來組合就行了。

第 8 章 以用戶例事管理項目

?????????????????????????????????????????????????

什么是用戶例事 (user story)

?

假定這個項目的客戶是個飲料自動售貨機的制造商。他們要求我們為他們的售貨機開發一款軟件。我們可以找他們的市場經理了解這個軟件的需求。

因此，我們的客戶就是他們的市場經理。談需求的時候，有一回他這樣說：“用戶往售貨機每塞一個硬幣，售貨機都要顯示當前該客戶已經投了多少錢。當用戶投的錢夠買某一款飲料時，代表這款飲料的按鈕的燈就會亮。如果那個用戶按了這個按鈕，售貨機就放一罐飲料到出口，然后找零錢給他。”

上面的話描述的是一件事情，一件用戶通過系統完成他一個有價值的目標（買一罐飲料）的事。這樣的過程就叫“用戶案例 (user case) ”或者“用戶例事 (user story) ”。也就是說，上面我們的客戶所說的話，就是在描述一個用戶例事（ user story ）。

( 我解釋一下為什么用例事這個詞，沒興趣也可以忽略。在一個系統面前，每個用戶要完成同樣的目標，都要做這個系統設定的例行的事，這件事情不是一個例子，所以不叫事例，這也不是故事，也不能算一段歷程，而是一個例行的事。 )

　pdf下載地址：　第8章以用戶例事管理項目.rar