編程思想、哲學、道與術

一切的起源:問題及問題的求解:

 

編程是爲了解決問題,而解決問題可以有多種視角和思路;

 

世界觀與方法論:

 馬克思:世界是物質的,物質是運動的;運動着的物質是普遍聯繫和永恆發展的;

 

編程思想與世界觀:

  我們知道,哲學領域中,最根本的對立是唯物主義和唯心主義的對立,而附屬其下,又有許多對立,如形而上學和辯證法的對立、可知論和不可知論的對立等等。這些對立形成了哲學的基本體系、派別和出發點。實際上,這些對立,都是世界觀的對立。世界觀,簡而言之即如何看待這個世界。世界觀是一切哲學問題的本源和出發點。

      同樣,在程序世界裏,也有着不同的世界觀。而這其中最根本的對立便是過程論和對象論的對立,這個對立,衍生出了面向過程和麪向對象兩種方法論。於是,要真正理解面向過程和麪相對象,我們就不得不先深究一下程序世界中這兩種世界觀。

      首先要提到的是,不論是過程論還是對象論,都承認一點,那就是程序世界本質上只有兩種東西——數據和邏輯。數據天性喜靜,構成了程序世界的本體和狀態;邏輯天性好動,作用於數據,推動程序世界的演進和發展。儘管上述觀點是統一的,但是在數據和邏輯的存在形式和演進形式上,過程論和對象論的觀點截然不同。

      過程論認爲:數據和邏輯是分離的、獨立的,各自形成程序世界的一個方面(Aspect)。所謂世界的演變,是在邏輯作用下,數據做改變的一個過程。這種過程有明確的開始、結束、輸入、輸出,每個步驟有着嚴格的因果關係。過程是相對穩定的、明確的和預定義的,小過程組合成大過程,大過程還可以組合成更大的過程。所以,程序世界本質是過程,數據作爲過程處理對象,邏輯作爲過程的形式定義,世界就是各個過程不斷進行的總體。

      對象論認爲:數據和邏輯不是分離的,而是相互依存的。相關的數據和邏輯形成個體,這些個體叫做對象(Object),世界就是由一個個對象組成的。對象具有相對獨立性,對外提供一定的服務。所謂世界的演進,是在某個“初始作用力”作用下,對象間通過相互調用而完成的交互;在沒有初始作用力下,對象保持靜止。這些交互並不是完全預定義的,不一定有嚴格的因果關係,對象間交互是“偶然的”,對象間聯繫是“暫時的”。世界就是由各色對象組成,然後在初始作用力下,對象間的交互完成了世界的演進。

 

 

軟件問題對象的問題:

1)業務邏輯的複雜型;

2)軟件組件的規模;

 

軟件複雜度的升級:一維線性(單純計算);二維平面(帶有業務邏輯的結構型計算);三維立體:描述複雜的現實世界;

 

針對軟件開發任務的升級,編程思想也有一個相應的升級過程:

編程思想的進化;

1)面向計算:計算機出現的驅動力,具有唯一解;

2)面向過程、結構:具有有限解;

3)面向對象:具有無限解;

 

面向過程編程及面向過程的問題:

傳統的面向過程的編程思想總結起來就八個字——自頂向下,逐步細化!實現步驟如下:

  1. 將要實現的功能描述爲一個從開始到結束按部就班的連續的步驟(過程);
  2. 依次逐步完成這些步驟,如果某一步的難度較大,又可以將該步驟再次細化爲若干個子步驟,以此類推,一直到結束得到想要的結果;
  3. 程序的主體是函數,一個函數就是一個封裝起來的模塊,可以實現一定的功能,各個子步驟往往就是通過各個函數來完成的,從而實現代碼的重用和模塊化編程!

 

問題:

      1.軟件重用性差

      重用性是指同一事物不經修改或稍加修改就可多次重複使用的性質。軟件重用性是軟件工程追求的目標之一。

 

      2.軟件可維護性差

      軟件工程強調軟件的可維護性,強調文檔資料的重要性,規定最終的軟件產品應該由完整、一致的配置成分組成。在軟件開發過程中,始終強調軟件的可讀性、可修改性和可測試性是軟件的重要的質量指標。實踐證明,用傳統方法開發出來的軟件,維護時其費用和成本仍然很高,其原因是可修改性差,維護困難,導致可維護性差。

 

      3.開發出的軟件不能滿足用戶需要

      用傳統的結構化方法開發大型軟件系統涉及各種不同領域的知識,在開發需求模糊或需求動態變化的系統時,所開發出的軟件系統往往不能真正滿足用戶的需要。

 

 

