[buaa-SE-2017]我的做業-期末總結

我的做業-期末總結

Part1: 閱讀做業

在這一部分，首先我將說說我對此次閱讀做業中每篇文章的理解，最後結合此次團隊項目的經理談談本身對軟件開發的見解。

1. No Silver Bullet

文章連接：No Silver Bullet
這篇文章我感觸最深的仍是做者在第一部分提到的，軟件的4個本質性困難。

1.1 Conformity

不一樣組件之間的接口須要嚴格遵照，這就是說使用者必須學習全部接口的規格。這個問題最好的解決方法應該是對軟件的接口有一個統一的規定，可是這基本是不可能的，寫程序就像說話，你不可能讓全部人表達同一種意思的時候都用同一句話。

1.2 Invisibility

在我看來這是軟件一個最本質的特徵，它致使咱們只能以線性的方式去觀察或者構建一個程序，但咱們構建的程序的複雜度是以指數級增加的；另外一方面，不可見性還會致使程序中概念的冗餘，這種狀況普遍發生，它就好像你在組裝一個機器的時候放進去不少多餘的螺絲，若是是這種狀況你必定能夠很快發現，可是在寫程序的時候要發現就沒那麼容易。這種狀況會發生的根本緣由一是因爲程序構建的自由性；二是在這基礎上因爲其不可見性致使的程序員對程序中概念理解上的障礙。

1.3 Complexity

上面也提到了，程序的複雜度會隨着程序代碼或者組件數量以指數級增加（固然這取決於程序的結構，但通常來講它是圖而不是鏈），而程序代碼和組件數量卻不可能以指數級增加。我的認爲這個難點並非一個專屬於軟件的特徵，而是屬於任意一個系統的，同時複雜度也能經過一些手段去控制，好比組件內部的高聚合，組件之間的低耦合。

1.4 Changeability

In short, the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their
changes inexorably force change upon the software product.

上面的引用很好地說明了使得軟件具備changeability的因素，嚴格來講這是由外部因素致使的性質，不過實際上咱們根本沒法避開這些因素去運行一個軟件。對於一個面向過程的程序，這個性質更加明顯，由於程序是以過程流的形式運行的，因此很是容易受到環境和需求的影響。

1.5 其餘

這篇文章中也提到了過去在軟件開發中的一些突破，好比高級程序設計語言、分時系統和統一開發環境，但這些都沒有解決軟件開發的本質性困難；
同時做者也對一些可能的"silver bullet"作了分析，他本人持一個悲觀的態度，認爲這些技術並不能解決這些困難，其中包括Graphical programming以及Automatic programming等，這些技術在如今看來也有不少確實是沒法從根本上解決問題的，可是咱們也沒法肯定像AI,Automatic programming這樣的技術在未來不會有什麼重大的突破。

2. There is a silver bullet

文章連接：There is a silver bullet
在這篇文章中做者的核心觀點是應用面向對象的方式製造可複用的組件能夠解決軟件開發的困難。
面向對象確實是構建程序思惟的一種變革：

It means changing how we view software, shifting our emphasis to the objects we build rather than the processes we use to build them.
It means using all available tools, from COBOL to Smalltalk and beyond, to make software as tangible--and as amenable to common-sense manipulation--> as are the everyday objects in a department store.

上面這段話很好地解釋了OO是如何在某種程度上解決軟件的Invisibility和changeability的，之前過程式程序時的程序流在某種程度上轉變成了代碼中存在的實體，繼承能夠更快更好地構建對象，多態則能夠應對Comfomity，一些以前沒法解決的問題彷佛都有了解決方法，不過做者也說明了面向對象面臨的一些挑戰：

However, this study has also revealed how difficult it still is, even with state-of-the-art object-oriented technologies, to design and build components that > are both useful and genuinely reusable, to document their interfaces so that consumers can understand them, to port them to an unceasing torrent of new > hardware platforms, to ensure that recent enhancements or ports haven't violated some preexisting interface......

這裏困難體如今兩方面，一是咱們既須要讓代碼知足需求，同時也要讓它們有複用性，知足需求就不能太抽象，有複用性則要抽象；二是移植性和對環境依賴的矛盾，這個問題如今看來依然存在，不過java的跨平臺性應該說在必定程度上解決了這個問題。

