星期天來加班,腦子裡一絲反抗boss的牴觸情緒蔓延開來.因為明天又要有新的專案咯.又要忙起來了.所以決定今天將我對分層的理解寫完..
ok..閒話少說.切入正題..
前兩篇說了,在專案開發過程中如果做前期的規劃,可以說,如果做好了前期的開發工作,肯定會帶動後期開發的效率以及減少維護期間的工作量..今天總結一下專案開發中分層的關係..
首先:在的專案開發過程中,使用介面來管理和約束你的專案(對於使用介面的概念和優點可以參考我的另一篇我對介面和類的總結
)..避免功能模組的重複開發和命名的不統一..
其次:合理的分配文件..例如,8月1日專案啟動,專案經理下放文件..8月5日,專案有新的需求變動..專案經理修改下放文件..8月7日,專案再次變動..ok..繼續修改下放文件..然而客戶的突然取消此次變動,要求按照8月5日的需求變動..這個時候問題就出來了,因為程式設計師是根據下放的文件進行開發..你每變動一次,**可能就要修改..對於此次的取消,你可能需要將8月5日的文件需求內容再次開發..對於這樣的情況..如果頻繁的發生..對於專案的進度和管理會造成極大的麻煩..
我的解決辦法:1.專案需求變動,不要修改下放文件..應該發放需求變更文件..並且保留下放文件..並且將此次變更前的**存擋..這樣的好處,其一:專案進度透明.對於乙個頻繁更改需求的專案來說,很難按照預期的時間開發完成(唯一的解決辦法就是加班^_^)..將每次的需求變動按照任務單的形式下放..便於boss對專案強度的了解(這個可是公升職加薪的關鍵哦)..其二:解決了上面所說的**重複開發問題..如果客戶要求還原至前期的需求..ok..調出前期存單的功能需求替換就搞定..其三:即便是你存檔的功能**此次變更沒有用.但是難保以後不會用在其他客戶的需求中用的到呢??
對於三篇文章,我做了以下的總結:
1.優化功能,對於功能結構要合理規劃.
2.合理編寫**,新增注釋..使你的**易於維護..每個類都要有詳細的注釋.如果有必要,就新增對類操作的例子
3.合理高效的使用介面來規範程式..給類新增規則..使專案易於管理..
4.建立專案文件管理制度..使專案透明化.
5.對於**盡量增大復用性.並歸檔整理..加快以後專案開發速度..
寫到這裡..看了看前面兩篇文章,才發現有點跑題了.呵呵..本來是想講分層的經驗..誰知道寫著寫著寫成專案中管理的經驗了..不過好歹不是偏的很厲害...以上內容都是個人在公司專案開發中的體會和感受..希望對大家在開發中有幫助..如果大家有好的專案開發經驗也可以說出來,一起進步..
我對分層的理解 二
昨天發表了我對 分層的理解第一部分.今天發表第二部分.對於文章的定位,一直是圍繞層與層這部分,其中牽涉到方方面面的東西.我盡量在每一篇都集中說明其中的一塊.不牽涉其他內容.今天這部分主要內容將圍繞層次開發的前期規劃上進行總結說明.大家在理解了需求之後,有的朋友可能就會開始急於投入專案,開始劃分層次,...
我對分布式計算框架的理解與設計
在架構上，可以將服務中的伺服器分三個模組 模組含義 config 配置服務 server 對外介面服務 service 工作服務 worker 我想讓service接受請求，server進行計算，流程會是怎麼的呢。一條簡單的請求過來，可能經過的處理過程 實際的處理比這個要複雜，比如請求過期處理等。在...
談談我網路分層協議的理解和問題
我對網路的分層協議的理解 1.每層的提供的服務是固定的，所以每一層改變的時候，不會影響其他層次。比如資料鏈路層是乙太網 令牌環網，他們都能支援ip協議。而應用層的傳輸協議既可以使用tcp協議，也可以使用udp協議。分層也使每一層的功能單一。2.協議是兩個通訊的主體達成一致的通訊規則，windows ...