昨天發表了我對
分層的理解第一部分..今天發表第二部分.對於文章的定位,一直是圍繞層與層這部分,其中牽涉到方方面面的東西.我盡量在每一篇都集中說明其中的一塊..不牽涉其他內容..今天這部分主要內容將圍繞層次開發的前期規劃上進行總結說明.
大家在理解了需求之後,有的朋友可能就會開始急於投入專案,開始劃分層次,接著根據需求分工編寫業務層和資料層.介面交給美工.似乎這樣的開發順序很適合國內這樣的小團隊開發.但是這樣的開發的可能會導致,層次銜接不明朗,後期維護難,給後期維護人員也帶來不方便.後期功能擴充套件也不方便.造成**的大量沉澱.
層次銜接不明朗:國內大多數的中小企業在專案管理上都存在缺陷,就是對於專案的管理化分不合理.例如:a負責業務,b負責資料,c負責美工,而初期專案經理會根據需求和大家談需求..然後告訴你.你要幹這個,你要做那個.然後大家就開始自己的工作.之後如果a遇到資料問題.就會和b商量,可能會有改動.但是這個時候如果有改動而忘記告訴c.則專案銜接有問題..如果c遇到介面表示問題需要和a解決,這個時候b不知道的話.銜接又會出現問題..類似這樣的需求變動,團隊缺乏合作意識的問題想必大家都可能遇到過.
我的建議:建立專職專案負責人制度.由專案負責人統一調配分發需求,即便是在開發階段一樣要提交專案負責人,由負責人解決.並在週期性的開會會議上做需求變更報告..這樣就解決了團隊間推諉扯皮的事情.因為專案有專職負責人,下面的開發人員有任何需求的變動,都要提交給負責人,並由負責人解決.類似古代的君主**集權制..如果公司規模小,沒有能力執行專職專案負責人制,可以考慮由小團隊中的開發人員兼任.但是職責一定要明確..
後期維護難:由於現在國內開發人員流動量大,給國內的專案後期維護帶來了一定的難度.解決這一問題的最好辦法就是在開發階段就要養成良好的程式設計習慣.俗話說的好,前人栽樹後人乘涼.做程式開發就更應該是這樣的.不能抱著反正做完就行了的心理.如果每個人都能在開發的時候多為以後想想,多為維護人員想想,能貫徹真正的前人栽樹後人乘涼的正確思想.那麼寫程式是件開心的事情,維護程式更是件開心的事情.
我的建議:養成良好的程式設計習慣,盡量把你的方法和類中加入詳細的說明吧..這不管是對於自己和以後維護人員都是有百利而無一害的事情..就如有人所說:要判斷乙個的程式設計師的**是否優秀就看他的**吧,例如乙個**文件你完全可以40%是**,60%是注釋..這樣的**我認為是藝術.甚至可以讓其他人員象讀書一樣就理解了你的**..注意:不要因為寫注釋的興奮而真的把瓊瑤,金庸的**真的寫到注釋中哦..那樣的話.嘿嘿..boss很生氣,後果很嚴重!
我對分層的理解 三
星期天來加班,腦子裡一絲反抗boss的牴觸情緒蔓延開來.因為明天又要有新的專案咯.又要忙起來了.所以決定今天將我對分層的理解寫完.ok.閒話少說.切入正題.前兩篇說了,在專案開發過程中如果做前期的規劃,可以說,如果做好了前期的開發工作,肯定會帶動後期開發的效率以及減少維護期間的工作量.今天總結一下專...
我對分布式計算框架的理解與設計
在架構上，可以將服務中的伺服器分三個模組 模組含義 config 配置服務 server 對外介面服務 service 工作服務 worker 我想讓service接受請求，server進行計算，流程會是怎麼的呢。一條簡單的請求過來，可能經過的處理過程 實際的處理比這個要複雜，比如請求過期處理等。在...
談談我網路分層協議的理解和問題
我對網路的分層協議的理解 1.每層的提供的服務是固定的，所以每一層改變的時候，不會影響其他層次。比如資料鏈路層是乙太網 令牌環網，他們都能支援ip協議。而應用層的傳輸協議既可以使用tcp協議，也可以使用udp協議。分層也使每一層的功能單一。2.協議是兩個通訊的主體達成一致的通訊規則，windows ...