所有編程思想共同方法論(與其它的普通問題解決相同);

 

將問題降緯然後重新組裝;

它面對的問題:

1)如何分拆成模塊;

2)如何將這些模塊組裝;

 

物理層面的表現:

文件、類、頭文件。

 

邏輯層面的表現:模塊、接口;

 

抽象、分析與綜合;

採用的相應策略爲:

1)降低開發時面對的對象的規模;

2)降低問題的複雜度;

 

軟件開發的工作是什麼?

 

軟件開發的三次轉化:

1)將需求轉化爲程序模型;

2)將程序模型轉化爲代碼;

3)將代碼轉化爲機器碼;

 

以人爲本:

人是軟件的不同形態轉化的關鍵

 

 

以分解降低複雜度

以分解的方式進行的設計,主要特點是: 

- 分離職責(Seperation of Concerns,參考單一職責原則) :強調功能分離;

- 關注接口(定義交互):強調模塊的組合;

 

◆  面向過程編程

       結構化編程思想的核心:功能分解(自頂向下,逐層細化)。

結構化編程思想主要是將一個大的問題劃分爲幾個小的問題,再將幾個小的問題劃分爲更小的問題,我們解決大問題非常困難,但是解決劃分後的最小的問題卻比較容易。

面向過程編程把編程任務劃分成一個一個的步驟,然後按照步驟分別去執行。其中每完成一個步驟就像是完成一個任務中的單個過程一樣。

 

  面向對象編程思想的核心:應對變化,提高複用。

面向對象編程思想主要是複用性和靈活性(彈性)。複用性是面向對象編程的一個主要機制。靈活性主要是應對變化的特性,因爲客戶的需求是不斷改變的,怎樣適應客戶需求的變化,這是軟件設計靈活性或者說是彈性的問題。

 

 

 

軟件的雙重屬性:

1)工具屬性:軟件的目的是給人使用,要實現功能。

2)工程屬性:有工程就會有質量;

 

軟件開發的通用策略:

http://blog.csdn.net/xiaojianpitt/article/details/1931058

人們在探索軟件工程方法的幾十年裏,提出了許多軟件開發的方法,但這些方法都不是嚴密的理論。我們不應該教條地套用方法,更重要的是學會"選擇合適的方法"和"產生新方法"。

  軟件開發中的三種基本策略:複用、分而治之、優化與折衷。

1.複用 

   對於建立軟件系統而言,所謂複用就是利用某些已開發的、對建立新系統有用的軟件元素來生成新的軟件系統。在一個新系統中,大部分的內容是成熟的,只有小部分內容是創新的。一般地,可以相信成熟的東西總是比較可靠的,而大量成熟的工作可以通過複用來快速實現,人們應該把大部分的時間用在小比例的創新工作上,而把小部分的時間用在大比例的成熟工作中,這樣才能把工作做得既快又好。
  我們將具有一定集成度並可以重複使用的軟件組成單元稱爲軟構件(Software Component),軟件複用就是直接使用已有的軟構件,即可組裝(或加以合理修改)成新的系統,而可以不必每次從零做起。一方面,軟件複用方法合理化並簡化了軟件開發過程,減少了總的開發工作量與維護代價,既降低了軟件的成本又提高了生產率。另一方面,由於軟構件是經過反覆使用驗證的,自身具有較高的質量,因此由軟構件組成的新系統也具有較高的質量。

2.分而治之

 分而治之是指把大而複雜的問題分解成若干個簡單的小問題,然後逐個解決。這種樸素的思想來源於人們生活與工作的經驗,也完全適合於技術領域。諸如軟件的體系結構設計、模塊化設計都是分而治之的具體表現。 

3.優化與折衷

