我的博客做業 #4

•  No Silver Bullet

　　Fred Brooks在1987年所發表的一篇關於軟件工程的經典論文《No Silver Bullet》中談到:全部軟件活動包括：

1. 根本任務—— 打造構成抽象軟件實體的複雜概念結構；
2. 次要任務—— 使用編程語言表達這些抽象實體，在空間和時間限制內將它們映射成機器語言。

　　其中軟件工程師在次要任務上花費了過多的時間，然而次要任務佔軟件工做的比例有限，因此一味地從次要任務方面進行優化沒法帶來軟件生產率數量級上的提升，須要開始關注軟件的根本任務。

　　人們在軟件開發中試圖尋找一種可以使得軟件可以像硬件中的電子管、晶體管那樣指望每兩年有兩倍的增加。然而並不存在任何技術或管理上的進展，可以獨立地保證軟件在生產率、可靠性或簡潔性上取得數量級的提升。這是由軟件的自身特性決定的，可是卻擁有一些使人振奮的革新。這些方法的規範化、持續地開拓、發展和傳播確實可使生產率產生數量級的提升。由此，產生了如今的軟件工程。

 

　　現代軟件系統中有一些沒法規避的內在特性：複雜度、一致性、可變性和不可見性。

1. 複雜度。軟件實體可能比任何由人類創造的其餘實體更復雜，軟件系統的狀態又比計算機的狀態多若干個數量級，軟件實體的擴展不只僅是相同元素重複添加，致使軟件複雜度要比非線性增加多得多。

2. 一致性。軟件工程師所要面對不少狀況，好比：必需要遵循許多人爲慣例。這些慣例隨接口的不一樣而不一樣，然而，這些變化並非必需的，僅僅因爲它們是不一樣的人設計的結果。在這種狀況下，軟件的複雜性來自：須要保持與其餘接口的一致性，對軟件自身的任何再設計，都沒法簡化這一複雜特性。

3. 可變性。軟件實體常常會遭受到持續的變動壓力。功能擴展的壓力主要來自那些喜歡基本功能，又對軟件提出了不少新用法的用戶們。此外，軟件必定是在某種計算機硬件平臺上開發，成功軟件的生命期一般比軟件開發時所用的硬件平臺要長。軟件必須與各類新生硬件保持一致。
4. 不可見性。軟件是不可見的和沒法可視化的。軟件的客觀存在不具備空間的形體特徵。所以，沒有自身的幾何表達方式。

 

　　在軟件領域中取得的最富有成效的三次進步體如今對於次要困難的解決包括：高級語言，分時，同一編程環境。

1. 高級語言。軟件生產率、可靠性和簡潔性上最有力的突破是使用高級語言編程。大多數觀察者相信開發生產率至少提升了5倍，同時可靠性、簡潔性和理解程度也大爲提升。  
2. 分時。分時在提升程序員的生產率和產品質量方面起到了很大做用，分時保證了及時性，縮短了系統的響應時間。隨着它接近於零，超過人類能夠辨識的基本能力—— 大概100毫秒時，所得到的好處就接近於零了。
3. 統一編程環境。集成開發環境經過提供集成庫、統一文件格式、管道和過濾器，解決了共同使用程序的次要困難。這樣，概念性結構理論上的相互調用、提供輸入和互相使用，在現實中能夠很是容易地實現。集成開發環境的普遍應用使生產率實現提升。

 

　　然而，如以前所述，一味地從次要任務方面進行優化沒法帶來軟件生產率數量級上的提升，須要開始解決軟件的根本而非次要問題，能夠從如下幾個方面來考慮：

1. 快速原型化系統的方法和工具。軟件系統的快速原型對重要的系統界面進行模擬，並演示待開發系統的主要功能。
2. 增量開發—— 增加，而非搭建系統。這種開發模式對士氣的推進是使人震驚的。
3. 卓越的設計人員。關鍵的問題是如何提升軟件行業的核心，一如既往的是人員。

