我的做業——軟件工程實踐總結

• 課程名稱：軟件工程1916|W（福州大學）
• 做業要求：我的做業——軟件工程實踐總結做業
• 學號： 221600131
• 做業目標：軟工實踐總結

做業正文

1、請回望暑假時的第一次做業，你對於軟件工程課程的想象

1）對比開篇博客你對課程目標和期待，「但願經過實踐鍛鍊，加強計算機專業的能力和就業競爭力」，對比目前的所學所練所得，在哪些方面達到了你的期待和目標，哪些方面還存在哪些不足，爲何？

"課程實現目標： 但願能從業界的工程師助教那裏學到實際項目的開發模式，嘗試一些以前沒學過的新技術。"

• 這是我在準備篇博客寫下的對軟工實踐課程的目標與期待。而我確實在這門課的過程當中查閱學習了不少業界流行的開發規範和開發工具注入整個團隊項目之中，提升了團隊的配合開發效率。而且我深刻學習了以前只是淺嘗輒止的Vue框架，最終帶領團隊開發了組件化開發的單網頁富應用web。
• 不足的是其實我更想寫後端，由於我有點完美主義寫前端會一直調樣式，樣式優化是很費時間的。而且我以後並不許備從事前端開發，後端開發其實更有助於從此的發展。可是團隊裏缺少擅長前端的隊員，UI對官網又尤其重要，所以身爲隊長只能擔下這個責任從新去看Vue文檔學習。

2）總結這門課程的實踐總結和給你帶來的提高，包括如下內容：

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

• 咱們的團隊項目前端總共包含了133個.vue文件（不算外部css和js文件），由於客戶端還作了對900-1440px與900px如下寬度的兩版css適配，因此客戶端展現部分的.vue文件的css代碼都是1500行起步。保守估計就團隊項目部分我應該至少完成3.5w行的代碼。

  二、軟工實踐的各次做業分別花了多少時間？（作一個列表）

  做業名稱	時間
  第一次做業-準備篇	2
  結對做業第一次—原型設計（文獻摘要熱詞統計）	8
  結對做業第二次—文獻摘要熱詞統計及進階需求	6
  團隊做業第一次—團隊展現	2
  團隊做業第二次—項目選題報告	6
  團隊做業第三次-項目原型設計	20
  團隊做業第四次-項目需求分析	6
  團隊做業第五次—項目系統設計與數據庫設計	8
  團隊做業第六次—團隊Github實戰訓練	8
  項目Alpha衝刺（團隊）	40
  過後諸葛亮（團隊）	2
  項目Beta衝刺（團隊）	70
  Beta階段團隊項目互評	1
  我的做業——軟件工程實踐總結做業	2

  三、哪一次做業讓你印象最深入？爲何？

• Beta衝刺做業。由於短期內工做量巨大，儘管面臨了期末複習、比賽、srtp結題、論文撰寫等多重壓力，仍是將其它暫時擱置專心beta衝刺。

  四、累計花了多少個小時在軟工實踐上？平均每週花多少個小時？

• 根據第2個問題的表格統計花費總時間爲181小時。按13周計算每週花14小時。

  五、學習和使用的新軟件和新工具；

• 原型設計： 墨刀
• 單元測試：easy-mock、SwaggerUI
• 版本管理： Gitlab搭建

• 代碼規範： ESlint

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

• 前端框架: Vue

  七、學習和掌握的新方法；

• 快速搭建單網頁富應用web app
• 自動化測試

• 團隊配合的git規範

  八、其餘方面的提高。

• 團隊領導能力，協做溝通能力。
• 對軟件項目開發的把控能力。
• 多任務並行處理能力及抗壓能力。

• 寫博客總結學習知識

  2、寫下屬於本身的人月神話——我的或結對或團隊項目實踐中的經驗總結+實例/例證結合的分析

• 一我的或兩我的開發的時候可能不會注意太多，可是多人一塊兒參與開發的時候就要注重不少以前沒有注意到的問題。例如代碼規範、版本管理、變動管理等項目管理控制的問題。若是在項目前期沒有預防，制定好計劃，等項目中期可能會消耗大量的時間去調整已寫好的代碼。
• 例如儘管項目開始前做業含有一項制定代碼規範，但到實際開發中很難記得清都有哪些約束。而若是你們都爲所欲爲，最後整合起來的代碼必定是風格迥異，閱讀性差。所以我在前端使用ESlint寫好代碼規範的腳本，若不遵循規範則會報錯並指引錯誤位置，作到了代碼規範的統一。

• 最後很開心帶領團隊中有四人得到了小黃衫。

3、對下一屆實踐的建議，或者對於開學初的你，對於大一的你，對於開學初的我，你有什麼想建議和告知的呢？對於後來人的期許。 特別地，特別地，下一屆要不要中途換隊員？

