個人工作總結(轉)

 
個人工作總結
 
 
2010-04-12 作者：ttion 來源：ttion的blog
 
一個人的軟體工程

一個簡單的網頁、自助建站、個人Blog、CMS，這是本人自認的站長生涯，我人生的第一桶金也是來自個人建站，對“個人站長”這個詞彙總會有點感慨，而一個人的軟體工程即始於此，做的第一套系統的名稱叫做“免費者內容管理系統”(最初的想法是想通過這套程式開源，建立一箇中國的開源社群“免費者www.mianfeizhe.com”，後來整個域名和網站出售掉了)。

免費者內容管理系統，採用jsp+servlet框架（當時，只學了這些技術）進行開發，版本通過U盤進行控制，當時整體需求還算是比較明確的，因為是防系統，所以開發起來遇到不是業務上的問題，而恰恰遇到的是一些技術問題，前臺靜態化、模板標籤，都是當時開發中的攔路虎，而此時回顧那些通過字串解析、IO流輸入輸出靜態頁面，還是有些欣慰的，因為通過這些實現建立在這套系統之上的一套語言（模板標籤），後來瞭解到的FreeMarker（模板搜尋引擎）正是我所需要的。現在如果讓我再去維護那套系統的話，我想我做的第一件事情就是推翻重寫，以前的程式碼看起來真的太幼稚了，不知道再過一年來看自己的程式碼，我會是什麼樣的心態和感想呢？一個人的軟體工程有痛苦並快樂著。

所謂的迭代開發

這是我做的第一個真實的專案，一個關於手機上網，無線閘道器的資料配置的開發，整個專案開發週期是3個月，採用迭代開發，開發人數6人，三天時間通過會議室形式瞭解需求，以及領取工作任務，然後便埋頭投入到了專案當中，每天加班熬夜到10點鐘左右，同時經常是加完班以後再回家吃飯，每天在心情極度低下，那一陣子經常容易忘事，有時候進入房間就忘記自己要做什麼了。在開發過程當中，由於缺乏溝通，開發出來的東西總是會有些出入（包括開發與開發之間的，開發與需求上的），在後期測試過程當中，發現存取資料沒有經過轉碼，頁面過於複雜，導致使用者體驗是那麼的不盡如意，後來差不多推翻了重新開發，再次進入無發估摸的開發過程當中，現在回想起來都有些後怕。我想是由於前期分析不足、沒有有效的溝通、難以掌控的工作計劃、個人編碼能力等等，導致了整個專案的失敗吧。當然，任何事物都是相對的，有壞的一面肯定也存在好的一面，通過這個專案，首先在技術得到了很大程度的提升，同時通過這個專案自己對軟體工程的重要性也理解的更為深刻，也讓自己對編碼規範、程式設計思想引起了注意，態度的轉變應該是最大的收穫吧。

敏捷開發

近幾年在軟體開發行業，敏捷開發無疑是最熱門的話題，而09年3月份進入的BMS敏捷專案組，也算是接觸了敏捷，從專案開工會，Story評估會議，Story撰寫，站立會議，持續整合，統一IDE構建，結對程式設計等等，對我來說都是新鮮的事物，這些新鮮事物總會讓我著迷，一個又一個有趣的實踐，讓我感受到了開發當中的快樂，以前提交版本時的忐忑與不安，在這個專案過程當中，我完全感受不到。做完整個專案最大的感受——整體計劃可控制，小粒度的Story可以讓每個組員明確每天做什麼。不再糾纏在無法估摸的專案進度當中，飽滿的8個小時工作，整體工作效率有明顯的提升。

敏捷的精髓是“充分溝通、坦誠合作”，敏捷當中的很多實踐都是圍繞著這展開的。

敏捷宣言：

– 個體和互動 勝過 過程和工具

– 可以工作的軟體 勝過 面面俱到的文件

– 客戶合作 勝過 合同談判

– 響應變化 勝過 遵循計劃

雖然右邊的也有價值，但是我們認為左邊的具有更大的價值

敏捷流派XP的價值觀：簡單、交流、反饋、勇氣、尊重。

敏捷實踐

Story評估會議