　　在咱們的團隊項目中，咱們選擇了C#，以及統一了VS開發環境，在次要任務上保證了軟件開發效率，此外在主要任務方面咱們採用增量式的開發方式，在初步實踐獲得效果後，團隊成員都特別興奮，增長了對寫一個相對完善軟件的信心。

• Big Ball of Mud

　　大泥球是指一個隨意化的雜亂的結構化系統，只是代碼的堆砌和拼湊，每每會致使不少錯誤或者缺陷。

　　在我的項目中，曾經出現過部分函數功能類似只有少許功能不一樣，而後類似的功能直接採用代碼複製，不只致使代碼冗餘度大，並且產生了許多潛在的bug，好比有少部分數組下標忘記修改致使結果偶發性錯誤，並且前期設計不夠充分，以後使得系統愈來愈複雜，最終代碼寫了1000+，然而感受若是以前一個好的設計的話，代碼最多400行左右。歸納總結避免大泥球的方法以下：在軟件設計階段首先須要關注軟件的特性和功能，而後集中在架構和性能，使得軟件設計之初就避免產生問題或者方向的誤差。其次，在編寫軟件時要及時解決出現的小問題或者原型概念等等，這樣不會使得問題堆積致使後期的沒法修改。

• The Cathedral and the Bazaar

1. 大教堂模式（The Cathedral model）：源代碼在軟件發行後公開，但在軟件的每一個版本開發過程當中是由一個專屬的團隊所控管的。
2. 市集模式（The Bazaar model）：源代碼在開發過程當中即在互聯網上公開，供人檢視及開發。

　　大教堂模式的軟件開發讓程式除錯的時間大幅增長，由於只有少數的開發者可參與修改工做。市集模式則相反。

　　咱們的團隊項目採用的是大教堂模式，因爲咱們選用TFS進行代碼管理，在必定程度上決定了代碼只能屬於大教堂模式，這樣也就致使咱們的軟件在開發過程當中只能由開發人員來保證軟件質量，在必定程度上致使除錯時間的增長，在以後的軟件開發中能夠考慮將代碼由github進行管理，即時接受其餘開發者的檢視以及增量式開發。　

• A Generation Lost in the Bazaar

　　做者文中無情的揭示了集市模式致使的一個悲哀的現實：一坨膿包似的權宜代碼，被一羣盲目的根本不知IT架構爲什麼物的所謂IT「專業人士」永無休止地複製着，粘貼着。這事兒放在今天你也許很難相信，但就是在這使人無比尷尬的混沌之下，沉睡着美輪美奐的Unix大教堂的遺蹟，而Unix偏偏是以設計簡約、功能實用、執行優雅而著稱於世的。（世間榮耀就此消失……）咱們能夠精確地指出Unix開始走向碎片化的時間點：1990年代初，AT&T拋棄Unix，將其商業化，搶走其架構師的那一刻。參考：有人負責，纔有質量：寫給在集市中迷失的一代。

　　而做者認爲針對這一現象最有效的解決方式是：所謂質量，只有在某人對它負責時纔有意義，而這個「某人」只能是一我的，不能是幾我的——二重奏除外。個人理解是針對軟件的架構師必需要負責整個軟件的生命週期，由於，軟件的開發人員可能更迭，若是架構師不負責軟件的維護，那麼後續的開發人員對於軟件很難有一個良好的把控，只能不明因此地沿用前人的代碼，而沒法對於已通過時甚至錯誤的代碼作出適當的刪改，致使軟件的碎片化，以及文中指出的那樣對於早已過期的Fortan編譯器兼容性的檢測。

　　咱們的團隊項目採用增量式的方式進行開發，因爲以前學長沒有使用那些晦澀難懂的語法或者語言現象，咱們對於代碼都可以清楚地理解和把握，因此咱們在團隊開發中沒有遇到相似的問題。我認爲這是因爲軟件的規模所決定的，咱們的軟件規模跟Unix這樣的大型軟件規模是無法相提並論的，軟件的設計也只存在於開發者的頭腦中，不存在架構師，這種問題也就相應地沒有出現。