軟件的優化是指優化軟件的各個質量因素,如提高運行速度、提高對內存資源的利用率、使用戶界面更加友好、使三維圖形的真實感更強等等。我們應該樹立這樣的正確認識:優化工作不是可有可無的事情,而是必須要做的事情。

 

https://zhidao.baidu.com/question/680100884243341852.html

所謂編程思想,就是指用計算機來解決人們實際問題的思維方式。

 

我們在做一件事情的時候,這種方法是合理的:

  1. 先將一個問題分爲一個個小模塊,就好比書到章的這一種關係;
  2. 將一個小模塊分爲還要小的部分,就好比章到節的這種關係;
  3. 最終將它們分爲不可分割的部分,就好比節到定義與概念這種關係;

這就好比我們實現一個程序的功能一樣,先考慮大體方向,然後再逐步實現,做到不重不漏。

 

我們在實現程序的功能時的思維方式爲:

  1. 整體法,確定我們想要實現的功能,把思考問題的方向對準全局和整體、從全局和整體出發,我們在此時要確定實現這個功能的主要矛盾,並做合適的取捨。
  2. 結構法,確定功能內部的聯繫,進行系統思維時,注意系統內部結構的合理性。系統由各部分組成,部分與部分之間組合是否合理,對系統有很大影響。這就是系統中的結構問題。 好的結構,是指組成系統的各部分間組織合理,是有機的聯繫。
  3. 要素法,對系統的構成部分逐個實現。

 

Booch最先描述了面向對象的軟件開發方法的基礎問題,指出面向對象開發是一種根本不同於傳統的功能分解的設計方法。面向對象的軟件分解更接近人對客觀事務的理解,而功能分解只通過問題空間的轉換來獲得。

 

編程思想、軟件工程思想、模塊內變化時對其他模塊的影響

 

http://www.cnblogs.com/feng9exe/p/6771956.html

什麼是面向對象

    面向對象(Object Oriented)就是以分類的方式進行思考和解決問題。面向對象的思維方式適合於處理複雜的問題。那麼,什麼叫做複雜的問題?  

    複雜,往往指的就是“數量相當龐大”。在哲學上,我們有句話叫“量變引起質變”。當數量達到一定級別,就會出現複雜的管理問題。比如:我約一個人晚上喫飯,這個事情很簡單,我只要關注整個過程就可以了。但是,如果我今天晚上約了3萬人共進晚餐。這時候,首要的問題不是每個人喫飯的問題,而是這3萬人怎麼處理的問題?最直接的想法就是首先對着3萬人進行分類處理。3萬人可以分爲:不喫飯的、喝粥的、喫素的、喫葷的、喫燒烤的等等。這樣,我就可以讓員工分類對各種情況進行合理的處理。 

    這種簡單的、樸素的分類思想,實質上就是面向對象的思維方式。依次我們發現,這種分類思想也是管理學的一個核心理念。 

面向過程和麪向對象的聯繫 

    面向對象無法取代面向過程,他們是相輔相成的。面向對象關注於從宏觀上把握事物之間的關係,在具體到如何實現某個細節時,仍然採用面向過程的思維方式。 

    面向對象如何離開了面向過程,就無法實現真正的落地,成爲無源之水。

 

面向對象的本質和麪向對象的程序語言:

    面向對象的本質是什麼?答案是抽象。從面對的問題域抽象出解決問題所需的對象是面向對象方法的核心思想。能否恰當抽象出足夠的對象類型,特別是抽象出潛在的對象是決定軟件設計好壞的關鍵。如果從更寬泛的角度講,對我們所面對的複雜問題進行抽象,抓住本質,得出高度精煉的邏輯模型,對問題的求解具有重要的意義。從這個角度來說,抽象並不僅僅侷限於對象的抽象,也包括流程和更高層的系統結構。

 

而面向對象的程序語言應該爲實現面向對象的本質和特徵提供支持。我們說一種語言是面向對象的,實際上是對它對面向對象的軟件是想提供了支持。因此C++的虛函數、多重繼承和麪向對象之間並沒有什麼必然的聯繫,不過是此種語言用以支持多態和繼承的手段選擇罷了。

 

 

https://zhidao.baidu.com/question/2009948362326949908.html

所謂編程範式(programming paradigm),指的是計算機編程的基本風格或典範模式。

