1. 程式人生 > >關於專案開發中的一些問題

關於專案開發中的一些問題

 1  軟體工程就意味著無休止的會議嗎?怎麼樣才能更好的將任務佈置給每一個人,保證進度,並且在其遇到難題的時候能夠更好的溝通呢? 
    2  在開發中間[我說的是WEB開發],頁面顯示的修改在總的工作量上所站的比例是多少呢? 
    3  程式程式碼的註釋要詳細到什麼程度呢? 
    4  作為開發小組的負責人,你與你的成員如何溝通呢? 
    5  任務的完成情況是如何檢查的呢?做到什麼程度才算任務完成了呢? 
鄙人初入WEB開發的門牆,但是感覺還沒有摸著門道,以上問題均是有感而發,希請諸君不吝賜教!! 



1 軟體工程就意味著無休止的會議嗎?怎麼樣才能更好的將任務佈置給每一個人,保證進度,並且在其遇到難題的時候能夠更好的溝通呢? 


答: 
>> 軟體工程不意味著無休止的會議,但會議還是要開的,假如你是Leader 的話,分配任任務時,整個系統的功能應該在以前的會議上分析了,此時,你只要單獨跟任務相關人員做一個說明,確定一些細節就行了。 當然,如果你有詳細的文件、原型圖等等,你不必跟相關人員面談。我的經驗是一般情況下面談比較現實.遇到困難的時候,當然是找Leader了,如果做為Leader的你感覺這種方式讓你很痛苦,那就表示你做了許多不該做的工作。你不應該做太細節的工作。有充分的時間幫助團隊分析並解決(可能是分配給其他人員實施)問題。  

2  在開發中間[我說的是WEB開發],頁面顯示的修改在總的工作量上所站的比例是多少呢


答: 
>> 在Web開發過程中,排除之前的分析和設計時間,頁面的開發佔80%, 這期間: 新面頁佔頁面開發時間的60%,修改佔40%,當然,這是我的經驗,只是個例. 

3 程序程式碼的註釋要詳細到什麼程度呢? 

答: 
>> 這個問題很難回答,正如樓上所說的,詳細到別人能基本通過註釋的幫助,很容易看懂你程式碼的意圖。程式碼寫的越好,註釋就可以越少。 我個人認為,不必要太詳細,在一個頁面上描寫了本頁面的基本功能和大概的實現演算法,每個方法做個簡單的描述。一段複雜的程式碼做一些演算法描述. 
請樓主注意程式碼的註釋描述方式!同樣的註釋,有些一看就明白,有些看了也不明白。舉個簡單的例子: 

假如有一個值班模組,要獲取一個值班日誌對像,進行接班。在程式碼裡可能有:  
   

if(OnDutyLog==null)  
       
return
有些人會註釋:   檢查空值 
但有些人會註釋: 無法取到值班日誌,不能接班 

兩種註釋都描寫了程式碼的操作,第一種更普通的泛泛描述。只是說了程式碼要做的。 但第二種則直接說出了他要做的和為什麼要這樣做。 一句話:通過第二種註釋,其他開發人員一眼就知道這兩行程式碼的做用,並且知道作者為什麼要這樣寫! 

4 作為開發小組的負責人,你與你的成員如何溝通呢? 

答: 
>> 如果是專案的溝通,則通過集體開會和單獨交流(面談) 

5 任務的完成情況是如何檢查的呢?做到什麼程度才算任務完成了呢? 

答: 
>>首先檢查做出來的模組是不是實現你分配給他的任務,對於Web開發舉個例子: 首先看需要的頁面是否都有,所以功能操作是否可以如預期的一樣順利執行。如果可以,就算基本完成。然後再看有沒有發現明顯的bug,如果沒有,就算完成了。如果你的團隊很大,這些應該是給測試人員做,反之,則是Leader做了。Leader驗收完畢(順便瀏覽一下此功能的程式碼) 然後就可以認為是完成了,再交給測試人員測試。  

        另外:樓主可以採用 bug管理軟體來記錄變更、分配置任務。 其實在開發初期分配任務、協調都不會出太多問題。問題主要分出現在迭代過程中: 你的專案收到的反饋或測試報告回來後,需要開發人員處理,在處理的同時,可能又有新的反饋,這些反饋可能涉及上一次反饋的問題,可能是正在根據客房要求進行修改的問題。 反饋也有可能是使用者自己推翻了自己的觀點,改變了需求。等等。 這些問題才讓人頭大。所以專案的泥潭往往在後期。 採用bug管理軟體可以解決絕大部分問題。 

以上是個人經驗和看法。