•  Waterfall Model

　　1970年WinSTon Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是惟一被普遍採用的軟件開發模型。 

　　瀑布模型將軟件生命週期劃分爲制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，而且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落，最終獲得軟件產品。

　　瀑布模型有如下優勢：

1. 爲項目提供了按階段劃分的檢查點。
2. 當前一階段完成後，只須要去關注後續階段。
3. 可在迭代模型中應用瀑布模型。增量迭代應用於瀑布模型。迭代1解決最大的問題。每次迭代產生一個可運行的版本,同時增長更多的功能。每次迭代必須通過質量和集成測試。
4. 它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法能夠在該模板下有一個共同的指導。

　　瀑布模型有如下缺點：

1. 各個階段的劃分徹底固定，階段之間產生大量的文檔，極大地增長了工做量。
2. 因爲開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增長了開發風險。
3. 經過過多的強制完成日期和里程碑來跟蹤各個項目階段。
4. 瀑布模型的突出缺點是不適應用戶需求的變化。

　　在咱們的團隊項目開發中採用的就是這種「瀑布模型」，因爲咱們的用戶需求相對固定，此外，瀑布模型給出了階段的劃分徹底可以適應咱們項目開發的模式需求，故而採用這種模式。

• Agile Methods

　　敏捷型方法的合理性，着重點並非放在其「輕重」上，而是於它們的適應性（adaptive〕性質和以人優先的理念。

　　多數軟件開發仍然是一個顯得混亂的活動，即典型的「邊寫邊改」 （code and fix〕。設計過程充斥着短時間的、即時的決定，而無完整的規劃。軟件行業中最初的一場運動是要改變這種狀況，而引入了「正規方法」 （methodology〕的概念。敏捷型方法（agile methodologies）的發展是對這些工程方法的反叛。

　　敏捷型與工程型方法有一些顯著的區別。其中一個顯而易見的不一樣反映在文檔上。敏捷型不是很面向文檔，對於一項任務，它們一般只要求儘量少的文檔。 從許多方面來看，它們更象是「面向源碼」（code-oriented〕。事實上，它們認爲最根本的文檔應該是源碼。

　　文檔減小僅僅是個表象，它其實反映的是兩個更深層的特色：

• 敏捷型方法是「適應性」而非「預見性」。 工程方法試圖對一個軟件開發項目在很長的時間跨度內做出詳細的計劃， 而後依計劃進行開發。這類方法在通常狀況下工做良好，但（需求、環境等）有變化時就不太靈了。所以它們本質上是拒絕變化的。而敏捷型方法則歡迎變化。其實，它們的目的就是成爲適應變化的過程，甚至能容許改變自身來適應變化。
• 敏捷型方法是「面向人」的(people-oriented) 而非「面向過程」的 (process-oriented)。 工程型方法的目標是定義一個過程，無論是誰用都工做。而敏捷型方法則認爲沒有任何過程能代替開發組的技能，過程起的做用是對開發組的工做提供支持。

　　不可預見過程的控制 － 迭代

　　對付一個不可預測的世界呢？最重要，也是最困難的是要隨時 知道咱們在開發中的情形處境，這須要一個誠實的反饋機制來不斷準確地告訴 咱們。這種機制的關鍵之點是「迭代式」（iterative〕開發方法。

　　雖然迭代式開發也可用於可見性環境，但它基本上仍是用做「適應性」 （adaptive〕過程,由於適應性過程能及時地對付需求變動。需求變動使得長期計劃是不穩定的，一個穩定的計劃只能是短時間的，這一般是一個「迭代週期」（iteration〕。迭代式開發能讓每一個迭代週期爲下面的開發計劃提供一個堅實的基礎。