借用哲學的術語,如果說每個編程者都在創造虛擬世界,那麼編程範式就是他們置身其中自覺不自覺採用的世界觀和方法論。我們知道,編程是爲了解決問題,而解決問題可以有多種視角和思路,其中普適且行之有效的模式被歸結爲範式。比如我們常用的“面向對象編程”就是一種範式。

由於着眼點和思維方式的不同,相應的範式自然各有側重和傾向,因此一些範式常用‘oriented’來描述。換言之,每種範式都引導人們帶着某種的傾向去分析問題、解決問題,這不就是“導向”嗎?

如果把一門編程語言比作兵器,它的語法、工具和技巧等是招法,它採用的編程範式則是心法。編程範式是抽象的,必須通過具體的編程語言來體現。它代表的世界觀往往體現在語言的核心概念中,代表的方法論往往體現在語言的表達機制中。一種範式可以在不同的語言中實現,一種語言也可以同時支持多種範式。

 

http://www.cnblogs.com/feng9exe/p/5592577.html

什麼是軟件設計的複雜度

軟件技術發展的使命之一就是控制複雜度(Complexity)。從高級語言的產生,到結構化編程,再到面向對象編程、組件化編程等等。關於複雜度的定義並不一致,想要詳細瞭解的可以讀讀The Many Faces of Complexity in Software Design.

英文中Complex和Complicated有着微妙的不同。但總結起來,軟件複雜度偏負面意義,包括兩個要點: 

- 難以理解 (難以維護和擴展。) 

- 無法預測行爲 

複雜度是隨着軟件規模不斷擴大而必然產生的。它本身又是一個相對的概念,同一個系統對於設計者、開發者,以及維護者而言,複雜度是不同的。不同時期,一個程序員所能掌握的複雜度也是不同的,這也是一個程序員不斷提升的目標。

既然業界已經對抗複雜度幾十年了,我們就來整理一下。

以分解降低複雜度

以分解的方式進行的設計,主要特點是: 

- 分離職責(Seperation of Concerns,參考單一職責原則) 

- 關注接口(定義交互)

這是最常使用的技術了。將一個大問題,不斷的拆解爲各個小問題進行分析研究,然後再組合到一起。在西方稱爲Divide and Conquer Principle (分而治之原則)。

在結構化編程的時代,提倡模塊化(Modularization)。最早提出軟件複雜度的工程師提出了基於組件的軟件(Component Based Software)。不知道是不是從樂高積木上得到的啓發,將系統中拆分爲不同的組件,各自實現,然後再組裝在一起。

在架構設計中,無論是C/S風格,分層,還是N-Tier,SOA,和前面組件式一樣,都是在進行分解,它們都更加強調組合交互。設計上,分分職責,定義好接口,就可以各自開發了。然後將交互限定於接口層,就能夠很好的控制整個系統的複雜度。

比如應用層使用一個語音庫(Speech Library,一個以庫的形式的模塊化應用), 根本不用關心其內部實現,只要瞭解如何使用它的API就可以了。

 

從結構化設計到面向對象程序設計

 

http://www.cnblogs.com/feng9exe/p/6772017.html

隨着時代的發展,軟件開發項目也越來越複雜。雖然面向過程程序設計思想有諸多優點,但在利用它解決複雜問題的時候,其缺點也逐漸暴露出來:在面向過程程序設計中,數據和操作是相互分離的,這就導致如果數據的結構發生變化,相應的操作函數就不得不重新改寫;如果遇到需求變化或者新的需求,還可能涉及模塊的重新劃分,這就要修改大量原先寫好的功能模塊。面向過程程序設計中數據和操作相互分離的特點,使得一些模塊跟具體的應用環境結合緊密,舊有的程序模塊很難在新的程序中得到複用。這些面向過程程序設計思想的固有缺點使得它越來越無法適應大型的軟件項目的開發,這真是“成也面向過程,敗也面向過程”。

 

 

http://www.cnblogs.com/feng9exe/p/6776322.html

還是回到編程語言上來,看它們如何一步步成長起來的。在C語言問世之前的各種語言,行內管它們叫“步驟性”語言(Procedural Language)。所謂“步驟性”語言的特點是,重事件的線性過程,卻不重視可能發生的變化;重步驟的前後連繫,而忽略步驟的替代性和可置換性。

 

