emu in blogjava

            BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
            171 隨筆 :: 103 文章 :: 1052 評論 :: 2 Trackbacks

          關于面向構件和EOS的一些思考
          author:emu(黃希彤)
          二、軟件開發和傳統行業應該怎么對比

           

                  普元很喜歡把軟件開發同傳統產業進行類比,在接口問題上,我們也來看看傳統的機械產業有沒有類似的概念吧。螺絲和螺帽是我們最常見的兩種構件,也是大規模工業化生產機械裝置的基礎,那么螺絲和螺帽的接口是不是寬松和自適應的呢?不是!他們是強耦合的接口,而且我們有上百萬中不同規格的螺紋規格,或者說接口,每一種都定義的非常精確和有針對性。我們還有不計其數的齒輪的規格,有多少個齒輪可以用其他型號的代替呢?很少。當然機械裝置中也有弱耦合,比如膠水、塑料、樹脂。但是有沒有利用弱耦合的結構來大規模生產機械裝置的呢?我一時間想不出這樣的例子。

           

                  類比得出的結論是,如果我們要學習傳統的機械產業,我們應該定制上百萬種嚴格的強耦合接口標準,然后大量的廠商按照標準生產上百萬種構件??雌饋砗孟駱嫾r代離我們還有點遙遠哦。不過也未必,類比得出的另一個結果是,用EOS這樣松耦合的構件來構造軟件,就象用萬能膠水粘到一起的一組齒輪、軸承和螺絲螺帽來做變速箱。

           

                我們不要理所當然的認為這樣的變速箱沒有用,這正是軟件和機械的不同。這樣一個變速箱只要設計合理、能夠承載所需要的負荷,他是真的能夠一直工作下去的,我們不需要面對金屬疲勞、膠水老化和磨損這樣的問題。也許這正是面向構件開發的實質吧:能用膠水粘到一起的東西,就不要用螺絲。

           

                  是的,我的類比存在問題。再寫上面這些文字的時候我腦子里面反復想起Jack Reecves的名言:源碼就是設計,而軟件的生產過程僅僅是廉價得幾乎免費的構建過程。不錯,我們可以機械化、自動化的生產大批的汽車、冰箱,可是我們還可以更容易的構建軟件的拷貝。我們在抱怨軟件的生產不能象汽車那樣一臺接一臺的出廠,可是汽車廠又何嘗能夠一臺接一臺的批量設計汽車呢?

              昨晚碼字之前喝了點紅酒,思路好像不是太清晰,有點自相矛盾的傾向…author:emu(黃希彤)

          posted on 2005-06-21 09:04 emu 閱讀(1397) 評論(8)  編輯  收藏

          評論

          # re: 關于面向構件和EOS的一些思考-軟件開發和傳統行業應該怎么對比 2005-06-21 10:29 大胃
          早期的軟件的確是強耦合的,至少我從我學機械的父親那里得到的印象是:那個時候做軟件多少都有點機械工程的味道,我不知道這個感受是我的意象還是確實如此。

          不過畢竟硬件/固件是固定的,具體的,綁在一起的實體;而軟件則是流動的,不斷變化甚至自我演化的流體。這個nature決定了軟件可以有朝一日比硬件更容易擺脫接口(廣義)的束縛,也更加容易升級。

          另一方面,固件的日常維護是為了保持它的正常運轉,需要的是讓它完成既定的任務,或者更好的完成那些規定好的具體的事情,這些需求和它出廠時并無區別;軟件則不同,我們經常需要根據新的需求來改變,通常是增加新的功能,所以維護軟件需要有不同的approach。正是對軟件這樣的要求才出現了越來越多的低耦合的解決方案、設計模式和框架。

          我父親的時代也許傾向于用傳統的機械制造的思維來思考軟件的工藝流程和軟件的本質,但是我發現這樣的思路越來越行不通了。

          // 昨天沒睡好,也胡亂說一通......  回復  更多評論
            

          # re: 關于面向構件和EOS的一些思考-軟件開發和傳統行業應該怎么對比 2005-06-21 12:26 emu
          固件?這個詞在升級數碼相機和mp3的時候用過,好像還是軟件來的哦。

          “用傳統的機械制造的思維來思考軟件的工藝流程和軟件的本質”行不通嗎?我覺得我們現在正是在軟件開發過程栽進死胡同里面了,所以正需要從傳統的機械、制造和建筑等行業學習人家的思維呢。我可以想像足夠高的層次上,他們是相通的。  回復  更多評論
            

          # re: 關于面向構件和EOS的一些思考-軟件開發和傳統行業應該怎么對比 2005-06-22 11:56 小陸
          軟件的開發和傳統的工業開發有很多不同之處. 軟件開發是一種純腦力勞動, 產品是一種無形的東西. 開發的過程是一個持續設計的過程, 從調查, 設計, 測試, 編碼, 到部署和后期維護, 是需要持續設計的. 軟件的開發過程中, 需求變化的程度要大于傳統的產品, 并且軟件構架的靈活程度也比較高, 一個系統的最初構架是可以發生漸變甚至突變的.
          方法論也許很重要, 但是從根本上解決問題要提高人的素質, 調動人的積極性. 人本身對于軟件開發的影響大大高于其他行業.   回復  更多評論
            

          # re: 關于面向構件和EOS的一些思考-軟件開發和傳統行業應該怎么對比 2005-06-22 12:21 emu
          我認為相反,方法論比“提高人的素質, 調動人的積極性”要重要。在傳統產業中是如此(比如零件標準化、生產流水線),在軟件開發中也應該如此。我們遇到的困境就在于我們現在在軟件開發中暫時還做不到、做不好。
          確實,現在人本身對于軟件開發的影響大大高于其他行業。這大概正是我們應該改變的現狀。
            回復  更多評論
            

          # re: 關于面向構件和EOS的一些思考-軟件開發和傳統行業應該怎么對比 2005-06-22 13:59 小陸
          軟件生產的特殊性是無法擺脫的, 最大的特點在于需求的變化. 需求變化造成了軟件的生產是一種持續設計的過程.

          10年前工廠生產自行車, 把裝好的自行車直接推進商場去買, 今天有專門的自行車店, 可以根據個性化的需要定制一輛自行車, 顧客可以試, 試過了還可以換, 這就是社會的進步. 盡管生產出來的自行車看起來沒有什么變化, 但是客戶的滿意程度增加了, 同樣也是增加了社會的財富. 對于這樣的自行車店來說, 一個僅僅會在柜臺里收錢的店員是沒有用的, 需要的是具有多種專業素質的人.

          軟件的生產類似與自行車店里的工作, 不會直接的創造價值, 但是會提高顧客對解決方案的滿意程度. 并且比傳統的工業更加靈活, 更加適應需求的變化.

          適用于流水線上的方法論基于一種基礎: 人力和人力是可以互相代替的, 人力和時間是可以互相代替的. 在軟件生產領域這個基礎是不存在的. 建一棟大樓的時候我們可以認為, 加50個工人, 就可以提前一個月完工. 用這樣的思想開發軟件則行不通, 這樣的方法論不適用于軟件開發.

          人本身對于軟件開發的影響大大高于其他行業, 這個現狀是很難改變的. 承認這個狀況才能找出適用于軟件開發的某種"方法論", 在這樣的方法論中, 人應該在一個更加重要的地位.   回復  更多評論
            

          # re: 小陸 2005-06-22 15:07 emu
          好一個“需求變化造成了軟件的生產是一種持續設計的過程”,和Jack Reecves的名言“源碼就是設計,而軟件的生產過程僅僅是廉價得幾乎免費的構建過程”是一個意思。這恰恰就是我們難以和傳統行業做重復相似的類比的根本原因。

          軟件開發至少在現在,和自行車店是完全沒有辦法類比的,也許在充分構件化開發的明天我們可以。

          我認為流水線上的方法論并不基于你所說的基礎,即使是什么經濟學家說的,我也照樣不同意。

          我認為流水線的要點是把復雜的工作分解成很多小任務,每個(每組)人負責完成其中的一個或幾個小任務。流水線之所以能夠提高生產效率,是因為人在重復完成一個小任務的效率比完成整個大任務的時候生產效率要高,因為重復的小任務會變得熟練。

          在軟件開發過程我們沒有借鑒過這樣的方法論嗎?我們不是幾組人分工,需求分析、設計、編碼、測試,象流水線一樣在工作嗎?我還把軟件分成數據訪問層、事務層、表現層來開發,這不是對流水線的模擬嗎?我們沒有因為這樣的分解而增加了開發熟練程度和效率嗎?

          而且,軟件開發中人力和人力也往往不是不可替代的(安德爾斯可能是個例外),我們都遇到過這樣的情況不是嗎?當然替換過程有個成本問題,傳統產業一樣也有。在這方面,我們的問題是能不能降低替換的成本,比如嚴格的XP開發流程中,這個問題就得到很好的解答。  回復  更多評論
            

          # re: 關于面向構件和EOS的一些思考-軟件開發和傳統行業應該怎么對比 2005-08-11 09:32 shuquan
          普元是好事,但是還不是非常好:
          基于jboss/eclipse兩個免費的平臺,整合出了一個東西來賣錢,讓人感覺有點點不妥。
          而且目標過于遠大,不可能有銀彈的。如果能提出一套控件的標準,ide以插件的形式分發,而不是把ide作為排他的東西(直接把jb/bea/idea等作為對手).
          應該有更大空間。(但是那樣的話,普元如何掙大錢?好像可以賣標準哦)
          由于該方向涉及東西太多,估計普元不可能都解決得了。因此,相信很多軟件公司會分析、吸取普元的思想,自己搞得。  回復  更多評論
            

          # re: 關于面向構件和EOS的一些思考-軟件開發和傳統行業應該怎么對比 2005-08-11 11:36 emu
          不只jboss和eclipse是免費的,java也是免費的,但是我們都還在靠java混飯吃呢,這倒沒什么不妥。

          從來沒有人證明過不可能有銀彈,這也不是問題。目標過于遠大?這更不成其為問題了。

          剩下的問題我認為才是真正的問題。普元再強,你能強得過微軟去?windows上面的軟件大半不是微軟出品的,用java開發的軟件也大半不是sun出品的,可是普元上面的構件卻基本上是普元出品的。雖然我們自己也可以開發構建,但是這不是一個開放的標準,我們如果這樣做了自己的利益得不到保障,誰會去這樣做呢?所以普元這個封閉的標準造成了他只能閉門造車,想幫他忙豐富他的構件庫的人都無從下手。普元開發能力再強能開發出來多少種構件呢?

          我覺得普元想做大,唯一的出路就是吧開發和應用環境都免費開放,最好干脆開源,并免費開放目前的大多數可以通用化的構件,在他的主導下創建并維護一個社群,讓每個人都可以用EOS獲取自己的利益,然后他可以以定制構件和生產出售在EOS平臺上的軟件來盈利。

          如果他不這樣做,我相信他的競爭對手遲早也會這么做。事實上,如果我是個沒有生存壓力的自由程序員,我現在也許已經在這么做了。

          在他轉向開放之前,我沒有辦法再看好他。  回復  更多評論
            


          只有注冊用戶登錄后才能發表評論。


          網站導航:
           
          主站蜘蛛池模板: 鹤岗市| 浦东新区| 泰宁县| 前郭尔| 板桥市| 航空| 丰顺县| 兰西县| 玛纳斯县| 汉源县| 舒城县| 沐川县| 额尔古纳市| 海城市| 山东省| 象州县| 剑川县| 霍城县| 治县。| 江永县| 毕节市| 兴安县| 舒城县| 鸡东县| 霍州市| 宣武区| 灵山县| 通许县| 邹城市| 铜陵市| 闻喜县| 乐业县| 海宁市| 普洱| 利津县| 岚皋县| 水城县| 西和县| 铜山县| 临邑县| 平利县|