　　一些敏捷開發的方法

• XP（Extreme Programming －－ 極限編程〕

　　XP始於五條基本價值觀（values）：交流，反饋，簡潔，勇氣和尊重（Communication, Feedback, Simplicity, courage, and Respect）。在此基礎上細化出了十四條原則（principles）和二十四條實踐法（practices）。其基本思想是： 實踐是項目組的平常的具體活動，而價值觀是根本性的知識和理念，其構成了該方法基石。沒有實踐法的價值觀是難於應用的，或失之於過於寬泛而不知從何着手。沒有價值觀的實踐法則是一堆雜亂無章的活動。價值觀和實踐法都是須要的， 但中間還有一個空檔－－而原則正是用來鏈接價值觀和實踐的。許多XP的實踐法都是之前就存在的並通過實踐檢驗的，而經常被許多過程，包括那些計劃型過程給忽略了。XP從新創建了這些準則，並把它們編織成了一個和諧的總體， 使得每一項準則都能在其餘準則裏得以強化。

　　XP有一個最具衝擊力的是它對測試的極端重視。誠然，全部的過程都提到測試，但通常都不怎麼強調。但是XP將測試做爲開發的基礎，要求每一個程序員寫一段源碼時都得寫相應的測試碼。這些測試片斷不斷地積累並被整合到系統中。這樣的過程會產生一個高度可靠的 建造平臺，爲進一步開發提供了良好的基礎。這種方法常被描述成 Test Driven Development(TDD)（測試驅動開發），它對許多不是徹底採用XP的方法都有很大的影響。

• SCRUM

　　SCRUM的着重點是在軟件開發的管理方面。它把一個項目分紅若干個爲期三十天的迭代階段，每一階段稱之爲一「衝」（sprint〕。天天有一個短會， 稱之爲一個scrum，這樣管理者能對項目有近距離的觀察與控制。SCRUM對工程實踐方面強調少一些，許多人在開發中把SCRUM的項目管理和XP的工程實踐相結合。

• 水晶（Crystal）系列

　　全部水晶方法都有三個需考慮的優先因素（priorities）：安全性（safety） （項目的結果），效率（efficiency），和習慣性（habitability）（即開發人員 多大程度上願意使用水晶方法）。其餘共同特徵有：頻繁發佈，反思改進，緊密交流 （Frequent Delivery,Reflective Improvement, and Close Communication）。

• 相關環境驅動測試（Context Driven Testing）

　　敏捷開發運動最初是由軟件開發人員來推進的。可是，參與軟件開發的其餘方面 的一些人士也受到這個運動的影響。一個明顯的羣體是測試人員，他們一般是生活 在由瀑布式開發所限定的世界裏。通常來講，測試的做用是保證軟件與開始的設計 相符合。而在敏捷世界裏，測試人員的角色還很不清楚。這致使了一個稱之爲「相關環境測試」（context driven testing）的羣體。

• Lean Development（精悍開發）

　　Lean movement（精悍生產運動）是由豐田公司（Toyta）Taiichi Ohno獨創，並以 豐田生產系統（Toyota Production System）著稱。精悍生產的理念對許多早期的 敏捷論者多有啓發。

• （Rational）Unified Process

　　RUP最主要的特徵是用例驅動開發（Use Case Driven）（即，開發是以用戶可見 的系統功能特徵來驅動的），迭代，和以架構爲中心（須要優先考慮的一點是， 儘早設計出一個架構以貫穿項目始終）。

　　在咱們的團隊項目中，對於需求變化以及其餘的不可預見性採用了迭代的方式進行予以適應性的變化，採用的敏捷開發方式是scrum，總共進行了兩次爲期兩週的衝刺。團隊編程中也使用部分極限編程的思想。其中最重要的就是交流和反饋思想的使用，這使得在團隊成員之間規避了許多理解上的分歧，從而少走了許多彎路。