我把單元測試的好處都闡述了一遍，可是大家仍然有很多疑慮，其中最主要的是擔心寫測試會降低開發效率——寫測試代碼+寫功能代碼〉〉寫功能代碼
最終由於這個項目工期很緊，否決了我的建議！
daquan198163 2006-09-28 18:13
根據自己三年多來的開發經歷談些感受：
我覺得最大的阻力還是來自程序員自身
管理層一般不會關心開發方法和技術細節的問題
struts的流行恐怕主要也是技術人員發自內心的認可和推崇造成的吧
畢竟這牽涉到他的切身利益（工作效率、成就感、樂趣。。。）
同樣的道理，單元測試和其他敏捷方法也要首先打動技術人員的心，然後想不流行都難
目前的情況與這兩種技術本身的特點也有關，單元測試是陽春白雪，struts是下里巴人
我自己的經歷就是這樣：03年中時，我們經理讓我研究一下junit和eclipse
那時候我用struts和jbuilder用的正爽，瞟了一眼覺得eclipse太簡陋了（其實是自己被jb這種傻瓜相機慣壞了）
junit就更無法接受，那時覺得程序員寫業務代碼天經地義，寫測試就是自虐
於是就丟在一邊不再看了（可是如今，這兩樣東西已經是我工作中最重要的工具了）
daquan198163 2006-09-28 18:48
每次看到缺少測試的代碼以及還在不停製造這種代碼的程序員，我就會感嘆前幾年走的彎路：
04年我經歷了一個項目，20人在客戶現場開發，開發到後期時，整個項目就像一座沙子堆起的城堡，稍有不慎就會跨塌
於是，程序員們開始變得消極、焦慮、易怒、神經質。。。。（更年期？？ ）
消極體現在：不願意修改bug，不願意改代碼以滿足用戶新的需求
焦慮：擔心剛剛修改的代碼會破壞已有功能，對下一個版本能否正常工作毫無信心，夢到測試人員發現其大量bug
易怒：經常對測試mm發火，私下裏詛咒客戶，抱怨別人弄壞了自己的程序
神經質：系統偶爾出現奇怪行爲就胡亂猜測，改了不該改的地方導致更多奇怪現象出現
那段日子簡直不堪回首，是對程序員身心的雙重摺磨
daquan198163 2006-09-28 19:06
自從單元測試（連帶着輕量級架構和敏捷）走進我的世界，我發現我變得快樂了
編成不再是一件痛苦的事——至少不那麼痛苦了——反而增添了很多樂趣和滿足感
勇氣：單元測試是自動化的迴歸測試，她讓我對自己的代碼充滿自信，每一個測試就像攀巖者釘在峭壁上的一個楔子，沒有了程序衰退的擔心，於是我可以大膽的重構、積極的擁抱變化；
快速反饋：每寫一段代碼，我都可以在幾秒鐘之內看到他的運行效果，免去了打包、部署、重起server以及在一堆日誌裏找結果的工作，開發的效率極大提高；
測試驅動設計：通過編寫測試可以準確的理解需求、發現問題、發現接口，在不知不覺間做出最合理的設計；
文檔：測試是最好的詳細設計文檔，不會過時、可運行。
daquan198163 2006-09-28 19:31
前面我提到，很多人最主要的是擔心寫測試會降低開發效率——寫測試代碼時間+寫功能代碼時間〉〉寫功能代碼時間
對於這個問題，論壇裏以前有人討論過了，marting也說明過，大致的意思是：如果軟件開發的主要工作是敲鍵盤的話，那個命題是成立的。
事實大家都知道，這個時間只佔很小比例，但畢竟也是多用了，那麼在哪兒又節省了呢，答案就是快速反饋。
快速反饋：每寫一段代碼，我都可以在幾秒鐘之內看到他的運行效果，免去了打包、重新部署以及在一堆日誌裏找結果的工作；
寫測試3+寫代碼3+跑測試看結果1=7
寫代碼3+打包2+重新部署10+用ie訪問程序2+在一堆日誌裏找結果並確認5=22
我一點也沒誇張，那個was5重新部署一次真的很慢，有時還需要重起服務
最終由於這個項目工期很緊，否決了我的建議！
daquan198163 2006-09-28 18:13
根據自己三年多來的開發經歷談些感受：
我覺得最大的阻力還是來自程序員自身
管理層一般不會關心開發方法和技術細節的問題
struts的流行恐怕主要也是技術人員發自內心的認可和推崇造成的吧
畢竟這牽涉到他的切身利益（工作效率、成就感、樂趣。。。）
同樣的道理，單元測試和其他敏捷方法也要首先打動技術人員的心，然後想不流行都難
目前的情況與這兩種技術本身的特點也有關，單元測試是陽春白雪，struts是下里巴人
我自己的經歷就是這樣：03年中時，我們經理讓我研究一下junit和eclipse
那時候我用struts和jbuilder用的正爽，瞟了一眼覺得eclipse太簡陋了（其實是自己被jb這種傻瓜相機慣壞了）
junit就更無法接受，那時覺得程序員寫業務代碼天經地義，寫測試就是自虐
於是就丟在一邊不再看了（可是如今，這兩樣東西已經是我工作中最重要的工具了）
daquan198163 2006-09-28 18:48
每次看到缺少測試的代碼以及還在不停製造這種代碼的程序員，我就會感嘆前幾年走的彎路：
04年我經歷了一個項目，20人在客戶現場開發，開發到後期時，整個項目就像一座沙子堆起的城堡，稍有不慎就會跨塌
於是，程序員們開始變得消極、焦慮、易怒、神經質。。。。（更年期？？ ）
消極體現在：不願意修改bug，不願意改代碼以滿足用戶新的需求
焦慮：擔心剛剛修改的代碼會破壞已有功能，對下一個版本能否正常工作毫無信心，夢到測試人員發現其大量bug
易怒：經常對測試mm發火，私下裏詛咒客戶，抱怨別人弄壞了自己的程序
神經質：系統偶爾出現奇怪行爲就胡亂猜測，改了不該改的地方導致更多奇怪現象出現
那段日子簡直不堪回首，是對程序員身心的雙重摺磨
daquan198163 2006-09-28 19:06
自從單元測試（連帶着輕量級架構和敏捷）走進我的世界，我發現我變得快樂了
編成不再是一件痛苦的事——至少不那麼痛苦了——反而增添了很多樂趣和滿足感
勇氣：單元測試是自動化的迴歸測試，她讓我對自己的代碼充滿自信，每一個測試就像攀巖者釘在峭壁上的一個楔子，沒有了程序衰退的擔心，於是我可以大膽的重構、積極的擁抱變化；
快速反饋：每寫一段代碼，我都可以在幾秒鐘之內看到他的運行效果，免去了打包、部署、重起server以及在一堆日誌裏找結果的工作，開發的效率極大提高；
測試驅動設計：通過編寫測試可以準確的理解需求、發現問題、發現接口，在不知不覺間做出最合理的設計；
文檔：測試是最好的詳細設計文檔，不會過時、可運行。
daquan198163 2006-09-28 19:31
前面我提到，很多人最主要的是擔心寫測試會降低開發效率——寫測試代碼時間+寫功能代碼時間〉〉寫功能代碼時間
對於這個問題，論壇裏以前有人討論過了，marting也說明過，大致的意思是：如果軟件開發的主要工作是敲鍵盤的話，那個命題是成立的。
事實大家都知道，這個時間只佔很小比例，但畢竟也是多用了，那麼在哪兒又節省了呢，答案就是快速反饋。
快速反饋：每寫一段代碼，我都可以在幾秒鐘之內看到他的運行效果，免去了打包、重新部署以及在一堆日誌裏找結果的工作；
寫測試3+寫代碼3+跑測試看結果1=7
寫代碼3+打包2+重新部署10+用ie訪問程序2+在一堆日誌裏找結果並確認5=22
我一點也沒誇張，那個was5重新部署一次真的很慢，有時還需要重起服務