參會人員：開發、測試、資料（如果客戶不能在現場，可由資料作為客戶代表）、PM，會議採用舉牌的形式決定Story的粒度，取最小的Story的力度作為單位，以舉牌的形式決定一個Story的開發-測試結束週期，一般天數可寫為：1、2、5、10、14、20（一般單位為半天），然後通過全體舉牌的形式得出總分，再除以全體舉牌人數得出一個Story的週期，當然，你有棄權的權利，所以準備牌的時候總會留一張笑臉來表示棄權。每一次參與這個會議時，總會讓我感到比較的高興，像極了拍賣會。

結對程式設計

結對程式設計此前是一項比較受質疑的一個實踐，而經歷過結對程式設計這一實踐的人員，是最樂意接受這一實踐的，至少我是。第一個和我結對的是個女同志，後來由於工作原因，她離開了專案組，而後我和專案經理結對開發，兩個人一臺電腦一個滑鼠一個鍵盤，兩個頭腦，一個是駕駛員（敲鍵盤的人），一個是領航員（前後觀察），兩個人每過十分鐘就可以進行角色互換。當然在專案開始前，挑選Pair時，一定是自願的，且能夠互相尊重的。有效的結對程式設計可以很大程度的保證程式碼質量，可以省去Code Review這一過程，同時這個實踐也是非常容易培養新手。

本地構建&持續整合

在現在我已經很樂意去接收這個實踐了，使用的CC作為伺服器，此前由於機器記憶體不夠，導致執行CC時，就不能做其他事情了，同時由於專案工程較多，在持續整合構建與執行上面花費的時間太多，所以此前總是有那麼一點的反感，而當機器更換後、個人編碼能力的提升、持續整合形成制度，接受持續整合也變得那麼的水到渠成。持續整合就像一個煉丹爐，一直在執行的過程當中，而我們所做的就是一直往爐子裡面扔程式碼，CC自動對那些程式碼進行檢查，然後生成報告。持續整合是很好的試金石，通過持續整合也能提高個人的編碼能力。

TDD(Test-Driven Development)

測試驅動開發，這也是自己一直在努力做好的一個實踐，以前第一次寫單元測試程式碼時總是有那麼一些的不理解，當時覺得寫這些程式碼是沒用的，第一，由於專案組沒有把測試程式碼作為互動物，第二，當時個人對單元測試程式碼瞭解不深刻，覺得是無用的工作。而在後來的重構過程當中，越來越認識到單元測試程式碼的重要性，有時候修改程式碼中的一個小點，都需要圍繞該小點進行一次很充分的測試，浪費了大量的工作時間，同時現在專案組當中，將測試程式碼作為編碼過程當中的一部分（新增程式碼單元測試程式碼行覆蓋率需要達到100%，修改程式碼單元測試程式碼行覆蓋率達到80%），自己對單元測試程式碼編寫也越來越感興趣，不過由於以前老程式碼過於複雜，可測性不高，在修改程式碼時，單元測試程式碼的編寫總是那麼的困難，在編寫過程當中我們專案組使用了，反射、EasyMock等技術來編寫測試程式碼，在維護程式碼時，TDD執行起來總是那麼的困難，當然老程式碼是一個原因，個人的態度也是一個重要的原因，革命尚未成功，同志仍需努力！

TDD的意思是，在編碼過程當中，先編寫UT程式碼，他是簡單的UT程式碼，此時可能會出現紅燈，甚至編譯不通過，根據UT編寫程式碼，讓UT程式碼一步一步通過，直到出現綠燈。在JavaEye中瞭解到有些專案組將單元測試程式碼作為互動物，替換掉一些文件，其實程式碼就是一個很好的文件，當然，你的程式碼要寫的足夠優美、簡單。

站立會議(Stand up meeting)

第一次接觸站立會議時，就感覺的比較的好奇，一塊白板，所有人圍成一圈，專案經理在中間，以結對組為單位，點到哪個Story時，相應負責人根據如下模板進行陳述。

“我昨天完成了...”

“今天要完成…”

“我遇到了…困難”

專案組是第一次執行敏捷，在大家反饋的時候跑題時，可愛的專案經理總會打斷，會後討論。

站立會議一般控制在15分鐘之內，畢竟站著說話腰痛（這是個人理解的）。

我想站立會議，是很好體現敏捷流派XP的勇氣、反饋、交流價值觀的一個實踐，你對問題進行反饋就需要勇氣，反饋的過程當中就產生了交流，確實是一個非常有趣的實踐。在執行過程當中，最好能按照上面的模板進行陳述，讓每個人參與進來，今天是pair中的一個人員反饋，明天就換一個，同時專案經理對人員反饋時，不能帶有個人情緒進行指責，我想這樣一天的好心情都破壞了，同時在執行過程當中不要跑題、延長會議時間、開小會，畢竟其他人還站著呢。

