工程思想方法及其在軟件工程分支的教學上的體現

前幾天寫了一篇跟軟工課程相關的博客[1],有一位能夠促成具有建設性對話的同學問了我一個問題:

能展開講講你說的工程思想和方法麼,以及從軟工的哪些環節可以獲得?

這位同學問了一個很好的問題。好在哪裏呢?好在他試圖詳細地瞭解和分析一個抽象的表面上看起來高大上而且美好的概念,從而提出了一個往具體方向上討論的引導問題。

同學們在面對類似的抽象的表面上看起來高大上而且美好的概念(例如“自由”和“平等”)時,一定要向自己或者向別人提出類似的往具體和細節上引導的問題。

在正文開始前,我要向各位老師和助教道歉。很抱歉在沒有事先跟你們溝通的情況下,就衝動地答應回答這個問題。希望我這個越俎代庖的行爲能得到大家的原諒。

另外我想跟同學們澄清一件事,我大多是在紙上談兵,老師和助教們是在實踐。大家要謹記“實踐是檢驗真理的唯一標準”,當理論和實踐不一致的時候,要以實踐爲準。

以下是我個人的看法,不一定代表老師和助教們的看法,也不一定對。

工程思想和方法

在正式展開我個人看法之前,我想再次重複我在 當前階段 總結的工程的目標:在當前社會環境中,工程實施者使用有限的資源,把能創造的價值最大化,並將其凝固在一個商品裏面。

我想請讀者試着回憶我在上一篇博客中反覆強調的一個跟工程相關的行爲是什麼?

大家的回答應該都是差不多的,否則就是我的表達能力有問題。儘管回答可能差不多,但以我 對自己的要求和標準 來看,我分成了四個層級:

第一層是捨棄,第二層是取捨,第三層是爲了創造最多的價值而取捨,第四層是在理解資源是有限的且瞭解了當前社會環境提供了哪些資源以及自己掌握了哪些有限的資源的情況下爲了創造最多的價值而取捨。

對我來說,這就是工程思想的核心。

接下來我會列出其他思想中的 一部分。其中有些是前輩們在他們各自所處的時代中通過實踐總結的,有些是我自己總結的(因爲我沒有系統地學過工程學)。

  • 分類討論思想
  • 迭代思想
  • 快速迭代思想(快速試錯、快速同步)
  • 可持續思想
  • 分而治之思想
  • 動態調整思想
  • 折中思想
  • 矛盾思想
  • 可預期思想

接下來我嘗試對這些思想做一些展開:這些思想是爲了解決什麼問題以及符合這些思想的方法有哪些。然後將這些思想結合到軟件工程的教學中。

分類討論思想

