1. 程式人生 > >離開公司前寫給在一起奮鬥了半年多的兄弟們

離開公司前寫給在一起奮鬥了半年多的兄弟們

對敏捷軟體開發方法的一些體會:

我覺得推行一個新技術最大的阻力還是來自程式設計師自身
管理層一般不會關心開發方法和技術細節的問題
struts的流行恐怕主要也是技術人員發自內心的認可和推崇造成的吧
畢竟這牽涉到他的切身利益(工作效率、成就感、樂趣。。。)
同樣的道理,單元測試和其他敏捷方法也要首先打動技術人員的心,然後想不流行都難
目前的情況與這兩種技術本身的特點也有關,單元測試是陽春白雪,struts是下里巴人

初次接觸,本能的抗拒

我自己的經歷就是這樣:03年中期時,我們技術總監讓我研究一下junit和eclipse
那時候我用struts和jbuilder用的正爽,瞟了一眼覺得eclipse太簡陋了(其實是自己被jb這種傻瓜相機慣壞了)
junit就更無法接受,那時覺得程式設計師寫業務程式碼天經地義,寫測試就是自虐
於是就丟在一邊不再看了(可是如今,這兩樣東西已經是我工作中最重要的工具了)

大多數人都走過的彎路

現在每次看到缺少測試的程式碼以及還在不停製造這種程式碼的程式設計師,我就會感嘆前幾年自己走的彎路:
04年我經歷了一個專案,20人在客戶現場開發,到了後期的時候,整個專案就像一座沙子堆起的巨大城堡,稍有不慎就會跨塌
於是,程式設計師們開始變得消極、焦慮、易怒、神經質。。。。(似乎還沒有人到更年期 )

  • 消極:不願意修改bug,不願意改程式碼以滿足使用者新提出的需求
  • 焦慮:擔心剛剛修改的程式碼會破壞已有功能,對下一個版本能否正常工作毫無信心,夢到測試人員報告其大量bug
  • 易怒:經常對測試mm發火,私下裡詛咒客戶,抱怨別人弄壞了自己的程式
  • 神經質:系統偶爾出現奇怪行為就胡亂猜測,改了不該改的地方導致更多奇怪現象出現
  • 那段日子簡直不堪回首,是對程式設計師身心的雙重摺磨!

走上敏捷之路,相見恨晚 

時間到了2005年的春天,單元測試(連帶著輕量級架構Spring和敏捷方法)真正走進了我的世界
從那以後,我發現我變得快樂了並且再也離不開它了
編成不再是一件痛苦的事,至少不那麼痛苦了,反而增添了很多樂趣和滿足感,祕密就在於:

  • 勇氣:單元測試是自動化的迴歸測試,她讓我對自己的程式碼充滿自信,每一個測試就像攀巖者釘在峭壁上的一個楔子,沒有了程式衰退的擔心,於是我可以大膽的重構、積極的擁抱變化;
  • 快速反饋:每寫一段程式碼,我都可以在幾秒鐘之內看到他的執行效果,免去了打包、部署、重起server以及在一堆日誌裡找結果的工作,開發的效率極大提高;
  • 測試驅動設計:通過編寫測試可以準確的理解需求、發現問題、發現介面,在不知不覺間做出最合理的設計;
  • 文件:測試是最好的詳細設計文件,不會過時、可執行。

對於新事物的懷疑總是不可避免的,很多人最主要的是擔心寫測試會降低開發效率------寫測試程式碼時間+寫功能程式碼時間〉〉寫功能程式碼時間
對於這個問題,marting有過回答,大致的意思是:如果軟體開發的主要工作是敲鍵盤的話,那個命題是成立的。
事實大家都知道,這個敲鍵盤的時間只佔很小比例,但畢竟也是多用了,那麼在哪兒又節省了呢,答案就是快速反饋
快速反饋:每寫一段程式碼,我都可以在幾秒鐘之內看到他的執行效果,免去了打包、重新部署以及在一堆日誌裡找結果的工作;
寫測試3+寫程式碼3+跑測試看結果1=7
寫程式碼3+打包2+重新部署10+用ie訪問程式2+在一堆日誌裡找結果並確認5=22
我一點也沒誇張,那個was5重新部署一次真的很慢,有時還需要重起服務。

不斷實踐,終獲回報 

來到e-ma以後,我繼續在工作中實踐著敏捷方法

包括在技術論證階段極力推薦Spring框架; 在編碼開始之前做了專案原型和開發模板;配置luntbuild持續整合伺服器;提倡編寫單元測試。。。

經過國檢專案的考驗,我更加堅信:敏捷方法是快速開發高質量軟體的一把鑰匙,因為它所承諾的那些好處全都得到了兌現:

我所開發的支付、衝正、清單模組全都按時完成,並且bug很少

雖然需求、介面一改再改,但是有密集的單元測試作保證,我總能毫無顧忌的快速的去調整程式

像國檢專案這樣的系統結構複雜、通訊方式多種多樣、需求變化頻繁、質量要求高、工期緊張的分散式系統,對於任何開發方法都是個嚴峻的挑戰,

但是我驚訝的發現,相比那種簡單的本地資料庫應用,敏捷方法在這樣的系統裡能夠更充分的發揮出威力 ,看看它是如何應對這些挑戰的:

  •  系統結構複雜:TDD正好可以產生一個簡單、鬆耦合、可測試的設計,極大的降低系統複雜度,防止過度設計
  •  分散式系統、通訊方式多種多樣:這對程式設計師是個巨大挑戰,但是mock單元測試讓事情變得簡單許多,mock可以輕鬆模擬任何外部資源和介面
  • 需求變化頻繁:敏捷的口號就是"擁抱變化",有單元測試作保障,讓變化來的更多些吧
  • 質量要求高:有單元測試作保障,每一段程式碼都有一個測試用例守護,同一個bug不會出現兩次或以上
  • 工期緊張:還記得"快速反饋"吧

敏捷方法很簡單

它不是軟體天才專用的難以理解和掌握的神祕方法,它只是一些普遍原理和經驗的總結、一種理念和一組最佳實踐。

 "I'm not a great programmer; I'm just a good programmer with great habits"
                                                                                ------Kent Beck
 

結語

 經過了那麼多沒日沒夜加班的日子,我們建立了深厚的戰鬥友誼,也都被折磨得身心俱疲:)

我始終堅信,軟體開發是一項偉大的、創造性的勞動,它應該是一件充滿樂趣的事,同時給我們帶來成就感和體面的收入;

程式設計師應該是一群快樂的傢伙,每天享受著自己喜歡的工作,有足夠的時間去打籃球、跟哥們兒喝啤酒、培女朋友看電影;

雖然現實還與此相去甚遠, 但這是我們要努力達到的境界,希望這篇文章介紹的方法能有所幫助。

最後,祝你們身體健康、程式設計快樂!