軟體的涅磐 讀後評論

2021-03-31 08:56:28 字數 3158 閱讀 1841

「構件」是乙個有別於「物件」的,不同層次的封裝,復用的級別也有不同。不同構件的粒度也和不同的行業,企業的需求的不同,有者直接的關係。「構件」其實是「原子」(高度封裝的原子結構)的概念,不同物質,他們的原子結構不同,但是他們是組成任何物質的「單元」,當然,物質的組成也需要環境,也就是我們需要乙個容器,乙個基於「原子」單元的搭建平台,我們將我們所需要的「原子」,在這個平台,或者叫容器中,按照規範,搭建起來。而這種平台需要擁有乙個,構件的開發環境,構件的整合,管理,部署,資料匯流排xml .以及資料資訊的通訊eai 

csdn 網友

( 2004-06-18)

所有的行業,企業的erp都可以在這個基於構件技術的平台上,搭建出來

darzui

( 2004-06-17)

軟體的構件化,無疑是從建築工程和機械製造中學習來的一種製造產品的方式。建築和機械之的構件化,是基於低技術含量且穩定的大量基礎構件之上的,比如螺栓,比如水泥板,只要採取合格的原料,就必然能夠產生合格的構件,然後要做的,就是怎樣將這些構件合理地組裝起來了。然而對於軟體來說,即便是最基礎的構件,也是由coding生成的,其中滲透了太多人的智慧型,既然有人腦的參與,就必然會產生不確定性,因此,構件的合格性就不能得到完全的保證。

我覺得這些是軟體構件話的大難點,構件化肯定是未來的趨勢,但是具體如何實現,還需要很長時間的摸索和實驗。

csdn 網友

( 2004-06-16)

其實企業應用軟體開發已經有了能將開發效率提高乙個量級以上的軟體工具平台,只要乙個小時左右的時間,它就能完整地加工成乙個進銷存系統,或者乙個oa系統,或者乙個crm系統。所有的開發工作只需要像畫uml圖一樣進行模型定義,由軟體工具全自動地加工出最終軟體成品!不信?訪問http://.k***soft.***就知道這是不是真的。它依據的不僅是構件技術,而是基於模型驅動的自動編碼技術。

csdn 網友

( 2004-06-15)

我聽過普元的培訓,但依然認為現在說構件化就是銀彈為時過早,在普元的試驗環境下,我搭建helloworld程式足足花費2小時,從入門來看,實在看不出構件的好處,從表示層來說,我找不到任何證據,證明用視覺化邏輯代替**邏輯可以帶來效率的提高。但我相信,無論是寫**還是使用視覺化建模,那些有經驗的人,必然可以達到高效率。所以從這點來說,如果使用者熟悉了普元的環境,還是可以有所作為的,如果我們寫**的人員一樣。

沒有銀彈,依然是我的觀點,構件化目前不是銀彈,也是我的觀點。cbd 與mda雖然很熱,卻依然無法徒然提高生產率,這是肯定的。如果我的觀點錯誤,那麼將有大批程式設計師面另下崗的危機了。

csdn 網友

( 2004-06-18)

「構件」是乙個有別於「物件」的,不同層次的封裝,復用的級別也有不同。不同構件的粒度也和不同的行業,企業的需求的不同,有者直接的關係。「構件」其實是「原子」(高度封裝的原子結構)的概念,不同物質,他們的原子結構不同,但是他們是組成任何物質的「單元」,當然,物質的組成也需要環境,也就是我們需要乙個容器,乙個基於「原子」單元的搭建平台,我們將我們所需要的「原子」,在這個平台,或者叫容器中,按照規範,搭建起來。而這種平台需要擁有乙個,構件的開發環境,構件的整合,管理,部署,資料匯流排xml .以及資料資訊的通訊eai

csdn 網友

( 2004-06-17)

它無不預示著軟體產業機制的轉型。要始終懂的如何去把握自己的方向,千萬別隨著老闆走!應該找的 「專業點」一直堅持下去!

csdn 網友

( 2004-06-17)

「相信演化論吧,最終,舊的一切會被拋棄,取而代之的將會是嶄新的面向構件的軟體結構。」

構件也需要人去編寫呀。就好像網路不能生產糧食一樣,糧食還是要人去生產的。

csdn 網友

( 2004-06-16)