對於同學們來說,分類討論思想再熟悉不過了。數學考試中經常要用到分類討論思想,而且通常是一道比較難的題目。但我們這裏不討論純粹的數學,我希望能夠立足於課本知識,但超越課本知識。另外我數學成績也只能算是中等(逃

分類討論思想的通俗化表達是“具體問題具體分析”,它的反面是“在任何條件下都使用同一種具體的解決方法”。

分類討論思想所要解決的是將一個抽象的問題根據不同條件轉化爲多個具體的問題,再根據具體問題的不同特點分別用不同的方式解決。

舉個生活中的例子: A 和 B 說頭疼了,B 應該怎麼回答?或者有人跟你說頭疼了,你應該怎麼回答?

這是一個非常抽象的問題,需要分好幾層的分類討論。

首先要對雙方的性別做一個分類,做這個分類在當前社會環境下具有一定風險。我在這裏根據國內大部分人的共識將其分爲兩類,男和女。由於縮小了數據集,因此只有四種情況。

這裏使用分類討論思想的圖表法,把四種情況列出來。

A男、B男 A男、B女
A女、B男 A女、B女

接着要對問題的主體雙方的關係進行分類,可以有以下幾種類型(我只列出部分):

  • 師生關係
  • 情侶關係
  • 普通朋友關係
  • 損友關係
  • 同事關係

其中這些類型有的是非對等關係(比如師生關係),換個順序很可能得到不一樣的結果;有的是對等關係(比如損友),換個順序很可能得到一樣的結果。

非對等關係通常使用排列的方式展開,對等關係通常使用組合的方式展開。這個可以根據實際情況調整。

通常我們看到一個問題,會下意識地採用社會共識所選擇的類型加以判斷。例如有人問 1+1 等於多少?根據社會共識,這個問題的完整表述是:在數學中,1+1 等於多少?於是我們回答,等於 2。

回到這個具體問題,社會的共識是,這個對話通常是在情侶關係中由女方發起的。我們可以先從最主要的這個分類開始討論。

接下來我們對頭疼這個現象進行分類。可以大致分爲:真的頭疼和假的頭疼兩類。然後再對女方的心理活動進行大致分類:想要解決頭疼問題、想要男朋友的關心、兩者都要。

現在我們使用分類討論思想中的連線法進行組合:

再從男方的角度做一些分類:

  • 想解決頭疼問題
  • 想關心女朋友
  • 兩者都想

還可以再做進一步分類,例如想解決頭疼問題:

  • 可以想出很多種方法
  • 只能想出“多喝熱水”

寫得我好累。不想再展開了。

從這些分類中,根據不同的連線大致寫出對應的解決方法。

  • 比如男女雙方是情侶,女方對男方說頭疼,但不是真的頭疼,她想要男朋友的關心,但男方想解決頭疼問題,又沒辦法想出很多方法,於是回答“多喝熱水”。
  • 再比如男女雙方是情侶,女方對男方說頭疼,但不是真的頭疼,她想要男朋友的關心,男方想關心女朋友,於是說了一些關心的話,還可以做一些她喜歡喫的東西,以及其他 N 中解決方法。

我們通常說一個男生是直男,有一部分原因是他們對於問題的理解停留在了表面,同時試圖解決這個表面的問題,又找不到合適的解決方法。這是一下子犯了 N 個錯誤才導致了 “多喝熱水” 這種答案。把問題分析到這種地步的時候,就會知道不是隻有男性這個羣體纔會出現的問題,這是人類這個羣體會出現的問題。

分類討論思想不僅僅是用來解決工程上的問題,還可以用來解決思想上的問題。

我花這麼長的篇幅來舉這個例子,是爲了以下內容不必過多展開。

迭代思想

迭代思想指的是在原有的基礎上有計劃地不斷改進以接近完美,與之相對的是一次性完美思想。

認爲一個完美的東西纔有價值,是人的缺點,需要通過後天的努力去改正。迭代思想要求人們接受不完美,看到不完美的東西的價值。

迭代的方法之一是把一個工程分成多個階段,每個階段設定一個可交付的標準,當前階段的每個事項做到預設標準就停下來,不繼續往下做。

不完美至少有兩種情況:

  1. 同一個功能有速度快的粗糙實現方案(比如手工調整),也有速度慢的靈活實現方案(比如自動調整)。粗糙的方案在這種情況下不是完美的選擇,但是可以在前面的迭代中實現,後續迭代中用靈活的實現方案替代。
  2. 在同一個方案中,有些重要的功能先實現,有些不那麼重要的功能放到以後實現。同一個方案沒有全部實現也不是完美的選擇。

迭代思想通常與分而治之思想配合。

分而治之思想

當我們明確了一個具體的問題之後,需要開始解決問題。但是如果這個問題非常大,無從下手,怎麼辦?分而治之。

分而治之思想還會和迭代思想以及矛盾思想進行配合。

詳細地分析這個具體的問題,會發現這個大的具體的問題可以分成幾個中等的具體問題。然後再去分析這些中等的具體問題,就會發現一箇中等的具體問題還可以分成幾個小的具體問題。接着繼續一直劃分下去,得到了一顆多個層級的樹。如果要開始解決這個大的問題,那麼就去解決葉子節點上的問題。

可是這個時候又發現葉子節點實在太多了,如果隨便選一些完成,可能要到所有葉子節點的問題解決之後,才能影響到大的問題的解決。

這時我們需要挑選葉子節點中對大問題影響程度大的那些,每次都儘量挑選一批影響程度最大的葉子節點出來解決。挑選影響程度大的葉子體現了矛盾思想,分次挑選體現了迭代思想。

矛盾思想

矛盾思想這裏指的是主要矛盾和次要矛盾。

主要矛盾是當前階段中對結果影響最大的一個點,其他的點都是次要矛盾。當解決了主要矛盾,會進入下一個階段,此時在上一個階段中的次要矛盾中會有一個對結果影響最大,此時該次要矛盾成爲了當前階段的主要矛盾。

區分主次矛盾不是爲了忽略次要矛盾,而是把更多精力用來解決主要矛盾。比如 80% 精力用來解決主要矛盾, 20% 精力用來解決次要矛盾。在實踐中,通常解決次要矛盾有助於解決主要矛盾。

快速迭代思想(快速試錯、快速同步)

快速迭代與迭代的區別在於迭代的期限很短。爲啥要縮短迭代的期限?

因爲我們通常在迭代結束的時候,纔會交付當前迭代的成果。但是由於對問題理解上存在偏差,很可能導致這個成果無法解決問題,需要重新做。

爲了減少這種反覆重做導致的資源浪費,可以縮短迭代的期限。這樣可能在某個行動項上只完成了 20% 就發現這個行動項無法解決問題,此時只浪費了 20% 的資源。迭代的期限如果拉長,等到完成 80% 才發現無法解決問題,那麼就浪費了 80% 的資源。

快速迭代思想還不止於此,在具體的實踐中,會有一些優化方案。我會在結合軟工時補充上這一點。

可持續思想

同學們對可持續思想也比較熟悉,經常背到。不知道同學們對可持續的重要性有多少思考?

可持續思想能夠解決的是隨着時間的推移,系統會自毀的問題。人就是一個系統,而且會不停地作死。

可持續思想是怎麼解決這個問題的?通過限制效率。一個項目的推進有多種選擇,其中必定有一種效率最高的推進方式。可持續思想就是要阻止你選擇這個效率最高的推進方式。

比如有一個高效率獲取快樂的方式(大家應該都懂,我怕文章被和諧就明確指出來了),爲什麼所有人都不使用這種方式去獲取快樂呢?因爲它不可持續。高效率帶來的是快速的消滅。人類將其加入刑法,就是阻止人類高效率地作死。

動態調整思想

動態調整思想能夠解決因對有限資源的誤判或者有限資源臨時變動出現的問題。

比如在迭代前選定了一批要解決的具體問題,但是在迭代中工程的施工人員數量發生變化。如果按照原先安排,可能會導致人員數量繼續發生變化。於是需要重新組合有限資源,並且對選定的問題做一些動態調整。

折中思想

折中思想面對的是單一的完全的選擇沒有比多個的部分的選擇的價值高的問題。形象的表達是 0.5 + 0.5 > 1。

在計算機歷史中,最不缺的可能就是折中了。同學們應該深有體會。

比如既然內存速度那麼快,爲啥還要用到硬盤?你可能說因爲內存斷電數據就丟失了呀。那我用一大堆設備確保它不斷電不就行了?

其實這總體上是一個性能和成本的折中問題(往深了講還有發展水平問題)。只用內存的產品不是沒有,但是很貴,難以推廣到全世界大多數人使用。只用硬盤也可以,但是速度會很慢,如果大家都只用硬盤,那就沒關係。問題就在於有人用少量內存和大容量硬盤結合起來,速度既可以很快,價格又能接受,於是更多人選擇了這個折中的產品。

預期管理思想

說實話沒想好準確的詞,湊合着用吧。

預期管理思想是讓自己成爲一個可預期的存在,以此管理其他人的行爲。大致分爲時間預期和行爲預期。

時間預期就是完成一個事項需要多少時間。這樣在工程迭代過程中,可以做出不同的調整。

  • 例如根據事項的預期完成時間和迭代的時間限制來挑選事項;
  • 或者發現所有事項的預期時間之和超過了所有迭代時間之和,那麼就可以做不同的調整。
  • 例如捨棄掉某些事項;
  • 或者增加施工人數。

大家對行爲預期比較熟悉的一個子類應該是底線思維。就是讓對方知道,一旦跨過這個底線,我方一定會讓對方付出巨大的代價,這個代價大概率是對方無法接受的,除非對方想同歸於盡。這樣對方就處在我方的管理之下,最多隻能在底線之上蹦噠。

舉個我自身的例子。我會讓領導知道我在當前階段主要想通過編程(包括學習技術、系統設計、編碼)解決問題,如果領導在這個階段強行給我一個沒什麼時間編程的崗位(例如產品經理或者管理崗),那麼我會立刻提出離職;而如果讓我把大部分時間花在編程上,那麼我剩餘的時間會幫助領導解決很多系統之外的問題。這樣領導可以評估他的這個行爲會對項目和他自己產生多大的影響,以及是否有消除影響的方法。如果有消除影響的方法,那麼可以逼我去沒時間編程的崗位,或者直接裁掉我。

爲了避免誤導大家,希望大家要注意,行爲預期管理思想對個人的硬實力要求高。比如我自身的例子要求我能夠創造足夠多的價值,以及我能夠承受離職帶來的影響。

工程思想和方法在軟工課程的各個環節上的體現

這裏的軟工課程指的是參考《構建之法》開展的軟工課程,因爲不同的軟工課程的開展方式不一樣。

同學的原問題是“從軟工的哪些環節可以獲得(這些思想方法)”。爲了嚴謹,我把思想和方法分開。方法可以從軟工的環節中獲得,思想則需要提醒和思考總結。

由於《構建之法》本身提供了很多方法,滿本都寫着兩個字“方法”(皮一下,如果鄒欣老師覺得這麼說不妥,我再換種表達),而且肯定比我一篇博客所能講的還來的詳細,感覺沒多大必要做這樣的重複。不知道下面的回答能否算是提供了一個令人滿意的答案。

課前

老師和助教通過可預期思想方法,讓同學們知道自己大概會在課程結束後得多少分。

個人技術和流程

這裏涉及了測試。測試是爲了阻止開發者以最高的效率完成一個既定任務,讓工程穩定可持續地推進,避免出現重大問題導致工程失敗,體現可持續思想。

這個階段對需求分析的要求還不是很高,放團隊項目說明。

結對編程

制定代碼規範、代碼複審和結對編程過程是軟件工程中爲了可持續推進項目而要求實踐的工程方法,都是爲了阻止開發者以最高的效率完成一個具體任務,體現可持續思想。

可以在兩人合作過程中使用分類討論思想的方法以提高合作效率。

團隊項目

老師和助教可以通過分類討論思想的方法,大致確定各團隊選題方案的合理性。可以通過可預期思想方法,讓同學們再次對自己的最終得分有一個較之前更準確的認識。

以下是與同學們相關的內容。

可以實踐分類討論思想的方法提高合作效率。

需求分析的時候:

  1. 用分類討論思想方法分析用戶羣體
  2. 用矛盾思想方法篩選出核心用戶羣體
  3. 找到具體的用戶,通過分類討論思想方法瞭解用戶,交流需求
  4. 用分而治之思想拆解問題,和用戶確認重要具體問題的細節,產出軟件功能規格說明書
  5. 用快速迭代思想的方法快速繪製原型,儘快與用戶確認,避免浪費開發資源

設計系統的時候:

  1. 用分而治之思想拆解具體問題
  2. 用折中思想的方法平衡完成時間和軟件性能或者功能

做工程規劃的時候:

  1. 用迭代思想、分而治之思想、矛盾思想、可預期思想的方法規劃各階段任務(Alpha 和 Beta 版本),避免系統無法按時交付

施工的時候:

  1. 結合可預期思想和動態調整思想的方法,調整迭代任務
    同學們通過站立式會議,及時準確地同步項目進展。PM 通過當前進展調整迭代任務,並反饋給老師和助教。讓老師和助教對團隊的進展有一個清晰的認識,並及時提供指導意見。
  2. Alpha 做完後快速交付給用戶,得到及時反饋,儘快調整 Beta 迭代的任務。這個是快速迭代思想的方法
  3. Alpha 和 Beta 做完後專門做了事後分析,阻止了同學們試圖採取最高效率的方法繼續推進項目,確保項目可持續

關於課程總結

我們當時在上張棟老師的課時,最後一次作業[2]中,有一個內容:

寫下屬於自己的人月神話——項目實踐中的經驗總結+實例/例證結合的分析

現在想起來,覺得很妙。且聽我具體解釋。

大多數理論都是不完美的,特別是工程類的理論。理論總是要結合實踐,通過實踐來驗證理論的正確性,但僅僅這樣還不夠。

世界的複雜性決定了一個理論難以適用所有的情況。可以說任何人所具備的“有限的資源”都是不一樣的。一旦條件不一樣,那麼在實踐一個理論時,很容易就得到不同的結果。

理論只有指導作用,指導不是強制。理論不一定和實踐一致,而且往往與實踐不一致。如果理論和實踐不一致,要以實踐爲準,並通過實踐反過去補充和完善理論。正是在實踐中得到的不同的結果,推動了理論的完善,進而推動人類的進步。

人們想要把具體實踐對理論的影響固化下來,想出了一種方法:寫論文。從上述內容看,一個實踐可以通過驗證在不同條件下理論仍然成立來補充理論;也可以驗證在不同條件下理論不成立,以及如何調整理論來包括這種條件以補充理論。

同學們認爲軟工改革的時候,自己是“小白鼠”,這似乎是比較悲觀的看法。在我看來,同學們以及老師和助教都是在通過自己“有限的資源”實踐軟件工程理論。在實踐的過程中會碰到屬於自己的問題。在解決各自問題的過程中,形成了屬於自己的軟件工程理論,最終通過總結把自己的“有限資源”以及軟件工程理論在這些“有限資源”的條件下的實踐情況表述出來。這樣在客觀上推動了軟件工程理論的完善,進而爲整體人類的進步做出自己的貢獻。

你們還未察覺到你們正在做的事情有多麼偉大。

這不是安慰,也沒有其他亂七八糟的想法。我是通過上述的事實和邏輯(雖然很粗糙)得到這個結論的,也就是說我是真的這麼認爲的。

寫在最後

寫完這篇博客後,除了工作上的一些總結之外,我在 2021 年不會再像這樣大量輸出跟軟工課程相關的內容了。我現在最需要的是輸入而不是輸出,從這兩篇博客的內容上大家就可以看得出來。

客觀上,這兩篇的博客會在一定程度上(雖然很低)提高我個人的影響力,這是我目前階段應該儘量避免的,因爲我必須承擔由此帶來的本不必要的風險和代價。

不過也正是因爲之前的那篇博客,使我和恩師張棟老師的關係得到進一步加深,所以我認爲承擔這個風險和代價是值得的。

最後的最後,提前給大家拜個早年。祝大家身體健康,事業順利,學業順利!

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