個體軟體工程讀書筆記

個體軟體工程讀書筆記

       今天學習看到了一篇關於個人軟體開發流程改善的文章，頗有感觸，遂記錄下來，以備以後參考並鞭策自己執行。

       很多人都在抱怨自己所在的公司的開發流程不夠規範，專案管理混亂，文檔不夠齊全，個階段該有的記錄沒有，該產生的工件也沒有。這一切可能都源於公司的管理，但更大程度上是來自於項目的壓力，使得我們對精細、嚴格的流程心有餘而力不足。那麼是不是在這樣的公司就沒有發展了呢？其實我個人覺得軟體工程的思想以及軟體開發流程的控管和它所依賴的群體沒有關係，如果我們真的理解了軟體工程，那在我們自己的開發過程中去實施、去應用，在應用之後做一個分析、對比。如果成效顯著我們當然可以拿來與同事分享，從而影響他人。

       個體軟體工程也就是將自己的開發工作看做是一個項目來做，既然看作一個項目，那它必然要有多個階段：計劃、需求、設計、編碼、測試、維護。當然我們也可以選擇其中的幾個重點來提高自己的能力。比如我個人比較看中其中的計劃、需求、設計、測試。其他的在開發中受關注程度會少一點。

       下面我按照軟體開發的流程來說說個體軟體開發過程中的自我管理。

l         計劃與跟蹤

無論是管理學還是工程學都很強調計劃的重要性，在專案管理中編寫專案計劃也是一個

重頭戲。在正規專案管理中，計劃階段我們需要對工作進行分解，也就是WBS，然後對活動進行細分、排序、標識活動的時間、尋找關鍵路徑、估計項目時間、成本、人力等。然而在我們簡化版的個體軟體工程中，我們把重點集中一下（因為畢竟精力有限），我覺得有幾個動作是必須做的。

首先，識別活動，也就是對自己的開發工作中的各個活動有一個標識，最好加上自己的描述，這樣會為我們的工作做個記錄，以免我們遺忘或者漏掉該做的工作。

其次，在識別活動後我們要對活動的工作量進行評估，也就是預測該活動需要的實際工作時間，可以參考類的個數、資料庫表的個數、介面的個數來估計（這可能是經驗的積累，對我們以後做真正的專案管理有很大協助）。在這個階段做詳細的記錄是必須的，因為這裡的記錄代表了你現階段的專案計劃能力。

最後，在工作完成後，用實際的工作時間與預期的估計做個對比，以次來提高自己的估計能力，相信在以後會有很大的作用。其實在這個計劃與跟蹤過程中，還有一點不要忘記就是要做好自己的時間管理，最好記錄下每天你在項目活動中所耗去的時間，不要太細，但是可以在一周結束後得到自己一周40個工作時中有多少有效項目時間（可能我們的基數不是40：））。這樣也有助於我們以後估算項目時間。

l         需求確認

我們開發中的需求可能因自己職位的不同而來源不同，可能直接來自客戶，也可能來自

業務分析員或者系統分析員。但不管來自哪兒，我們都應該做一個需求確認的動作，我覺得幾個重要的檢查點：

首先，看現在我們所得到的資訊是否對我們的設計、編碼工作已經足夠。

其次，需求的優先順序應該清楚的給出。

另外，需求不明確的時候一定要搞清楚再去開發，以免返工（雖然有的時候即使明確了也得返工，因為需求的變化：（）。

l         設計

如果我們是程式員，而且是流程特別規範的公司的程式員的話，我們可能接觸不到設計，

我們的需求文檔可能是詳細的不能再詳細的詳細設計了（象在說繞口令），這種情況我們的發揮餘地可能不多，但是如果你接手到的設計文檔是很泛泛的，那麼就應該在設計上多下點工夫了。我個人覺得對於我們開發人員，這裡的設計可能重重之中是用例的細化，詳細的狀態圖、活動圖表以及代碼級的結構設計，比如組件設計、重構、抽象。這些估計大家都是高手。

l         測試

不知道大家開發的時候公司的績效考核有沒有千行BUG率的指標，我們有！所以提交

QA測試的話不可能不去做測試，可能我們習慣做的測試是單元測試，但是就我個人而言，做單元測試也是隨性的，不可能有測試計劃、不可能有測試記錄、更不會有測試分析。但是現在這一切在個體軟體工程中都成了必須的：）有四點我覺得應該有改進的餘地：

1.         做好測試案例，尤其是迴歸測試的測試案例。

2.         代碼靜態走查（我也嘗試的去找C#的靜態程式碼分析工具，但是未果，倒是有JAVA的，鬱悶！）

3.         代碼動態測試（檢查我們程式的動態問題，比如記憶體流失、數組越界等，但是我沒用過工具，學習中）

另外在個體軟體工程中，測試還有一項是Peer Review，雖然我覺得這麼做確實有用，

但是，實際執行起來困難重重啊：）大家可以嘗試一下。

 

 

       其實說了這麼多，我個人認為專案計劃與跟蹤和測試的學習使我收穫最大。