重構

現在在專案過程當中，偶爾會停下來進行一次重構，第一次重構是整改一處查詢，一是由於查詢速度過慢，二是由於查詢資料不太準確，而在我接手重構時，也確實頭大了一下，十一個功能使用同一處程式碼（高耦合），其中的查詢使用在程式碼當中拼接查詢條件，有時改動其中一小段程式碼，都可能導致某個功能出現資料庫錯誤，第一個想法是通過配置檔案控制SQL語句，整理出一個SQL解析器出來，在這個方案執行了一天以後，由於時間原因，以及其複雜度、難維護性的原因，徹底的放棄了，第二個方案便是採用工廠方法和組合的設計模式進行解耦處理，在重構過程當中，總共分配了兩名人員給我，在第一個方案失敗後，施行第二個方案，由於時間問題，他們兩個擔任了測試的工作，從開發到測試，整體重構花費了4天的時間，查詢速度由此前的2分鐘降低到了2秒鐘，程式碼徹底的解耦，設計的變得簡單，當然由於使用工廠方法，日後維護工作量是增加了的。

第二次相對較大規模的重構是，專案組實施程式碼責任田制度，每個人領取一塊程式碼土地，然後通過單元測試程式碼覆蓋率，圈複雜度，問題單數量，程式碼結構作為度量項，進行評斷責任田的執行結果，並予以相應的獎勵。在重構的過程當中，我愈來愈感覺到單元測試程式碼的重要性，曾經歪了一首《勇氣》重構版，聊以抒發對單元測試程式碼之情，“重構真的需要勇氣，來面對流言蜚語，只要你一個單元測試，我的重構就有意義，我的真心！”。

重構應該是一個時刻進行的過程，曾經在JavaEye上面看到了一位仁兄說他們專案組的一件趣事，開發人員A在維護某個類時，五分鐘後提交到配置庫時，發現程式碼不見了，然後詢問，這時候開發人員B說，我覺得這樣實現不太好，我已經將那個類刪除了。從這件事情當中可以看出他們重構的力度，每五分鐘可以進行一次重構。我想我需要對此更加努力了。

Show Case(技術展示)

這個實踐是在敏捷指導書當中看到的，然後，覺得這個實踐非常適合我們專案組，老程式碼過於複雜，整體系統相對比較複雜，每個人都只是某個模組的專家。我想正好可以通過Show Case的形式來改善現狀。由某個人提出某個模組，出發緣由可以是，由於遇到了難題，希望通過大家的力量來解決，可以是覺得自己這塊程式碼的實現很好，希望展示一下自己的技術。同時，通過Show Case可以找出需要重構的程式碼，為問題找到更好的解決方案，這樣大家也可以瞭解其他模組，不再是某個模組的專家。

我們專案組從我提出到現在，執行了三次Show Case，主要以解決問題作為出發點，但是由於講解人員在展示時，講的比較發散，沒有注重點，結果收效不是很大，倒是成了Code Review。我想我們在進行Show Case時，第一，應該事前通知參與人員，能讓參與人員有一個初步的瞭解。第二，展示人員應該掌握好注重點，不要浪費時間在無足輕重的事情上面，同時要把握好時間度，不要讓這有趣的實踐變得無味。

Show Case

會議目的:將工作成果展示給使用者，獲得使用者的反饋，讓團隊所有成員瞭解專案的進展

會議形式：不限，可能只花15分鐘,但是隨時都可以進行.通過展示,也可能得到其他團隊成員對被展示程式碼的意見.

展示內容：程式碼、測試程式碼、介面原型、重構程式碼、好的實踐、新工具的使用、知識共享、教訓、經驗等都可以做為技術展示的素材.

參加人員： 開發團隊、研發代表、客戶

以上是我個人在工作上面的一些總結以及理解，在09年當中學習到了很多東西，在第一個專案組當中學習了技術，以及一些程式設計思想，同時在痛苦的加班當中，來到了第二個專案組，這也讓我深刻的感受到了軟體工程的重要性，如何工作，如何進行時間管理，我想這還是一個需要繼續努力的方向。