現在有很多的公司, 產品的價值提升都是依持續開發新功能累積產品價值的方式,進行軟體增值!
首先這種途徑是必須的,但是是否會出現以下幾點問題!
第一:貴公司的產品在持續的累積開發中,代碼能否經得起重構的考驗?能否經得起需求變更的考驗!
第二:新員工能否理解老員工的作品,需要多長時間?核心技術是不是掌握在個別程式員手中
第三:公司開發新產品時,能否從現有產品中拿出已有模組,在現有模組的基礎上,進行快速開發!
第四:公司的現有價值是不是只表現在某個產品的原始碼上?而且只表現在原始碼上!(我是說文檔,代碼,分析,設計等等產生的現有勞動成
果!)
第五:代碼是不是越來越臃腫,但是卻沒有信心進行重新開發?
出現這些問題主要的原因在於原始碼的管理上,雖然現在大多公司已經注意到版本控制的重要性,但是卻沒有注意到項目"分模組管理"的重要性!
也許說到這裡很多人已經豁然開朗,軟體是一個很複雜的東西,引用<人月神話>中的一個比較形象的比例,原始碼就像淤泥,
而每個程式員都是大象.大象在創造淤泥的同時,如果不管理好淤泥最後會被自己所造的淤泥所淹沒.在自己創造的淤泥中掙紮的滋味...我想每個做程式員的肯定都體會過! 軟體產品需要各個模組錯綜複雜的交織在一起,相互依賴,缺一不可!但是交織在一起就提高了程式的複雜性,現在又很多的架構就是為了降低程式的複雜性而設計的,其中不得不提的是spring這個架構,spring的價值不在簡單的是原始碼,更多的是設計模式的實現!(我不是為spring打廣告,如果貴公司還沒認識到spring的好處,......)
這篇文章不是為了探討設計模式,主要是探討如何有效管理原始碼,管理所有程式員所創造的"淤泥"
在這裡我要推薦的就是磚廠的生產模式,磚廠就是把淤泥做成產品的最好的案例!而且做的比較成功!
磚廠在處理到淤泥的時候首先要"制坯"然後"火燒",最後"堆砌"(我們老家話叫"插坯")
借用磚廠生產流程的專業術語依次講解,這些流程如何映射到我們的軟體開發流程中,以及一些應該注意的地方(我個人的看法)
第一步:創造淤泥
一步我們每個程式員都會,就是寫代碼!值得我們程式員驕傲的是!在這一步的時候我們能夠體驗到只有上帝才能擁有的快樂!
我們可以創造一切,這是傳統的行業所無法比擬的!我慶幸我體驗過做上帝的感覺.最初吸引我進入這一行的也是這種感覺!
可是上帝也有苦惱的時候也許上帝就是管理不了他所創造的最進階的東西-----人類,而放棄了我們,所以導致我們現在還見不到上帝!
第二部:制坯,
這一步也有很多的程式員都在做,每個程式員都有自己收集的一套"磚頭瓦片"比如"spring,hanbnate.....",把他們放到自己電腦的某個檔案夾下如數家珍! 但是到了公司就變成:有的程式員在拿這些"磚頭瓦片"磊房子,有的程式員在造"淤泥",有的程式員"大工,小工一起做",即造淤泥又磊房子!但是往往為了偷懶省事,他也不"制胚",就拿淤泥當磚頭用!這樣造出的房子能牢固嗎?最大的問題是程式員不能認識到"淤泥"與"磚頭"之間的差別兩者混用!我們應該清楚的定義出"淤泥"與"磚胚"(注意是"磚胚"不是"磚頭")之間的差別!
"淤泥":是程式員根據功能需求隨手寫出來的代碼,隨意性很高,有的人說我們的項目只要磚頭不要淤泥,但是沒有淤泥你能把"磚頭"粘到一
起嗎?
"轉胚":是在程式員有意識的要讓他所創造出來的"淤泥"有一定的形狀,並且有一定的特效能完成某項功能,比如說:"我造過一塊"磚頭"可以驗證使用者所有的輸入類型是否合法,我用JavaScript造過這個功能的磚,用C#也造過同樣功能的磚"只是他們材質不同!
專業的說,"磚胚",是能夠實現某單獨功能的代碼的集合!
當然你造"空心磚"也好,造"黃泥磚"也好,還是造一個"巨大的基石"也好,都在你自己的選擇
第三步:火燒
這一步也有部分程式員在做,"轉胚"不燒不結實不能用啊!所以要"火燒",如何火燒呢?
測試唄;不知道哪吒的三味真火是那三味,這方面我不精通,希望會三味真火的兄弟教教我!怎麼搞個三味真火好好的燒燒這塊磚!
注意:這裡的磚塊大小是有約定的,這個磚塊是要在能夠完成某項功能的基礎上,如果這塊磚依賴於其他的磚塊那麼這塊磚並非不是好磚,而是在使用的時候不太順手!所以磚塊與磚塊之間盡量相互隔離才好!
注意:這裡要說明的是,這塊磚燒好了沒錯,最重要的一部就是要寫好說明文檔,這塊磚怎麼用,搞兩個最常用的樣本!那麼你的這個磚就算燒到家了!如果沒有document,沒有example!那麼你這塊磚誰能看懂是幹嘛的!
我來講講這裡面的好處... 有了document 那麼無論是作者自己還是後來的新手,都能夠快速的理解這塊磚的作用! example就更不用說了!
長此以往下去公司的價值得以延續和增值!每個人的勞動成果得以無限放大!作為公司管理者的你應該能夠看清楚其中的利害關係!
第四步:堆砌
站在一個公司的角度出發,公司的競爭力累加也就是這些"磚頭瓦塊"的累加
這一步就是把燒好的磚嘜(ma)起來,俺們山東話叫垛起來!
當一個公司的磚塊過多的時候也會形成另外一種層次的淤泥,所以在這個層次的有效管理也是很必要的! 很多公司都沒有這一步,有的也只是簡單的把他們分開放到了某個檔案夾下!怎樣才是最有效管理方式呢!我們不妨看看jquery中文社區是如何有效區分那240個jquery外掛程式,以及Apache官方網站是如何顯示他們的勞動成果的!還有http://www.codeproject.com/是如何管理那麼多磚頭瓦塊的!
我們不得不承認國外的軟體品質較高!但是我們在佩服的同時應該看到他們是如何達到這種效果的!
我發現:並不是中國人比外國人差,相反我倒覺得外國人不如中國人聰明和勤勞,但是為什麼就不如外國人做的軟體好呢?
我的觀點是:從公司層級來看缺乏有效管理,具體哪些管理呢!
我認為有以下幾點:
第一個最主要的管理就是: 項目進度管理(我要說一下我的觀點,做項目進度管理的這個人絕對不能寫代碼,否則容易影響進度管理人的全域把握思維!)
第二個最主要的管理就是: 項目品質管理(測試不收口,甚至沒有測試.最好的產品不會讓使用者去做測試,當然你可以搞個測試版!免費用用)
第三個最主要的原因就是: 能夠承擔軟體構架總體設計的人才在中國太少,(但是最近看一個設計模式的書的時候提出,好的設計模式是重構出來的,這一點目前保持支援態度,但是並不意味著這種總體構架師就可以不要了!)
第四個最主要的管理就是: 我這個文章所提倡的公司已有產品的,價值的,有效管理!