軟工課程總結

1、軟工初印象

---

• 期待、目標和不足

  • 期待：坦誠的說，一開始沒有不少指望，想着組隊水一水，過了就好了，在組隊後卻成了隊長，就指望着能和你們一塊兒作東西出來，能讓每一個人獲得不錯的分數，以及有好的收穫。
  • 不足：沒有負責項目的代碼部分，是很惋惜的一點，但也是本身的選擇，會利用寒假的時間去彌補這樣的遺憾。
  • 目標：但願能在寒假完善好小二結帳的商家端，也經過這個過程，彌補下在軟工實踐中缺失的部分。

• 提高總結

  • 代碼行數

    • 軟工實踐的代碼大量集中在團隊項目中，而我自己在團隊項目中不主要負責代碼部分，因此我的主要代碼分佈在我的項目和結對項目的代碼，以及部分團隊項目中的代碼，一共只有只有1140行左右

  • 做業時間列表

    做業名稱	耗時(h)	任務
    軟工實踐第一次做業	2	跟隨問題引導，反思本身，作出預期
    我的做業-詞頻統計	15	複習c++，學習github使用
    第三次做業-結對做業（原型設計）	2	接觸墨刀，嘗試原型設計
    第四次做業 - 團隊展現	5	設計團隊頭像，肯定項目，開會討論並拍照
    第五次做業 - 結對做業2	10	負責文本處理部分的代碼
    第六次做業 - 團隊答辯	10	開會肯定團隊的分配和管理，書寫博客，ppt製做演講
    項目UML設計	3	開了臨時會議，緊急分配任務，並去別組製做UML圖
    需求分析報告	10	項目logo設計，思惟導圖製做，博客整理
    團隊現場編程實戰（抽獎系統）	8	進度協調，需求分析，博客、文案撰寫，演示視頻製做
    Alpha 衝刺	50	機動+任務分配+答辯準備+美工設計+答辯準備+博客整理+拍攝演示視頻
    Alpha 過後諸葛亮	1	博客整理，alpha反思，beta 計劃
    項目測評（團隊）	6	任務分配，ppt製做，演講，博客整理
    BETA 版衝刺前準備（團隊）	1	組織會議，反思總結，分配任務，博客撰寫
    Beta 衝刺	30	機動+任務分配+答辯準備+美工設計+答辯準備+博客整理+拍攝演示視頻
    本次做業	3	反思總結，博客撰寫
    總計	221

  • 印象最深入的做業

    • 現場編程實戰做業
    • 咱們在頭一天的熬夜開會作了準備，提早配置好了了編程環境，在次日拿到題目後，從一開始的懵逼，到冷靜下來後的分析、分配和構建，到緊張編程到最後沒有作出東西，再到任務的從新分配，以及以後一個下午+一個晚上的團隊編程，最後終於成功作出東西並提交github。經歷了一個軟件完整的構建過程，有deadline的刺激、有團隊的協做，有失敗、有反思、有調整，最終也有了一個好的結果。是很棒、很難忘的經歷！

  • 累計時長

    • 累計大約花了221個小時，按15周次來算，平均每週14個小時

• 學習和使用的新軟件

  • typora能夠編輯markdown
  • 有道雲筆記能夠作筆記
  • 墨刀能夠作原型設計
  • powerpoint的功能很是豐富且強大
  • 格式工廠對文件格式轉換的處理很棒

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

  • 小程序開發平臺
  • 學習了部分小程序的開發語言

• 學習和掌握的新方法

  • markdown語法排版簡潔明瞭
  • 創客貼和千圖網都是很棒的素材網站
  • 阿里巴巴矢量圖庫有不少矢量素材，能夠作ppt

• 其餘方面的提高

  • 作了三次ppt答辯，演講方面獲得了鍛鍊，提高空間很大
  • 作了四次ppt，收集了不少素材，也多了些設計思路
  • 博客整理，讓我作筆記的整理更簡潔、明瞭
  • 有道雲筆記很好用，多端同步，很方便

2、人月神話

---

• 我的做業

  我的做業難度是通過老師和助教討論過控制在合理範圍內的，對這個難度我以爲是，班上絕大部分同窗自身經過花費時間學習，就能夠完成地不錯，但結果並非絕大部分同窗都能完成地很好，包括我本身也同樣，排除我的能力的差別之外，更多的仍是態度差別，有的人「想着怎麼去完成做業」，有的人「想着怎麼完成好做業」，相似於這樣的態度差別，也決定了最終結果上的差別。

