閱讀作業

沒有銀彈 No Silver Bullet - Essence and Accidents of Software Engineering - Brooks

在這篇論文中，作者闡述了軟件的四個本質：Complexity,Conformity，Changeablity, Invisibility

在解釋復雜性時，作者首先把軟件和其他的人類建造物做對比：

    Software entities  are  more  complex  for  their  size  than  perhaps  any  other  human  construct,  because  no  two  parts  are  alike  (at  least  above  the  statement  level).    If  they  are,  we  make  the  two  similar  parts  into one,  a  subroutine,  open  or  closed.    In  this  respect  software  systems  differ  profoundly  from computers,  buildings,  or  automobiles,  where repeated elements abound. 
 

在軟件開發中，如果我們遇到兩個相同的部分，我們一般的做法是把他們寫成一個函數，以便於重用，因此軟件的每個組成部分可以說是互不相同的，不可替代的。而在人類的其他建造物，例如樓房，則是由重復的磚塊，或者是鋼筋混凝土搭建而成，因此軟件的復雜性遠超於普通的事物。

而作者又把軟件的復雜性與基礎科學例如數學物理的復雜性做對比，我覺得這裏的對比真的讓人豁然開朗，它突出了軟件的復雜性的本質性

 Mathematics and the physical sciences made great strides for three centuries by constructing  simplified  models  of  complex  phenomena, deriving  properties  from  the  models,  and  verifying  those  properties  experimentally.    This  worked  because  the  complexities ignored in the models were not the essential properties of the phenomena.  It does not work when the complexities are the essence. 
 

物理和數學學科之所以在建立了基本概念和模型後，可以快速發展的原因就是物理和數學的“本質”並不復雜，但是為什麽軟件工程沒有這樣的基礎模型和概念呢？就是因為軟件的復雜性就是軟件的本質之一!

軟件的可變性也是軟件的本質之一，為什麽軟件一直在被改變呢？就是因為軟件是一個embedded system，它和硬件有關，和寫軟件的人有關，和需求有關，一旦這些影響因素發生變化，例如硬件更新換代，需求變更，那麽軟件就需要隨之更新，所以軟件是在一直變化的。

軟件也是“不可見”的，一個軟件實體不能用一張圖或者一個立體模型給表現出來，因為它的復雜性和易變性，如果嘗試為一個軟件建立一個可視化的模型，那麽可能需要幾個圖模型，有的表示數據流向，有的表示依賴關系等等，但是這些都無法像現實世界的實體一樣，通過一個立體模型直觀的表現出來。

在之後作者提出的一些建議中，我覺得這個建議很關鍵：

Incremental development?grow, not build, software.

我們要做的不是建造軟件，而是不斷的更新軟件，關於這一點，神策數據的CEO桑文鋒老師就在α階段的總結會上提到過類似的，就是不要想著一開始就造一個大工程，好的軟件是靠不斷的更新換代產生的，可惜的是，我們在這個學期的軟件開發過程中並沒有很好的貫徹這個原則，不過我是非常贊同這個觀點的。雖然在我們的團隊開發中沒有實現不斷叠代版本，但是我自己在寫一些個人項目，例如我們的編譯大作業，再比如之前的計組等的過程中可以感受到 叠代的重要性。我們無法在一開始寫出一個軟件就保證它是最好的，只有在不斷的根據用戶反饋或者自己的重構中不斷的提高軟件的質量。

Big Ball of Mud

“大泥球代碼”，這個比喻非常生動，它形容那些結構雜亂無章的代碼。我覺得這樣的代碼的產生有兩個情況，如果設計者只有一個，那麽這個設計者在一開始肯定沒有想好怎麽組織代碼，就糊裏糊塗的開始寫，如果代碼的參與者有多個，那麽這些參與者在一開始一定沒有統一代碼的編寫規範，導致各寫各的，合在一起就變成了四不像。

為了避免這種代碼的產生，我覺得首先是要有一個清醒的頭腦，在開始寫之前先想好大致的架構，然後是要有不斷改正更新的勇氣，很多人因為重構比較麻煩就懶於重構修改，導致代碼結構越來越混亂龐雜，最後只能推到重來，這是極其費時費力的行為，最後是要有一個統一的原則和規範，這個在多人合作時極為重要，在我們自己的團隊開發中，就經常會因為一些原則規範不明確，導致一些時候開發工作效率低下，不過這種情況下只需要及時補充規範，嚴格執行規範，及時糾正即可。

Cathedral and the Bazaar

作者拿“教堂”和“集市”類比軟件開發的兩種模式，教堂模式就好像封閉的建設，會有精致的設計，充足的成本，長期的建設，而集市模式則更像是自然而然的形成，大家都來參與集市的建設，當然最後質量通常不如精心設計和建造的教堂。

我覺得軟件開發如果可以吸收兩個模式的優點會更好，首先吸收教堂模式的優點，就是必須要有一個軟件設計主導者或者大家都要遵守的設計原則，防止這個軟件不會跑偏，然後就是要結合集市模式的特點，大家都可以為軟件開發做出自己的貢獻，集百家之長。

我們的開發模式一開始是大教堂模式，就是由一個人制定設計，其他人執行設計，但是後來發現其他課程的課業太繁重了，如果還由一個人設計，可能導致開發進度過慢，所以之後就變成了集市模式。

所謂質量，只有在某人對它負責時才有意義，而這個“某人”只能是一個人，不能是幾個人——二重奏除外

我認為這句話很有道理，在我們的團隊開發中，一開始是由多個人討論設計，但是很快就發現，每個人往往都只會關註和推崇自己的設計，對他人的設計往往采取排斥的態度，所以後來我們的設計只由一人負責，其他人僅僅審查並提出一些意見而已，這樣做才能保證質量。

我們團隊曾經遇到過這種情況，不過很快改正了

瀑布模型

我覺得我們團隊開發的瀑布模型是這樣的： 遊戲內容設計 -> 內容設計轉化為邏輯設計（類的組織） -> 邏輯設計轉化為代碼編寫 -> 測試運行並調整遊戲平衡性

這個開發過程給人的感覺就好比單周期流水線的運作，效率很低（至少我是這麽認為的），因為下一階段的負責人必須要等待上一階段結果的產生，最重要的是不能並行運作，例如如果遊戲內容設計人員給了你一部分內容設計，在你把這部分轉化為邏輯的設計後，發現如果把遊戲設計人員給你的另一部分設計參與到已有的邏輯設計中的話，很多原來的結構都不適用了。雖然我們經常要求軟件設計要有可擴展性，但是這個可擴展性的“擴展能力”我認為有時根本不能滿足需求的改變，因為總有一些擴展的情況是你想不到的。

如果軟件開發的過程能夠達到像CPU流水線那樣精巧的並行設計該多好，至少在我們的團隊開發中，我們沒有實現並行。

個人總結

這個學期的軟工學習了很多，一開始的個人項目和結對編程，讓我學習了C++和QT的基本使用，這也為之後的編譯打下了堅實的C++語言基礎，之後的團隊項目，雖然坑很多，但是讓我第一次體驗了團隊開發，同時也體會到了一個好的PM，一個好的團隊交流，一個確定的代碼規範對於團隊編程是多麽重要。

不過這裏也需要著重說明一下最大教訓，就是框架的選擇，不成熟的框架可能會造成很多不必要的麻煩，這裏也不一一列舉了，總之在選擇框架時不僅僅需要要看它的可用性，還要註意它支不支持單元測試！

[2017BUAA軟工]個人閱讀作業+總結