C語言的產生,在一定程度上解決了這個“計劃趕不上變化”的問題,因爲它可以把相似事件或步驟寫成可置換並可共享的“模塊”(Module)。

 

但“模塊化”的編程方式並未從根本上解決問題。我們很容易看到,無論“步驟性”語言,還是“模塊化”語言,都只是把世界看成直線平面的,程序只有一個維度:時間,按這個單向維度編出的程序,不足以描繪真實世界的全貌。受上世紀八、九十年代數據庫從數據儲存場發展到關係型數據庫,進而多維數據庫的啓發,計算機語言也開始轉變思想,進一步改革語言,讓它變得靈活、立體,容易建構和適用性強,於是“類”(Class)的概念就出現了。

 

“類”的觀念是把同類事物整合到一起,將數據、功能和行爲方法捆綁起來,限制其使用權限,增加變通性。

 

阿爾法狗使用兩個“神經網絡”(Neural Network):策略和價值,在對弈的每一步,把未來各種變化建成一棵無限伸展的“蒙特卡羅樹”,從中搜索出勝算更高,而非着眼於眼前利益的步法。由於人類棋手難以在有限時間內算出百步以外的結果,所以根據大量參數變量,快速運算,穩健選擇,是機器人克敵制勝的不二法寶。這種神經網絡方法,我在上世紀九十年代中期爲一家人工智能公司工作時,也曾用過,我們採用的是美國一位物理學家進行熱核聚變的計算方法。

 

http://www.cnblogs.com/feng9exe/p/6776316.html

結構化設計:

    結構化程序設計方法主張按功能來分析系統需求, 原則有 自頂向下, 逐步求精, 模塊化等.

 

面向對象與哲學

http://baike.baidu.com/link?url=L9od0cPynZSezvhH_QoP9kDI8oB1d9trb9hts5OtUqUyAbqsYRP_RJeuLw1oZhjtT7aPjKCB5Ur58bO4aZMKKxRMZKBiGD9aR5Baxo0cKpwUNofsImBZon8nHJe-DyaDPH6BObkIfQxG6iUJlDdaf_

系統中一切事物皆爲對象;對象是屬性及其操作的封裝體;對象可按其性質劃分爲類,對象成爲類的實例;實例關係和繼承關係是對象之間的靜態關係;消息傳遞是對象之間動態聯繫的唯一形式,也是計算的唯一形式;方法是消息的序列。

從世界觀的角度可以認爲:面向對象的基本哲學是認爲世界是由各種各樣具有自己的運動規律和內部狀態的對象所組成的;不同對象之間的相互作用和通訊構成了完整的現實世界。因此,人們應當按照現實世界這個本來面貌來理解世界,直接通過對象及其相互關係來反映世界。這樣建立起來的系統才能符合現實世界的本來面目。

http://www.cnblogs.com/leoo2sk/archive/2009/04/09/1432103.html

世界觀(德文:Weltanschauung)意爲着眼世界之上,是人們對世界的總的根本的看法。任何哲學問題的探討,歸其出發點和本源,都是世界觀的問題。什麼樣的世界觀決定了什麼樣的哲學觀點。——馬克思

