軟件工程——我的總結

軟件工程­——我的總結

回想開學初對於軟件工程這門課的指望，總結本課程對你帶來的提高：

1. 學習和使用的新軟件

MySQL，用於數據庫實現方面的嘗試。

xampp進行後臺虛擬網站的運行和網站進行修復。

mockplus工具進行原型界面設計，後續界面用代碼進行實現。

2. 學習和使用的新工具

學習使用在coding上，存放代碼，共享代碼。

git創建倉庫，以及利用git倉庫進行代碼上傳。

3. 學習和掌握的新語言、新平臺

博客園：一個面向大衆的知識分享平臺。

Git:如何創建git倉庫以及在本身的倉庫中如何上傳代碼。

經過PHP搭建一個初始網站。

4. 統計一下，你在這軟件工程實踐中，完成了多少行的代碼

此次的軟工做業中完成了較少的代碼。

5. 學習和掌握的新方法

學習的新方法：數據庫的鏈接與基本操做，軟件測試和後端的編寫方法。

此外最重要的就是結對編程的好處。

二 總結和展望

1. 記錄本身在軟件工程課程上的經驗總結

在軟件工程團隊項目中咱們要善於交流，積極表達本身的想法，有時候別人以爲很容易的東西到本身手裏的時候卻發現根本無法解決，這時團隊就是一很好的交流平臺。總而言之，在這此團隊項目過程當中遇到的問題以及解決的辦法也讓我受益不淺，我明白了團隊分工與合做協調的重要性。編程過程當中本身有不規範的地方也通過合做夥伴的提示獲得了規範，也深入明白了取長補短的益處。

二、對學弟學妹的建議及告知

學弟學妹要切記在決定作什麼項目以前大家必定要合理的衡量自身；決定作什麼項目以後儘可能早早的開始並強迫本身完成天天的任務量，這樣既能保證進度又不致在後期倍感時間的緊迫。也能夠在作項目的過程當中對不會作的部分多加嘗試。

3 分析本身的團隊

咱們的項目是個商品比價系統，在項目的完成過程當中咱們的分工很明確，都是由組長分配好，而後咱們各自執行好本身的任務，這樣的前提是咱們都有着足夠的執行力。雖然作起來時間很趕，但最終咱們仍是完成了這個項目。不得不說團隊的每一個人心中都是很欣慰的。

4 個性發揮

此次的團隊項目協做過程當中我學到了不少，收穫很大。

1. 在一週以內快速看完《構建之法》，列出你不懂的5-10個問題，發佈在本身的博客。

• 如何作好敏捷流程？         （ 第六章  敏捷流程）

   我在軟件工程第六章6.3 敏捷的團隊的113頁上我看到了這樣一段文字「若是你的團隊很弱，那麼強行把敏捷（或者其餘高級方法）套在上面也沒用，也許還會拔苗助長，每每須要經歷屢次失敗/總結/改進的過程才能讓Scrum走上正軌。換句話說，若是你的團隊已經有這麼厲害（自主管理。自我組織，多功能型）的一幫人，那麼用不用Scrum都能寫好軟件！」提出問題（作敏捷流程的開發是要有必定的軟件開發能力的人員才能完成嗎？）

答：敏捷流程是一種軟件開發，它會指導咱們的團隊用規定的時間去完成項目，作這種開發軟件的核心是人，因此毋庸置疑咱們的團隊要有必定的基礎才能完成本身所向往的項目，若是團隊的綜合能力或基礎太過薄弱的話用敏捷流程作開發不但會出現這樣那樣的問題並且效率還不高，與其這樣還不如不作，歸根節低用敏捷流程作開發要有必定的基礎才能完成。 

• 在軟件測試時須要覆蓋全部的代碼段嗎？    （第二章  我的技術和流程）

         我在軟件工程第二章27頁單元測試應該覆蓋全部代碼路徑下面有這麼一段話「單元測試應覆蓋所測單元的全部代碼路徑，包括錯誤處理路徑。而下面有段是100%的代碼覆蓋率並不等同於100%的正確性！」  提出問提（軟件測試時是否須要覆蓋全部的代碼，覆蓋後的代碼是否100%正確）

答：軟件測試時代碼須要覆蓋全部的代碼，旦這樣並不表明覆蓋後的代碼是百分百的正確。如代碼申請了內存或其餘資源，但又沒有釋放等。

•  「團隊精神」和日常的「集體主義」有什麼區別呢？     （第五章   團隊和流程） 

        我在軟件工程第五章102頁（你們在回想小學和中學的學習過程，你們在一個班集體，有多少工做是以「團隊」的形式來完成的，有多少工做是以「工做組」形式完成的，或許大部分工做都是以「非團隊」形式完成的），提出問題（「團隊精神」和日常講的「集體主義"有什麼區別？）

答：你們在回想小學和中學的學習過程，你們在一個班集體，有多少工做是以「團隊」的形式來完成的，有多少工做是以「工做組」形式完成的，或許大部分工做都是以「非團隊」形式完成的，集體和團隊都是由兩個或兩個以上的人組成，團隊精神和集體主義從本質上都是調節我的和他人、我的和羣體關係的思想。

• 工程師完成代碼後還有許多BUG，怎樣解決這些BUG呢？   （第十一章    軟件設計與實現）

          參考書中第十一章230頁，看完代碼完成那一段落以後，我明白了原來代碼雖然寫完了，但仍是有不少BUG，書中沒有介紹怎樣處理這些BUG。提出問題（怎樣解決這些BUG？）

答：咱們寫代碼後遇到bug是很正常的事，然而怎樣解決纔是硬道理，一旦遇到BUG咱們要積極的去找錯處，或者去問一些比本身對編程好的同窗或問老師。有時咱們遇到BUG就意味沮喪，鬱悶，甚至泄氣這樣不但不能解決問題，然而會把本身弄的一團糟。因此不管作什麼心平氣和最重要。

•   兩人合做中的代碼複審到底看的是什麼？    第四章  （兩人合做）

    在軟件工程第四章69頁看到代碼複審的定義是：看代碼是否在「代碼規範」的框架內正確的解決了問題。看完這段定義。   提出問題（我仍是不太明白代碼複審到底看的是什麼？）

答：代碼複審看的是團隊工程的代碼，並且代碼複審是程序開發完後必需要作的事，在軟件工程中最基本的複審手段就是同伴複審。代碼複審的能夠有效地找出代碼錯處看好比不符合團隊代碼規範的地方，發現須要改進的地方等。代碼複審能有效的幫助新成員瞭解團隊的開發策略以及工程的編碼風格和工做流程。