其實企業應用軟體開發已經有了能將開發效率提高乙個量級以上的軟體工具平台,只要乙個小時左右的時間,它就能完整地加工成乙個進銷存系統,或者乙個oa系統,或者乙個crm系統。所有的開發工作只需要像畫uml圖一樣進行模型定義,由軟體工具全自動地加工出最終軟體成品!不信?訪問http://.k***soft.***就知道這是不是真的。它依據的不僅是構件技術,而是基於模型驅動的自動編碼技術。

csdn 網友

( 2004-06-15)

我聽過普元的培訓,但依然認為現在說構件化就是銀彈為時過早,在普元的試驗環境下,我搭建helloworld程式足足花費2小時,從入門來看,實在看不出構件的好處,從表示層來說,我找不到任何證據,證明用視覺化邏輯代替**邏輯可以帶來效率的提高。但我相信,無論是寫**還是使用視覺化建模,那些有經驗的人,必然可以達到高效率。所以從這點來說,如果使用者熟悉了普元的環境,還是可以有所作為的,如果我們寫**的人員一樣。

沒有銀彈,依然是我的觀點,構件化目前不是銀彈,也是我的觀點。cbd 與mda雖然很熱,卻依然無法徒然提高生產率,這是肯定的。如果我的觀點錯誤,那麼將有大批程式設計師面另下崗的危機了。 

csdn 網友

( 2004-06-16)

構件不是**式的?構建「美」,**不「美」?這話說的有失水準吧,我邏輯學的不好...

csdn 網友

( 2004-06-15)

我聽過普元的培訓,但依然認為現在說構件化就是銀彈為時過早,在普元的試驗環境下,我搭建helloworld程式足足花費2小時,從入門來看,實在看不出構件的好處,從表示層來說,我找不到任何證據,證明用視覺化邏輯代替**邏輯可以帶來效率的提高。但我相信,無論是寫**還是使用視覺化建模,那些有經驗的人,必然可以達到高效率。所以從這點來說,如果使用者熟悉了普元的環境,還是可以有所作為的,如果我們寫**的人員一樣。

沒有銀彈,依然是我的觀點,構件化目前不是銀彈,也是我的觀點。cbd 與mda雖然很熱,卻依然無法徒然提高生產率,這是肯定的。如果我的觀點錯誤,那麼將有大批程式設計師面另下崗的危機了。 

csdn 網友

( 2004-06-15)

黃柳青是上海普元(http://.primeton.***)的cto,寫這種文章不怪了,大家看過就算了

csdn 網友

( 2004-06-14)

我覺得這是普元的搶手寫的

csdn 網友

( 2004-06-11)

其實企業應用軟體開發已經有了能將開發效率提高乙個量級以上的軟體工具平台,只要乙個小時左右的時間,它就能完整地加工成乙個進銷存系統,或者乙個oa系統,或者乙個crm系統。所有的開發工作只需要像畫uml圖一樣進行模型定義,由軟體工具全自動地加工出最終軟體成品!不信?訪問http://.k***soft.***就知道這是不是真的。它依據的不僅是構件技術,而是基於模型驅動的自動編碼技術。

關於軟體平台的選擇有人的評論

如果僅在windows下,追求程式小巧,用wtl,不足的地方自己實現去吧,但是視覺效果就呵呵了。如果可以大一點,還要好看點,那就qt。如果完全不在乎大小,只要視覺效果華麗,就用wpf,如果把開發工具 也考慮進來,那麼土豪才會選wpf呢。mfc就是個雞肋了,除非你現有的工程師不會用別的,或者有歷史遺留...

外刊IT評論 軟體程式設計21法則

任何乙個有經驗的程式設計師都知道,軟體開發遵循著一些不成文的法則。然而,如果你不遵循這些法則也並不意味著會受到懲罰 相反,有時你還會獲得意外的好處。下面的就是軟體程式設計中的21條法則 任何程式一旦部署即顯陳舊。修改需求規範來適應程式比反過來做更容易。乙個程式如果很有用,那它注定要被改掉。乙個程式如...

軟體工程讀後問題

1.知道熟悉整個軟體開發的流程。2.開始從一些簡單的專案向更加複雜,更加接近社會上真實情況過度。3.乙個高階軟體開發人員具備的能力,怎麼成長成那樣 4.兩人合作開發要做些什麼,如何提高開發效率 5.認識團隊 6.敏捷開發,msf 實戰中的軟體工程 在軟體開發的過程中如何做得更好,效率更高 7.處理軟...