我的認爲OO確實解決了不少問題，也加速了軟件的開發過程，不過那4個本質性困難仍然是存在的。

3. Big Ball of Mud

文章連接：Big Ball of Mud
提及來比較慚愧，因爲時間關係我沒有看完整篇文章，僅僅對文章提出的一些概念和結論作了概括，若是有錯誤歡迎指正。

3.1 big ball of mud

A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems > show unmistakable signs of unregulated growth, and repeated, expedient repair.

簡而言之，大泥球就是指一個結構混亂不堪，代碼邏輯混亂的系統，這種系統常常須要不停地維護。

Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global > or duplicated. The overall structure of the system may never have been well defined.

大泥球系統中信息的交互是混亂的，距離很遠的組件也可能有信息交互，這就形成系統的複雜度增大。系統中的代碼彷佛沒有考慮過二次使用，使用一次後就丟棄，從觀察者的角度看這種作法的確很不明智，然而，這種現象是常常發生的，甚至我自身也有這種狀況（不少做業都是這樣，代碼也許只用一次，出現問題的時候最省力的方法就是因引入一些dirty code，而且它是有效的，即使它會產生一些問題，因此爲何不用呢？）。這種dirty code會侵蝕(erode)原有的健康的系統架構，致使咱們繼續用dirty code去修復前面的dirty code產生的bug，造成一個惡性循環，最終一個大泥球就產生了。

不少因素會致使這樣的系統產生——時間、成本、技巧，甚至軟件自己的特質也妨礙到咱們對一個健康架構的系統的構建，軟件的線性特徵會妨礙到咱們觀察總體的結構，軟件的靈活性(我是說，即使是一個壞的設計，一般你也能夠修復)一樣也會致使這個問題。

3.2 shearing layer

這裏做者提出了軟件須要具有的兩個性質：適應性(Adaptability)和穩定性(Stability)，前者是說軟件應該能夠應對各類各樣不一樣的需求，然後者則是說軟件中已經穩定的部分不該該被輕易更改，很容易就能注意到這兩個性質是有內在的衝突的：

Adaptability and Stability are forces that are in constant tension. On one hand, systems must be able to confront novelty without blinking. On the other,
they should not squander their patrimony on spur of the moment misadventures.

做者這裏用房屋來作了類比：

從外到內有6個層次，這些層次的變化速率是徹底不同的，好比內部的陳設可能幾天就會變一次，可是房屋的地點倒是不會改變的，相鄰層次之間的變化速率差異是相似的，房屋能具備適應性和穩定性正是由於有這樣的結構。

因此說shearing layer就是說咱們應該讓系統中相鄰層次之間有相似的變化率。

3.3 refactoring

我的理解重構是隨着軟件的複雜度增加而不可避免要發生的事情，一個結構必然有它能知足功能的上限，超過這個上限結構就沒法完美支持功能，這個時候程序可能變得沒法修復甚至沒法理解，那麼咱們就須要重構。

固然，雖然重構沒法避免，但在一開始咱們仍然須要謹慎對待設計，同時也應該作好重構以後的迴歸測試。

4. Cathedral and the Bazaar

文章連接：
[1] The Cathedral and the Bazaar
[2] A Generation Lost in the Bazaar

教堂和集市在這裏是指兩種自由軟件開發的模型，前者是指軟件在版本迭代過程當中，雖然每次都公開發布時候的代碼，但在兩次發佈之間的開發時期，新修改的代碼只對開發者開放；集市模型和教堂模型相反，是指任意時期的代碼均對外公開。
第一篇文章做者的核心觀點是，當軟件有更多的人去測試，它的bug就會越快地被發現，這確實是集市模型下的一個明顯的優勢，同時在這個模型中，用戶也成了軟件的開發者，這樣能夠在軟件的開發過程當中引入集體智慧；可是從另外一方面來講，這種作法的缺點也是很明顯的（具體能夠參看第2篇文章），非專業人士參與到開發中會很容易侵蝕原有軟件的健康架構，爲了防止這種狀況出現，必定須要專業人士對新增代碼的檢查。
只要能保證代碼的質量，更多人蔘與到開發中必定是益處大於壞處的。

5. 瀑布模型

文章連接：water fall