1.1、看世界

      我們知道,哲學領域中,最根本的對立是唯物主義和唯心主義的對立,而附屬其下,又有許多對立,如形而上學和辯證法的對立、可知論和不可知論的對立等等。這些對立形成了哲學的基本體系、派別和出發點。實際上,這些對立,都是世界觀的對立。世界觀,簡而言之即如何看待這個世界。世界觀是一切哲學問題的本源和出發點。

      同樣,在程序世界裏,也有着不同的世界觀。而這其中最根本的對立便是過程論和對象論的對立,這個對立,衍生出了面向過程和麪向對象兩種方法論。於是,要真正理解面向過程和麪相對象,我們就不得不先深究一下程序世界中這兩種世界觀。

      首先要提到的是,不論是過程論還是對象論,都承認一點,那就是程序世界本質上只有兩種東西——數據和邏輯。數據天性喜靜,構成了程序世界的本體和狀態;邏輯天性好動,作用於數據,推動程序世界的演進和發展。儘管上述觀點是統一的,但是在數據和邏輯的存在形式和演進形式上,過程論和對象論的觀點截然不同。

      過程論認爲:數據和邏輯是分離的、獨立的,各自形成程序世界的一個方面(Aspect)。所謂世界的演變,是在邏輯作用下,數據做改變的一個過程。這種過程有明確的開始、結束、輸入、輸出,每個步驟有着嚴格的因果關係。過程是相對穩定的、明確的和預定義的,小過程組合成大過程,大過程還可以組合成更大的過程。所以,程序世界本質是過程,數據作爲過程處理對象,邏輯作爲過程的形式定義,世界就是各個過程不斷進行的總體。

      對象論認爲:數據和邏輯不是分離的,而是相互依存的。相關的數據和邏輯形成個體,這些個體叫做對象(Object),世界就是由一個個對象組成的。對象具有相對獨立性,對外提供一定的服務。所謂世界的演進,是在某個“初始作用力”作用下,對象間通過相互調用而完成的交互;在沒有初始作用力下,對象保持靜止。這些交互並不是完全預定義的,不一定有嚴格的因果關係,對象間交互是“偶然的”,對象間聯繫是“暫時的”。世界就是由各色對象組成,然後在初始作用力下,對象間的交互完成了世界的演進。

 

http://www.cnblogs.com/feng9exe/p/6771887.html

面向過程就是面向解決問題的過程進行編程。

傳統的面向過程的編程思想總結起來就八個字——自頂向下,逐步細化!實現步驟如下:

  1. 將要實現的功能描述爲一個從開始到結束按部就班的連續的步驟(過程);
  2. 依次逐步完成這些步驟,如果某一步的難度較大,又可以將該步驟再次細化爲若干個子步驟,以此類推,一直到結束得到想要的結果;
  3. 程序的主體是函數,一個函數就是一個封裝起來的模塊,可以實現一定的功能,各個子步驟往往就是通過各個函數來完成的,從而實現代碼的重用和模塊化編程!

 

http://www.cnblogs.com/feng9exe/p/6772034.html

面向過程編程是以功能爲中心來進行思考和組織的一種編程方法,它強調的是系統的數據被加工和處理的過程,在程序設計中主要以函數或者過程爲程序的基本組織方式,系統功能是由一組相關的過程和函數序列構成。

 

http://www.cnblogs.com/feng9exe/p/6771933.html

對象的抽象與關係的抽象

  面向過程的設計更具挑戰性,技巧性,面向對象主要在於對象抽象的技術性,一旦完成抽象,

總的來說:

                   面向對象是將事物高度抽象化。

                   面向過程是一種自頂向下的編程

                   面向對象必須先建立抽象模型,之後直接使用模型就行了。

 

http://www.cnblogs.com/dbEssay/p/6358253.html 

面向對象:用線性的思維。與面向過程相輔相成。在軟件開發過程中,宏觀上,用面向對象來把握事物間複雜的關係,分析系統。微觀上,仍然使用面向過程。

“面向過程”是一種是事件爲中心的編程思想。就是分析出解決問題所需的步驟,然後用函數把這寫步驟實現,並按順序調用。

 

http://www.cnblogs.com/feng9exe/p/6776303.html

1)工程隱喻

在各種隱喻中,建築工程與軟件開發的關係最爲密切,這個隱喻與軟件開發的相似之處最多,因此影響也最爲深遠。這個隱喻有四個要點:分解、分配、設計和階段化。

分解是一種極爲深刻的思想,將整個過程分爲幾個階段,將整個任務分解爲幾個子任務,將系統分解爲多個層次,多個模塊,將需求劃分爲多個類型等等。這樣的思路,是解決複雜問題的唯一正確的方法,一團亂麻的需求、任務、項目、設計,根本不可能成功。但是分解也意味着它最好第一次就劃分正確,當任務被層層分解,變成了很多很多的子任務、模塊、子模塊、類的時候。你發現有一個子任務的分解有問題,修改的困難可能極爲驚人,而軟件開發,在第一次就劃分正確的情況,幾乎絕無僅有。