• 團隊做業

  在團隊做業中當了小組長，因此對團隊領導者的角色有了新的認識，做爲一個好的團隊領導者應該有兩個基本的品質：一個是團隊中必要且領先的我的能力，另外一個是足夠的我的魅力。

  做爲我本身來講，在整個過程當中，由於沒有參與代碼編寫部分，在後期會感受到與團隊脫節，而做爲隊長又會大機率承擔一些與項目無關的之外的事情，花費了不少時間，但卻對本身的所須要的能力的成長幫助不大。因此我本身之後不會像此次軟工同樣，在沒有相關能力和好的考慮狀況下，草率地擔任一個團隊的領導者，那樣對本身和對團隊都不可以很好地擔負責任，可能做爲一個組員在團隊中工做，提升本身的核心業務能力，同時向好的領導者學習管理經驗，會是一個更好的選擇。

3、前車可鑑

---

• 建議、告知和期許

  • 期許：但願他們對本身想作的東西，能有更創新有趣的想法，也但願他們能收穫本身想要的東西。
  • 建議：建議每一個人都要參與代碼的編程，不要留下和我同樣的遺憾。
  • 告知：少熬夜！少熬夜！少熬夜！

• 跳槽建議

  交換隊員，更建議採起自願，強制換隊本意是好的，但這種騷操做很難把控利弊，容易翻車，形成很差的結果。

• 人數

  人數在6-7人比較合適，任務量、溝通交流、團隊協做都比較有利。

• 做業規模

  • 我的做業：難度上，但願能讓多數同窗經過查詢和學習能獨立完成；任務量上，但願平均能在10h左右完成比較好。
  • 結對做業：難度上，仍是要能讓大多數人經過努力作出來，任務量上平坦下來，平均每一個人在7-8h左右比較好。
  • 團隊做業：團隊項目由於是各組自定、老師審覈，因此以爲提醒同窗們，按本身的實際狀況去本身選擇項目的難度便可，做業量的話但願能簡化一些內容，好比：天天的衝刺博客這種，雖然是課程要求，但作到最後反而成了負擔，沒有了促進做用。

• 感謝的人

  感謝劉浩同窗，從結對做業到團隊做業都給了我不少的幫助，也向他學習了不少東西，具體不想談，放在內心就好。

4、團隊分析

---

回想起來，咱們小組一路走過來仍是很不容易。最初組建時候，人員配置缺乏大佬和有開發經驗的同窗，隊內其實有一種不夠自信的因素在其中；到第一次答辯的項目選題答辯的時候，儘管答辯成績還不錯，但答辯結束後卻又兩位同窗選擇跳槽，成爲全班惟二的跳槽同窗。整個小組就顯得有些出師不利、風雨飄搖的感受；而後，隨着時間的推移，和不斷的調整和努力，團隊在一次又一次答辯中取得了不錯的成績，整個團隊信心也愈來愈足，技術上也愈來愈成熟，不斷遇到新的問題，不斷解決新的問題；最後完成了完整的項目，也取得了不錯的成績，你們都收穫不少，很是感謝這段經歷！

5、軟件工程

---

怎麼證實你學會了軟件工程？哈哈，對我而言這是個僞命題，固然是沒法證實的。用一個學期的時間在課程要求的引導下，經歷了一個完整的軟件工程，用期末的三天時間粗讀了軟工的理論，因此不敢說本身學會了軟件工程，只能是對整個軟件工程的過程有所體悟，也在整個過程當中有了新的收穫。

對於項目的發佈實際上是比較惋惜的一點，由於咱們項目是基於微信平臺的小程序，又涉及到支付的功能，因此自己具備很大的資質限制性，儘管咱們已經盡最大努力去達成小程序的發佈，但最終仍是由於一個沒法搞定的資質證書，宣告發布失敗。但儘管如此，咱們對項目自身的需求和可用性來說都頗有信心，做爲一個軟件也實現了完整的功能和交互。

6、閱讀筆記

---

參考文獻：

[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.

這篇論文主要介紹了關於開源軟件的開發。開源項目的代碼須要是」嚴格模塊化，自包含，自我解釋「，因爲其它程序員能夠自由讀取、修改，加快了系統的演化速度，而審覈代碼質量的關鍵在於帶啊嗎是否有註釋，編碼是否貴伐以及代碼的可擴展性和移植性。

7、個性發揮

---

• 我的很喜歡本身爲項目設計的宣傳海報，因此最後的最後附在這裏