• 首先是關於課程調整的建議，固然我知道這個得跟學院溝通，實現難度很大，不行的話就看成吐槽吧。第一點建議課程時間能夠放在前面的學期。在當前升學率逐漸升高的背景下，大三下同窗們的狀況都是保研的準備夏令營，考研準備考研複習，留學的備戰雅思託福GRE等。雖然咱們都知道多學多得，對本身絕沒有壞處。但在大三下這個關鍵節點每每還要考慮優先級的關係，短期內什麼是最有必要的選擇。另外一方面若是學生能較早地通過完整項目實踐的洗禮，到了大三其實會更清楚地知道本身的不足和興趣方向在哪裏，進而去有針對地發展。第二點是能夠提升軟工實踐的學分。這個工做量巨大的課程只有1.5學分，不免有些人會「戰略性」划水，優先保證其它學分更高的課程。這樣沒法達到軟工實踐的目的。
• 關於課程開展的建議，我認爲助教能夠在開發過程中多進行一些技術指導。若是一個團隊中沒有人完整接觸過項目開發，本身短期摸索出來的做品是很難達到要求的。可能表面看起來能跑，但根本經不起測試，更不用談及功能的拓展和維護。相對而言，若是在有人引導下經歷一段規範的開發流程，短期內的提高會更大。而需求分析、軟件設計、測試等環節在理論課都已經詳細介紹，基本不會出現一籌莫展的狀況。

• 關於換隊友的建議其實我以前在羣裏提過。換隊友能夠模擬企業宣講、招聘、面試這樣的流程。每一個團隊上臺介紹他們的開發項目和招聘崗位（可能前期組隊過程當中沒有考慮到須要某個位置的隊員），讓其它全部團隊都至少出一人來投遞簡歷面試。最後進行一個雙向選擇的過程。這樣雙方自願，才能更好地繼續接下來的工做，也更大程度地模擬了現實場景。特別是還能給某些不知足於所在團隊現狀的人一個跳槽的機會。隨機分配就可能會出現想走的走不了，不想走的依依不捨的狀況。

  4、分析一下本身所處的團隊。軟件工程實踐是大學裏少有的認真的團隊協做經驗。《構建之法》上說團隊的發展有幾個階段，你的團隊都經歷過麼，最後到達了「創造」階段了麼？（參考《構建執法》第17章 人、績效和職業道德）

• 我認爲目前團隊還未到創造階段。由於整個軟工實踐團隊開發的時間實在很是有限，我又擔負了大量的開發工做，因此主要精力是針對項目制定開發配合的規範。

  5、怎樣證實你學會了軟件工程？

• 不知如何證實，就簡單說一下我在團隊項目中是如何進行管理的吧。
• 在團隊項目中除了我在第二個問題中舉的進行代碼規範的控制，我對團隊配合規範也進行規定。首先爲團隊制定git配合規範，基於master創建development分支用來開發，基於dev分支創建了各模塊的feature分支，這樣分支之間幾乎沒有耦合，不會存在合併衝突的狀況。同時基於master創建release分支做爲項目發佈版本的分支。
  

• 爲了方便前端開發的接口對接，後端將全部接口文檔上傳至gitlab上的api文件夾，前端開發人員只需在gitlab即可以查看全部後端接口和相應的更新時間。
  
  
  

• 同時爲了便捷後期網站維護人員對bug的定位，我對項目的目錄框架和命名也進行規範。在views和components文件夾中分別先創建admin（管理端）、client（客戶端）、common三個文件夾。common文件夾主要存放對管理員端和客戶端共同複用的組件（以下拉框、導航欄等）和頁面（如登錄、40四、403頁面等）； 而在admin、client分別按照網站模塊創建文件夾。客戶端的views中的目錄與components中目錄徹底相同，管理端同理。
  views裏的頁面文件統一以index命名。
  綜上，這樣有頁面出bug後，即便未參與開發的維護人員也能根據目錄快速鎖定出錯文件。

• 在達到代碼規範和配合規範的必定要求，團隊能夠較有效率地進行配合開發以後，咱們對代碼質量也有要求。項目先後端都是採用MVC架構，大量封裝底層代碼，從而保證代碼的複用性、可維護性、可拓展性。之前端爲例，咱們在alpha階段主要對項目所需組件進行整理統計，接着統一開發單文件組件爲項目鋪好基礎，以後在beta階段只需在頁面文件中直接引用組件進行使用，再根據佈局修改css樣式，而沒必要關心組件的內部邏輯。這樣減小代碼冗餘的同時，頁面出現問題只需找到組件文件修改，而不會影響該頁面的其它部分。

7、個性發揮，包括圖文、照片和創意等

那周魚加熊掌兼得。