That way I want to stay

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

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

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

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

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

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

結(jié)對編程的好處：

聯(lián)合兩人的知識去對付一個難題。

知識互相傳遞。

更有效的查錯跟糾錯。

程序員都很開心。

減少員工離職的損失。

?

結(jié)對編程需要的一些技能：

用代碼解釋已有的設(shè)計結(jié)構(gòu)。

用例子來解釋。

用圖表來解釋設(shè)計思路。

如果你無法把你的設(shè)計思路表達(dá)清楚，把代碼寫出來。

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

經(jīng)常的休息。

經(jīng)常的更換搭檔。

具體內(nèi)容請下載pdf觀看。

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

TDD及它的優(yōu)點(diǎn)

?

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

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

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

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

???

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

?

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

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

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

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

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

pdf下載地址：　第9章用CRC卡協(xié)助設(shè)計.rar
或者：　下載

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

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

CRC 卡的典型應(yīng)用　

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

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

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

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

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

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

什么是用戶例事 (user story)

?

假定這個項目的客戶是個飲料自動售貨機(jī)的制造商。他們要求我們?yōu)樗麄兊氖圬洐C(jī)開發(fā)一款軟件。我們可以找他們的市場經(jīng)理了解這個軟件的需求。

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

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

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

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