最終做業：軟工實踐我的總結

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

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

開篇博客連接

（5）針對上述問題（2）、（3）、（4），你對這門課的期待是什麼？你打算平均每週拿出多少個小時用在這門課上，以達成你的期待以及你在（2）或（3）或（4）上的目標？

個人期待就是，可以好好地開發一個有趣的東西，而不是爲了趕工期而找好實現的東西作（數據庫的教訓），能去系統瞭解軟件工程開發的流程，包括需求、版本控制、文檔、展現答辯還有進度控制。

• 達到的期待
  • 咱們的產品相對來講仍是十分有趣的！（大言不慚，同時在開發週期頁跟預計的差很少
  • 在整個過程當中，是一段紮紮實實寫代碼的經歷，感受還不錯
  • 縱觀每一次的答辯，咱們組的答辯成績都處於較爲前面的水平
• 未達到的期待
  • 在開發的代碼能力上以爲須要跟進一步的學習
  • 版本控制和相關工具的高端操做上面我還學習得不夠
  • 有時候會發現太多的精力反而花在做業文檔上面
• 意想不到的期待
  • 從新認識了好多超優秀而原來了解和接觸並很少的同窗

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

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

參照本身的PSP表格，包括我的及結對項目在內，大體完成了大約2200行左右的代碼

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

我的項目	結對項目1	結對項目2	uml設計	Alpha	現場編程	Beta	項目測評
1200	600	2000	600	4000	800	600	500

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

印象最深的仍是現場編程的那次做業，由於使用的技術棧你們都是剛剛上手，因而在前端上就耗費了挺多時間。這讓剛剛開始開發的咱們陷入了很僵硬的局面，士氣也有必定的降低。那次的做業也所以沒有完成的很好，但終歸最後的咱們坑都爬出來了。

四、累計花了多少個小時在軟工實踐上？平均每週花多少個小時？同時貼出開篇博客「你打算平均每週拿出多少個小時用在這門課上」的回答

• 當時彷佛沒有明確回答願意花多少時間在上面，但我持有的態度是隻要我認爲有意義事務，我就會去儘量地用時間去投入，整體上說本次實踐仍是十分符合期待的。

• 根據PSP表格上的記錄，累計消耗280小時左右，平均每週處於15~20小時之間。

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

• 設計工具：Mockup Procreate

• 開發工具：PyChram QtDesigner
• 庫：好像數不清了…

• 使用但不是新使用的工具：墨刀 PS AI VsCode GitHUb ProcessOn

六、學習和使用的新工具；

• 設計工具：Mockup Procreate

• 開發工具：PyChram QtDesigner
• 庫：好像數不清了…

• 使用但不是新使用的工具：墨刀 PS AI VsCode GitHUb ProcessOn

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

• git 命令行
• Python更深刻了些，尤爲在PyQt上

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

• 測試部分是我以前幾乎沒接觸過的
• 對代碼的管理
• 在寫代碼的過程當中掌握的一些新的tips

九、其餘方面的提高：

• 抗壓能力
• 消解負面情緒的壓力

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

團隊合做

有一些要注意的點：共識 分配 換位 溝通

共識：

• 必定要把目前團隊着手的任務狀態講清楚，而且讓你們都有一個全局的瞭解。
• 同時對於問題的解決路徑在分工前談好。
• 作好任務的規範

分配

• 保證物盡其用、人盡其才
• 儘可能的細粒度
• 團隊內人員最好不要出現重複的勞動

換位

• 當本身的任務完成時，要注意好是否符合達成共識中的規範
• 在保證規範的前提下，是否是能在本身的領域中作一些小小的優化，讓別人在處理時能更便利，以提升團隊的效率
• 不要僅僅思考本身的部分，相反應該適當關注整個全局，將大腦讓給PM或者負責人（這在團隊的討論中很常見），事實上在學生團隊中（尤其在課設）產品、事務的走向你們有權利也有義務來決定，一味地將思考的任務放在負責人身上是一種不負責的行爲，也不利於團隊取得更好的結果。

溝通

• 即便向團隊說明本身的進度和困難
• 有異議和想法應該積極在會議中提出並着手解決

3、對下一屆實踐的建議，或者對於開學初的你，對於大一的你，對於開學初的我，對於同期的TA們，對於後來的學弟學妹：

1）你有什麼想建議、告知和期許想要告訴他們呢？

• 之前咱們有得選，如今大家沒得選

• 當深淵凝視你的時候，大膽地瞪回去，當你回望，它也就那樣

2）特別地，特別地，下一屆要不要中途換隊員（強制的、完全的從一隊換到另外一隊）？ 假設依舊是一個90+人數的大班

私覺得這要視狀況而定，在項目真正開始編碼前，換組這件事的成本都會處於比較可控的狀態下。既然是軟工實踐這種較爲開放的課程，仍是不要禁掉這種渠道吧。所謂凱撒歸凱撒，成員換組這種事仍是讓同窗們用叫來投票，讓市場來決定。

3）身在一個格外大的班級，競爭強勁，你認爲一個組的人數應當在多少比較合適？

我認爲處於6~9人會比較合適

4）我的/結對/團隊做業應該控制在怎樣的規模？

團隊做業中有些花裏胡哨的東西反而過多佔據了精力（好比兩天一更的衝刺博客），事實上敏捷開發的人員是處於專職工做的，而咱們在本學期課還尤其多。長期都處在爲軟工疲於奔命。

5）這學期下來，你最感謝的人是誰？有什麼話想要對TA說呢？

綜合考慮應該是張揚同窗，確確實實地扛起了這個團隊的大旗，同時在面對項目停滯時可以解決好難題。正如大魔王說的那樣，他是本學期中最均衡的一我的。

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

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

1）研發出符合用戶需求的軟件

必須公開發布，有實際的用戶，必定的用戶量和持續使用量 （3 天后能保持10 - 100個用戶）；而不是: 作沒有用戶使用的軟件
2）經過一系列工具，流程，團隊合做，可以在預計的時間內發佈 「足夠好」 的軟件

有項目規劃/需求/設計/實現/發佈/維護，有定時的進度發佈 ； 而不是: 經過臨時熬夜，胡亂拼湊，大牛一人代勞，延遲交付等方式糊弄
3）而且經過數據展示軟件是能夠維護和繼續發展的。

而不是 找不到源代碼，代碼無文檔，代碼不能編譯，沒有task/bug 等項目的發展資料
4）對着這個檢查表：http://xinz.cnblogs.com/p/3852177.html 檢查一下，本身若是去企業面試，這些常見的問題是否都能回答，並在此總結。

請在隨筆中用數據證實上述內容或側重選擇之一。

六*（選作）、閱讀軟件工程中關於代碼質量的的經典論文，從下列文獻中選擇一篇或若干篇，結合本身的實際作一個閱讀筆記（例如，本身寫的代碼質量如何，是否是一個大泥球，如何衡量本身代碼的質量）？從如下參考論文中選擇一篇或若干篇：

參考論文文獻：

[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.

[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605

[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87

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