瀑布模型是一種計劃驅動的開發模型，它有完整嚴密的計劃以及步驟之間的回溯：

瀑布模型在《構建之法》裏已經有了比較詳細的解釋，這裏就不贅述了。這個模型很適合大型的而且有嚴格要求的軟件的開發，而且開發出的軟件會有較高的質量，不過，任何模型都有它適用的範圍，這個模型的週期很長，在需求變化快的商業環境下顯得有些笨重，這個時候敏捷開發的靈活性就體現了它的優點。

6. 敏捷

文章連接：
[1]Agile Mehod
[2]敏捷已死
[3]The Corruption of Agile
[4]In defense of Agile

我的理解敏捷是順應如今軟件需求變化快、競爭激烈狀況下順勢發展出的一套價值觀和方法論，敏捷開發但願更快地交付軟件以知足需求，它是一種需求導向的模型，因此它在某種程度上捨棄了嚴謹地計劃，可是它並非一通亂作，它也有一些固定的流程，好比產品規劃、Sprint backlog、Sprint以及Scrum，能夠說這些流程都是爲了能更快更好地開發軟件而設計的，敏捷流程在教材中也有詳細解釋，這裏也很少說了。
這學期的團隊項目也採用了敏捷開發流程，這個過程當中確實能體會到scrum中面對面交流帶來的即時反饋對軟件開發帶來的幫助，不過在這個過程當中感受最重要的是隊友之間的互相配合，若是隊友懶惰推卸責任，那麼有再好的方法和模型也是無濟於事的，萬幸的是個人隊友都很是可靠（這裏要表達對他們的感謝），使得咱們的開發流程比較順利（敏捷）。

7. 軟件開發的方法論有用嗎？

文章連接：Why Software Development Methodologies Suck

做者在這篇文章中提出了兩個通用的原則來判斷一個實踐是好是壞，是否能幫助咱們提高軟件的價值：減小開發週期和增長反饋
同時做者認爲最終軟件的總體質量仍是須要依靠開發者自己的能力的，同時因爲軟件開發的不肯定性使得技能的學習變得困難，創建一個有強大學習能力和適應能力的團隊就顯得很是重要；做者也認爲一些創建在不可控項目上的對軟件方法論的實踐是經不起推敲的，這些思想和方法每每不是最重要的。

在上一節我也提到了，我確實從敏捷開發流程中體會到了它的益處，我想若是沒有天天的scrum，那麼開發進度必定會減緩，因此我的認爲軟件開發的方法論都是前人總結的寶貴經驗，也是他們留給咱們的寶貴財富，有能力強的開發人員雖然也很重要，可是若是沒有一個系統而且嚴謹的方法論來指導，一樣也是沒法取得好的效果的。

Part2: 期末總結

2.1 收穫和感想

這個學期軟工的幾個項目中，最重要而且收穫最多的就是團隊項目了，整體來講咱們在開發的過程當中並無遇到太大的阻力，α階段基本把能踩的坑都踩完了，以後的β階段你們都顯得比較輕鬆，而且大部分的精力都投入在編譯上。

咱們搭建網站選用了Vue+Django的組合，實現了先後端的分離，總體項目的結構中，信息流向很清晰，也很容易把握，負責每一個部分的人只須要作好本身部分的內容，先後端交互以及和數據庫的交互也只須要一些學習就能夠解決。

能這麼順利仍是要歸功於靠得住的隊友以及很負責的PM，在這裏再次表達對他們的感謝。我想在團隊項目中我學到的不只是軟件開發過程的思想和方法，更重要的是學習如何在團隊中交流並和其餘人配合。

固然說到收穫也少不了一些和web開發相關的技術，以及我的項目中學到的C++和Qt，同時還有一個爬取教務的程序和用這個程序爬到的一大堆課程信息。

2.2 反思和反省

說完收穫也須要檢討和反省一下本身，首先是此次團隊項目前端的代碼寫的並不優雅，甚至有點笨重，因爲這是我第一次進行完整的web開發，在α階段寫了不少如今看起來不須要的dirty code，雖然在β階段的代碼中進行了必定的改進，可是已經寫完的代碼就沒有時間和精力來重構了，這也是此次項目中讓我比較遺憾的一件事，但願下次有機會能作的更好。