2014-軟體工程基礎-總結

本學期接近尾聲，軟體工程的課程也到了末尾，在此做一下總結。總結中可能涉及到其他課程，未必僅限于軟體工程。

 第一部分：連結到以前的部落格，進行現在的體會的分析和說明：

個人項目：http://www.cnblogs.com/hks1994/p/3991963.html

第一次的個人項目，現在看來，其實還是有難度的，當時應該也是花了很多功夫，不過當時雖然時間緊張，但是事情不多，是以還是可以專心的做軟工。不得不說，當時是非常幸運地了解到了c#中的dictionary類，否則，要麼在資料結構的選擇中糾結，要麼在連結清單的使用中備受煎熬，不僅程式會變得難寫，出來的結果也不會太好。其實也是一種機遇，當然也是積累的結果，有一定的必然性。與他人相比，資料結構方面我無疑占了很多的優勢，與使用連結清單的同學相比，我的程式的運作時間是秒級，而他們的是小時級，這充分說明了資料結構的重要性。

閱讀代碼大全體會小結：http://www.cnblogs.com/hks1994/p/4025345.html

這應該是第一次閱讀作業了。當時聽到要看這麼大的一本書時很是驚訝，後來才發現，其實基本的思路，基本的東西就是那幾塊，精髓并不是太多。

将函數分割為子程式，将類中定義的方法分開，方法之間，類之間的耦合度需要降低，這是面向對象課程上老師多次強調的東西。現在想來，面向對象課當時看起來那麼蛋疼煩人，現在看來講的東西雖然抽象但是還是很有道理，是很有幫助的思想。之前寫java程式的時候，雖然寫到了上千行，但是我仍然不想把函數和類給分開，因為分開顯得太麻煩，有的時候函數長，代碼量大，執行的速度不一定慢。這一句話我現在依然比較相信，不過，子程式的重要性我已經深刻地體會到了，主要來自兩個事件。第一個是軟體工程團隊項目的第一個階段。在團隊項目的alpha階段，我當時還認為任務量并不大，這無非是一個比較簡單，功能比較基礎的安卓應用而已。後來在開發的過程中才了解到，實際的開發比想象的要難得多，自己的力量其實很有限，這一點在資料庫大作業、編譯器實作和ruby大作業中也有體會。當時我弄一個搜尋的部分就花費了很多的精力，更不用說其他的隊員，有一個花了一周的時間，每天都在死磕檔案的上傳下載下傳，另一些着眼于繁雜的界面設計和經受着各種崩潰的考研。而這些東西，如果都寫在一個方法裡，寫在一個類裡，你能想象嗎，那對于維護将是非常可怕的。就拿搜尋來說，搜尋處理分不同的内容進行搜尋，具體對使用者的輸入進行分解處理，然後再搜尋，搜尋後再整理搜尋結果，将結果高亮，在界面上輸出，同時還要做好頁面的跳轉，另一方面還要考慮到在android4.0中出現的新規定對項目開發帶來的影響，比如說在主程式中不允許使用handleMessage消息循環，必須在子線程中進行，而涉及到多線程，一般都不會太容易解決。将這些複雜的東西分開，有利于理清楚自己的思路，也便于測試盒修改。雖然我一直很讨厭單元測試，因為他很繁雜，測試程式也不好寫，但是在實際中往往不自覺地就是用了瀑布模型的開發方式，對單個子產品進行不斷地疊代測試，确認無誤了才敢放心地進行接下來的開發。又說編譯系統，編譯器是一個非常典型的，必須采用子程式分割法的開發過程。如果你不把編譯器的設計分為詞法分析、文法分析、語義分析、代碼優化、代碼生成幾個部分，那你真的能夠想象程式構思和編寫的複雜度嗎，以及一個部分出問題對于整體的影響麼。程式出錯的時候，有的時候你的子程式分割不開，錯誤都無法準确判斷在哪裡出現，這又應該怎樣去解決呢？總而言之，代碼分割，子程式的使用，确實是非常重要的，不管是在遞歸和循環中，還是在普通的基本塊中。

 對于全局變量的使用，其實我個人已經高度認可全局變量了。現在經曆了用java、c#和c++進行開發，不得不說，類的概念非常重要，沒有類的程式，在我看來無法想象。在類中，各個函數之間對于類變量的共享是非常友善的，尤其是在大型的程式當中，比如說編譯程式中，各個部分，各種語句成分的分析，各種分析函數對于變量值的共享，而類變量無疑提供了很好的通路方式。但是顯然，這樣大規模的共同通路很容易出問題，這裡還不考慮多線程的問題，而是資料不一緻的問題。代碼量一大，程式就變得難以控制，有的時候一個變量複用好幾十次上百次，你查都查不過來，而實際調試的時候費盡心力才發現是某一個地方少寫了一個加号，或者少運算了一次，這些都是非常常見的，并且非常讓人無奈的。