分配與分解一樣,是工程隱喻所特有的,當一個需要完成的系統,已經被仔細的分解之後,分解的粒度會達到一個人能過獨立完成的範圍,然後根據現有的資源以及任務的前後依賴關係,合理的分配給各有不同能力和特長的人,沒有這樣的分配,項目同樣會一片混亂,而這個隱喻還包含一種(支配關係),存在分配的人與被分配的人,層層分解的任務與層層分解的人力資源,使得整個項目成爲一個嚴密的金字塔結構,而這樣的結構,往往使得項目的應變能力與可能性,隨着項目的擴大而縮小。

基於以上的兩個要點,工程隱喻極爲順理成章的推出了這樣一個結論:“必須嚴格的控制需求的變更,如果可能,將所有的變更都頂回去。”純正的軟件工程的思想中,任何需求的變更都是不受歡迎的。

設計極爲重要,無論是對於建築還是對於軟件開發來說,都是這樣。但是設計與設計不同,在建築行業,不體現設計師理念的建築,會被稱爲沒有靈魂的“水泥塊”。但是在軟件開發裏,如果開發人員老是想着往程序里加入自己的東西,會被稱爲過度設計。但是由於軟件開發對於建築工程的模仿,過度設計變得比比皆是。

在建築工程中,有着極爲清晰的階段劃分,分析、設計、施工、驗收。最早的軟件工程,就是完全模仿這樣的階段而執行的。這樣的模仿,後果是嚴重的,因爲這樣的階段不是軟件開發的特徵,強行套用,大多失敗。隨後的改進似乎總也跳不出這個思維模式,就像用無數的直線去擬合一條曲線,用N多個正方形去拼出一個圓形。比如說螺旋式開發,在一個螺旋中,還要搞出四個象限,使得軟件開發的過程,不斷的重走這四個階段。但是,軟件開發的過程,真的是像建築工程一樣嗎?

 

3)舞蹈隱喻

CMM本身不需要隱喻,它的理論基礎來源於純正的軟件工程,所有軟件工程有關的隱喻,CMM都用得上,但是CMM有它自身的特點,主要是在CMM的實施方面。我看到過一個關於CMM實施的隱喻:軟件開發就像跳舞,軟件過程改進就像是舞蹈編排,軟件開發人員在過程改進專家的知道下,就像舞蹈演員在舞蹈編導的知道下,學習新的節奏、動作。最後開發出令消費者滿意的軟件產品。就像舞蹈演員爲觀衆帶來出色的表演。這樣的隱喻,爲一個巨大的諮詢市場開闢了道路;最天才的舞蹈演員,也不能沒有編導的知道,所以想要公司提高CMM等級,就必須找專家來做諮詢,果然巧妙!但是這樣的隱喻,卻經不起推敲,舞蹈編排過程中,演員們排練的目標是達到編導的要求,如果演出的效果不好,自然由編導負責。但是軟件開發過程的改進,如果也是爲了博得諮詢專家的滿意,到時候軟件開發出來不賺錢,那些專家可不會負責。他們早就賺到諮詢費,走人了。關鍵問題在於,過程改進只能是一種手段,它本身不能成爲目的,更不能想當然的認爲,完美的過程就一定能帶來完美的產品。舞蹈編導不是觀衆,沒有一個編導敢保證自己的這次創作,一定能贏得觀衆的好評,但是爲什麼現在CMM專家,就敢作出這樣的保證呢?當舞蹈演員在一個“三角形的舞臺上”,完美的跌落的時候,誰會爲這樣的悲劇負責呢?

 

 

1. 2. 3. 4. ""Make it run, then make it right, then make it fast.90%100%Delete

------------------越是喧囂的世界,越需要寧靜的思考------------------ 合抱之木,生於毫末;九層之臺,起於壘土;千里之行,始於足下。 積土成山,風雨興焉;積水成淵,蛟龍生焉;積善成德,而神明自得,聖心備焉。故不積跬步,無以至千里;不積小流,無以成江海。騏驥一躍,不能十步;駑馬十駕,功在不捨。鍥而舍之,朽木不折;鍥而不捨,金石可鏤。蚓無爪牙之利,筋骨之強,上食埃土,下飲黃泉,用心一也。蟹六跪而二螯,非蛇鱔之穴無可寄託者,用心躁也。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章