關于類的封裝，現在還是沒有什麼更加深刻的體會，大概是因為沒有什麼特别需求private的地方吧，是以也就随便寫随便用了。不過有一點收獲很大：頭檔案的定義作用。以前沒寫過c++，這一次編譯寫了c++，發現頭檔案的作用還是非常大的。将類的定義放在頭檔案中，在cpp檔案中實作類中的方法。這樣檢視類的定義友善，檢視每個函數的具體内容也比較友善，自己兩個檔案（頭檔案和實作檔案）對照起來看，程式的（類的）結構也比較清楚明白。在軟體工程第二次結對項目中，編寫電梯時，當時也在c#中強制使用了已有的接口進行定義與實作。這大概就是定義和實作分開的思想吧。這種思想也挺好的，之前沒有體會到。

至于類的組合與繼承，現在從來不用繼承，至于類的組合，也就是類作為其他類的成員而存在。如果作為局部變量而存在，所耗費的棧空間無疑非常大，是不可忍受的，是以一般将這些類的指針作為參數傳進來，一個類儲存其他類對象的指針，指向堆空間中的其他對象。這樣看起來是很好的，不過最近遇到的一個問題就是，在c++中，delete這些對象時，由于指針重複引用，delete一個之後，另一個對象還包含已被delete的指針的内容，再次delete，就會導緻程式崩潰結束。也就是說，類的重複引用，或者是指針空間的重複，導緻已經被delete的空間再次被delete而是程式出現運作時錯誤而崩潰。對于表驅動法，雖然沒用過，但是其實在編譯器設計中，對于switch語句的分析，與表驅動法有異曲同工之妙。在switch語句的分析當中，借鑒gcc的分析方式，将一個switch語句内所有的case語句後的常量收集在集合中，進行排序，然後進行二分查找，也就是利用折半查找來進行case語句的比對進而實作跳轉，不得不說，這是簡單而又便利的思考方式，是對傳統和簡單資料結構的活用。

經過現在一段時間的程式設計，會發現複雜的資料結構，例如格式各樣的樹和圖，除了他們的特殊功能（例如紅黑樹和B+樹等），都可以用更加簡單的資料結構進行替代。樹和圖都可以用多重數組來代替，由于在進階語言中動态數組的出現，再加上資料庫中關系模式二維表的提出，表結構（實際就是多元數組）扮演着越來越重要的作用。隻要空間足夠，完全可以利用多元哈希表進行表建構，由于哈希表高效的查詢效果，這樣進行查詢，可能比樹和圖嗨喲啊更加簡便。根據問題選擇适合的資料結構，敢于使用多樣化的資料結構，将各種資料結構進行比較，通過實踐找出目前問題對應的最佳的資料結構，是今後一直需要做的重要工作。

軟體工程結對項目：http://www.cnblogs.com/hks1994/p/4034028.html

結對項目附加：http://www.cnblogs.com/hks1994/p/4034036.html

雖然上一次個人項目比較成功，但是這一次結對項目回望起來比較失敗，而且現在回望那時的表現，仿佛就決定了會有那樣的結果，以及決定了如今的窘境。

我是相信命運的，或者這樣，上天以及定好了劇本，你做出不同的選擇，就會出現的不同的劇情走向，這些有的已經決定好，有的是動态決定的，因為他人也在變化，就像編譯時系統和運作時系統一樣。是以，那時的失敗，就決定了我今日會失敗。在現在這個節骨眼上，隻有兩三天的時間了還有三門大作業，一門考試和答辯。我這一學期的資料庫大作業、編譯課大作業、ruby大作業、軟體工程都比較失敗，其中前三個的情況簡直慘不忍睹。原因說白了就是：心太大，但是自己沒有配置設定好時間。我一直知道自己是感性的人，而時至今日我才知道我是一個理想主義者，具體表現為我認為很多事情我都可以實作，哪怕隻剩一天了，我也認為我能做得完。再加上我對品質的高要求，是以就很有可能導緻中途夭折而影響到最後的結果。大二上學期有一門計算機組成原理實驗課，當時做的不錯，大二下學期的作業系統實驗做的也不錯，現在想來可能是因為當時大作業少，是以有精力弄。而像這一個學期，最後的階段，大作業大概畢竟十個，而且其中的軟體工程課的團隊項目還分兩個階段，而第一個階段花費了那麼多的時間以至于整個人大概有三四個月以來的作息都是混亂的，自己的身體和心情都變得很糟，就認為自己是能做到的，但是就是沒時間做了，真的是太遺憾了。這些東西确實是難，但也并不是做不到的。這麼多大作業的糟糕的完成情況無疑給了我很大的打擊，讓我開始思考時間配置設定的重要性，以及對自身實力的正确估計，加上問題分析和計劃制定的重要性。這些東西遲早是要考慮的，而如果到了後面才考慮，那麼就可能因為來不及而沒有什麼補救辦法了。是以，時間配置設定一定要做好，事前不管是否詳細，一定要做計劃，心裡要有一些數，明确問題的主要沖突和任務目标的需求重點，合理配置設定時間，達到最優的效果，也就是以完成目标為第一，具體的優化和其他細節不能糾纏不放，計劃始終是要想的，想不明白就容易白白耽誤時間，而同時卻沒有做什麼，影響身體和心情。

代碼複審：http://www.cnblogs.com/hks1994/p/4046913.html